mysql では順序条件でインデックスを作成するのが効果的だといつも思っていましたが、効果がないことがわかりました。

EXPLAIN SELECT *
FROM `order2`
WHERE 1
ORDER BY `create_time` DESC

フルテーブルスキャン...

ディスカッションへの返信 (解決策)

このように順序付けされたインデックスは使用されません

現在の条件はテーブル全体です。どのようなインデックスがあっても、テーブル全体が必ず完了します。

順序インデックスは 2 か所で使用する必要があることを理解しています。
1.は制限です
2. order フィールドは選択された戻り値内にあります。これはより複雑です。つまり、戻り値には order フィールドのみが存在するか、複数のフィールドが返される必要があります。これらのフィールドの順序での結合インデックス

の順 これはインデックスの使用方法ではありません

現在の状態は、どのようなインデックスがあるかに関係なく、テーブル全体です。テーブルは必ず使用されます

順序インデックスは 2 か所で使用する必要があることを理解しています
1. 制限がある場合
2. 順序フィールドは選択の戻り値にあります。より複雑な場合、つまり、戻り値に順序フィールドのみが存在するか、複数のフィールドが返される場合、インデックスはこれらのフィールドの順序で結合インデックスである必要があります

を使用しました。テーブル全体のインデックスに影響を与えるゴミデータはありますか?

EXPLAIN などのインデックス条件を追加します。 SELECT *
FROM `order2`
WHERE 1 and create_time>0
ORDER BY `create_time` DESC

考えてみると、テーブル内のデータベースが小さすぎる場合、または 分布が大きくない場合、MySQL クエリ オプティマイザーはインデックスを削除し、テーブル全体のスキャンを実行します。
この種の自動最適化の動作は予測できません。データ量が比較的少ない場合は、インデックスが使用される場合と使用されない場合があります。

そういえば、テーブル内のデータベースが小さすぎる場合、または分布が大きくない場合、MySQL クエリ オプティマイザーはインデックスを削除し、テーブル全体のスキャンを実行します。
この種の自動最適化の動作は予測できません。データ量が比較的少ない場合は、インデックスが使用される場合と使用されない場合があります。

はい、この問題を見つけました。
検索条件で見つかったデータ 多すぎる場合はテーブル全体がスキャンされます