mysqlソート後、1ページ目のデータと2ページ目のデータ部分のデータ重複問題

開発過程の穴が開発過程で出会った問題を記録する(菜鶏一枚、エッセイは噴き出さないでください)
問題説明データページング時にデータレコード作成時間create_timeフィールドの逆順序、すなわちorder by create_を使用するtime desc limit ?,?,しかし,フロントエンドが要求したときに取得したデータは正しくなく,ページング中に一定の重複データが現れていることがわかる.
問題の原因は期首してまだ好奇心があって、総数は問題なくて、総照会も問題なくて、どうしてデータは繰り返して、それから一部のデータをカバーしました.その後、SQLを見ると、時間に基づいてソートされていますが、この時間は多くのデータが同じ時間に挿入されたり、同じ時間に設定されたりしています.
合計クエリー(つまり、ページを分割しない)を前後して実行するのは、重複していません.
再度ページングクエリーを実行すると、2ページに分けてクエリーを実行することができます.(しかも、2回にわたってクエリされたデータと合計クエリデータが異なる)
その後、SQLのORDER BYソート対象フィールドの値が同じである場合、システムのデータのソートはランダムになる可能性があります.すなわち、このデータが前にあるか、後ろにあるかのいずれかです.ページをめくると、重複したデータが簡単に見えます.
SQLでORDER BYが同じ値で結果が乱れている具体的な原因はGooleと関連資料を調べ、その原因をまとめました.実はこのような現象が発生したのは「わざと」設計されたのです.
ORDER BY文が指定されていない場合、MySQL(または任意のRDBMS)は結果を特定の順序で返すことを保証しません.order by句が指定されていない場合、ローは常にクラスタインデックス順序または物理ディスク順序で返されると考えている人もいます.しかし、これは、クエリ処理中に行の順序を変更できる多くの要因、例えば並列HASH接続が行の順序を変更するオペレータの良い例であるため、正しくない.
ORDER BY文を指定すると、MySQLはローをソートし、要求された順序で返します.ただし、この順序が確定的でない場合、すなわち重複する値がある可能性がある場合、同じ値を有する各グループでは、上記と同じ理由でこの順序は「ランダム」である.
決定的な順序を確認する唯一の方法は、ORDER BY句に保証された一意の列または列グループ(プライマリ・キーなど)を含めることです.

select member_id,create_time from member order by create_time desc,member_id;

このような問題を回避するために、プライマリ・キー(または一意性のあるフィールド)のソートをソートする必要があるビジネス・フィールドに導入して解決することができます.