重要：MySQL 8+へのアップグレードを検討し、定義および文書化されたROW_NUMBER（）関数を使用して、機能が制限されたMySQLの古いバージョンに関連付けられた古いハックを破棄してください
次に、これらのハックの1つを示します。
クエリ内変数をほとんど/すべて使用するここでの回答は、ドキュメントに記載されている（言い換え）という事実を無視しているようです：
SELECTリストの項目が上から順に評価されることに依存しないでください。1つのSELECT項目に変数を割り当てて、別の項目で使用しないでください
そのため、彼らは間違った答えを生み出すリスクがあります。
select
(row number variable that uses partition variable),
(assign partition variable)
これらがボトムアップで評価されると、行番号は機能しなくなります（パーティションなし）。
したがって、実行順序が保証されたものを使用する必要があります。ケースを入力：
SELECT
t.*,
@r := CASE
WHEN col = @prevcol THEN @r + 1
WHEN (@prevcol := col) = null THEN null
ELSE 1 END AS rn
FROM
t,
(SELECT @r := 0, @prevcol := null) x
ORDER BY col
アウトラインldと同様に、prevcolの割り当て順序が重要です。prevcolは、現在の行の値を割り当てる前に現在の行の値と比較する必要があります（そうでない場合は、前の行のcol値ではなく、現在の行のcol値になります） 。
これがどのように組み合わされるかは次のとおりです。
最初のWHENが評価されます。この行のcolが前の行のcolと同じ場合、@ rがインクリメントされ、CASEから返されます。この戻り値は@rに格納されます。割り当てが@rに割り当てられたものの新しい値を結果行に返すのは、MySQLの機能です。
結果セットの最初の行では、@ prevcolはnull（サブクエリでnullに初期化されます）なので、この述語はfalseです。この最初の述語は、colが変更されるたびにfalseを返します（現在の行は前の行とは異なります）。これにより、2番目のWHENが評価されます。
2番目のWHEN述語は常にfalseであり、@ prevcolに新しい値を割り当てるためだけに存在します。この行のcolは前の行のcolとは異なるため（同じである場合、最初のWHENが使用されていたため、これを知っています）、次回のテスト用に保持するために新しい値を割り当てる必要があります。割り当てが行われた後、割り当ての結果がnullと比較され、nullと等しいものはすべてfalseであるため、この述語は常にfalseです。しかし、少なくともそれを評価することは、この行からのcolの値を維持するという仕事をしたので、次の行のcol値に対して評価することができます
2番目のWHENはfalseであるため、（col）でパーティション化している列が変更された場合、@ rに新しい値を与えるのはELSEであり、番号付けを1から再開します
これは、次のような状況になります。
SELECT
t.*,
ROW_NUMBER() OVER(PARTITION BY pcol1, pcol2, ... pcolX ORDER BY ocol1, ocol2, ... ocolX) rn
FROM
t
一般的な形式を持っています：
SELECT
t.*,
@r := CASE
WHEN col1 = @pcol1 AND col2 = @pcol2 AND ... AND colX = @pcolX THEN @r + 1
WHEN (@pcol1 := pcol1) = null OR (@pcol2 := col2) = null OR ... OR (@pcolX := colX) = null THEN null
ELSE 1
END AS rn
FROM
t,
(SELECT @r := 0, @pcol1 := null, @pcol2 := null, ..., @pcolX := null) x
ORDER BY pcol1, pcol2, ..., pcolX, ocol1, ocol2, ..., ocolX
脚注：
pcol内のpは「パーティション」を意味し、ocol内のoは「順序」を意味します。一般的な形式では、視覚的な混乱を減らすために変数名から「prev」を削除しました
括弧(@pcolX := colX) = nullは重要です。それらがないと、@ pcolXにnullが割り当てられ、処理が停止します。
前の列の比較が機能するためには、結果セットもパーティション列で順序付けする必要があるという妥協です。したがって、1つの列に基づいて行番号を並べ替えることはできませんが、結果セットは別の列に並べ替えることができます。サブクエリでこれを解決できる可能性がありますが、LIMITを使用しない限りサブクエリの順序が無視され、これが影響する可能性があることもドキュメントに記載されていると思いますパフォーマンス
私はメソッドが機能することをテストする以外にそれを掘り下げていませんが、2番目のWHENの述部が最適化されてしまうリスクがある場合（nullと比較してすべてがnull / falseなので、わざわざ割り当てを実行する必要があります）、実行されません、それも停止します。これは私の経験では発生しないようですが、合理的に発生する可能性がある場合は、コメントを受け入れて解決策を提案します
@pcolX変数を作成するサブクエリで、@ pcolXを作成するnullを実際の列のタイプにキャストするのが賢明な場合があります。 select @pcol1 := CAST(null as INT), @pcol2 := CAST(null as DATE)
greatest-n-per-groupして、同様の質問に案内します。