1.インデックスを作成します
テーブルの作成時にCREATEINDEXメソッドが使用されます
普通的索引的创建：
CREATE INDEX (自定义)索引名 ON 数据表(字段);
复合索引的创建：
CREATE INDEX (自定义)索引名 ON 数据表(字段，字段....);
ALTER TABLEモード。テーブルの作成後に、インデックスを追加するために使用されます
//普通索引
alter table (表名) add index index_name (字段，字段....) ;
//唯一索引
alter table (表名) add unique (字段，字段....) ;
//主键索引
alter table (表名) add primary key (字段，字段....) ;
//全文索引
ALTER TABLE (表名) ADD FULLTEXT (字段，字段....) ;
//主键索引
ALTER TABLE (表名) ADD INDEX index_name (字段，字段....) ;
2インデックスがあるかどうかを確認します
クエリ条件の前にEXPLAINコマンドを使用して、SQL実行プランを表示します。NULLの場合は、インデックスがないことを意味します。
3. SQLステートメントの実行が遅い理由は何ですか？
①ほとんどの場合正常で、時折遅い
（1）データベースがダーティページをフラッシュしています。たとえば、REDOログがいっぱいで、ディスクに同期する必要があります。
（2）実行時に、テーブルロックや行ロックなどのロックが発生します。
②このSQL文の実行速度が非常に遅い（インデックスが無効であるか、インデックスがないため、データベースがインデックスを使用しないことを選択している）
1. likeが％で始まる場合、インデックスは無効です。likeプレフィックスに％がなく、サフィックスに％がある場合、インデックスは有効です。
2.インデックスはorステートメントの前後で同時に使用されません。またはの左右のクエリフィールドの1つだけがインデックスである場合、インデックスは無効であり、またはの左右のクエリフィールドがすべてインデックスである場合にのみ有効になります。
3.複合インデックス。最初の列インデックスを使用する代わりに、インデックスが無効になります。
4.データ型の暗黙的な変換があります（手動でインデックス障害も発生します）。varcharが一重引用符を追加しない場合、自動的にint型に変換され、インデックスが無効になり、全表スキャンが生成される場合があります。
5.インデックスフィールドにnot、<>、！=を使用します。不等式演算子はインデックスを使用しないため、その処理では全表スキャンのみが生成されます。最適化方法：key <> 0をkey> 0またはkey <0に変更します。
6.クエリ条件（=操作または機能が左側に表示されます）、この時点ではインデックスは無効になります。
7.範囲クエリ（>、<、between、like）が発生すると、ジョイントインデックスは一致を停止します。
つまり、主キーインデックスではないフィールドのインデックスを取得する場合、最終的に対応する主キーの値をクエリし、次に主キーの値に従って主キーインデックスを取得します。データの行全体をクエリして返します。したがって、完全なテーブルクエリでn行をクエリする場合、インデックスは2nです。nが非常に大きい場合、この時点で2n >> nの場合、データベースはインデックスを放棄し、完全なテーブルクエリを実行します）
4.クラスター化インデックス
いわゆるクラスター化インデックスとは、データフィールドにデータが格納され、主キーインデックスがクラスター化インデックスに属することを意味します。
5.非クラスター化インデックス
非クラスター化インデックスは、データに格納されている主キーまたはデータへのポインターであり、セカンダリインデックスは非クラスター化インデックスです。
6.インデックスカバレッジ
クエリするフィールドにインデックスが付けられている場合は、「テーブルに戻って」主キーに基づいて再度チェックし、値を直接返す必要はありません。
例：select name from table_a where name = 'zrx' ;;このとき、nameフィールドのインデックスがあり、nameの値を取得できます（インデックスのキーはnameであるため）。システムはまだ主キーに従って動作しますテーブルに戻ってもう一度確認しますか？答えは間違いなくノーです。
同様に、
例：select id from table_a where id = '10086';このクエリにもインデックスカバレッジがあります。主キーインデックスのキーもIDであるため、データベースはテーブルに戻って再度クエリを実行することはありません。
このカバレッジインデックスは少し奇妙なので、すでに知っている値に基づいてもう一度確認してください。しかし、私はそれがまだ機能していると思います、それは正しいファジークエリの場合でなければなりません。
7.どのフィールドがインデックスとして適しているか
1.頻繁なクエリとまれな改訂
2.条件付きクエリとしてよく使用されます
8.B +ツリー
完全に理解したくないが、すぐに理解したい場合。名前から、この構造がツリーであることがわかります。ツリーのバックエンドを学習すると、ツリーに格納されているデータがソートされていることがわかります。したがって、そうではありません。結論を出すのは難しい。ツリーのキーが順序付けられ、すでに間隔があり、間隔が低くなるほど間隔が小さくなり、必要なデータが最終的に検索されます。
参照：https：//www.cnblogs.com/wdss/p/11186411.html