マスターする必要がある MySQL インデックスの 13 の知識ポイント

この記事では、MySQL インデックスに関する 13 の知識ポイントを紹介します。面接に非常に役立つと思いますので、共有します。

正直、データベースインデックスに関する知識は非常に複雑なので、本来はこの点をしっかりと見てから記事を書き、それについて説明したいと思っていました。その後、インデックス作成の知識が難しすぎて深すぎることに気づきました。それを包括的かつ詳細に話すのは本当に難しいので、最終的に学んだことや考えたことを次の質問に反映させました。みんなを助けることができます！

知識ポイント

質問 1: データベース インデックスとは何ですか?

データベース インデックスはデータベース システムにおける重要な概念です。インデックスは key とも呼ばれます。データベース クエリの効率を向上させるために使用されるデータ構造です。インデックスは次のように理解できます。本 目次 (対応する章の内容をすぐに見つけることができます) 同様に、データベース インデックスを使用して、データ テーブル内の対応するレコードをすぐに見つけることができます。

つまり、インデックスはデータ テーブルのディレクトリを作成するようなものです。

質問 2: インデックスを使用する理由は何ですか?

1. インデックスを使用すると、ストレージ エンジンがスキャンする必要があるデータの量が大幅に削減されます。インデックスを使用しない場合は、データ行ごとにデータ テーブルをスキャンする必要があり、非常に時間がかかります。

2. インデックスがソートされているため、データ テーブルに対して ORDER BY および GROUP BY 操作を実行すると、結果をすぐに取得できます。

3. インデックスはランダムな I/O をシーケンシャル I/O に変換して、ディスク IO の高いコストを回避し、クエリ効率を向上させることができます。

質問 3: MySQL インデックスはどのモジュールに実装されていますか?

(無料の学習ビデオ チュートリアルの推奨事項: mysql ビデオ チュートリアル)

MySQL インデックスはストレージ エンジン層で実装されるため、各 A ストレージ エンジン実装方法が異なり、同じインデックスが異なる方法で処理されます。

質問 4: インデックスを設定した後に機能しないのはなぜですか?

あいまい一致に % で始まる LIKE ステートメントを使用する場合、次のようなインデックスは使用できません。

がインデックスで終わる場合は、次のようなインデックスを使用できます。 <pre class='brush:php;toolbar:false;'>SELECT * FROM users WHERE name LIKE &amp;#39;%小张%&amp;#39;; SELECT * FROM users WHERE name LIKE &amp;#39;%小张&amp;#39;;</pre>

ステートメントの前後にインデックスは使用されません。次のステートメント、フィールド ID にはインデックスがあり、フィールド名 インデックスが作成されていない場合、次のステートメントはテーブル全体をスキャンすることしかできず、インデックスを使用できません: <pre class='brush:php;toolbar:false;'>SELECT * FROM users WHERE name LIKE &amp;#39;张%&amp;#39;;</pre>

では、ほとんどの場合、インデックスは基礎となるデータ構造として B-Tree を使用します。B-Tree は単に一般的な用語。実際、B-Tree を使用する場合、ストレージ エンジンごとに異なるバリエーションがあります。たとえば、InnoDB は B Tree を使用します。 ハッシュ インデックスなど、特殊なインデックス構造もいくつかあります。ハッシュ インデックスの最下層ではハッシュ テーブルが使用されます。

では、Memory のみが保存されます。ハッシュインデックスをサポートします。 質問 6: データ テーブルにインデックスを作成するのが適さないのはどのような状況ですか?

1. アーカイブされた履歴データの保存に使用され、クエリにはほとんど使用されないデータ テーブルにインデックスを作成することはお勧めできません。

2. 比較的少量のデータを含むデータ テーブルや、将来的にデータがあまり増加しないデータ テーブル (構成の保存に使用されるデータ テーブルなど) は、インデックスを構築すべきではありません。

3. 変更が頻繁に行われ、変更のパフォーマンスがクエリのパフォーマンスよりもはるかに優れている場合は、それ以上インデックスを作成する必要はありません。

質問 7: 返品フォームとは何ですか?

テーブルの戻り値は Innodb ストレージ エンジン用です。

ストレージ エンジンでは、主キー インデックスのリーフ ノードには記録されたデータが保存され、通常のインデックスのリーフ ノードには記録されたデータが保存されます。主キーのインデックスの場所。 主キーを介してクエリを実行する場合、主キー インデックスの検索ツリーを検索するだけで、記録されたデータを直接取得できます。

通常のインデックスを使用してクエリを実行する場合、通常のインデックスの検索ツリーを検索して主キーのアドレスを取得した後、さらに主キーを使用して主キーの検索ツリーを検索します。このプロセスは次のとおりです。テーブルリターンと呼ばれます。

質問 8: クラスター化インデックスと非クラスター化インデックスの違いは何ですか?

クラスター化インデックス: クラスター化インデックスの順序は、データの物理的な保存順序であり、インデックスとデータは一緒に配置されます。データはインデックスを通じて直接取得できます。クラスター化インデックスは 1 つだけです。データテーブル内。

ノンクラスタード インデックス: インデックスの順序はデータの物理的な配置順序とは関係がなく、インデックス ファイルとデータは別々に保存されます。

質問 9: MySQL の主キー インデックス、一意のインデックス、および通常のインデックスの違いは何ですか?

主キー インデックスとして設定されたフィールドは

にすることはできません。また、データ テーブルに含めることができる主キー インデックスは 1 つだけです。 一意のインデックスとして設定されたフィールド値を重要にすることはできません。

普通索引可以包含重复的值，也可以为 NULL 。

问题10：索引可以提高查询性能，那是不是索引创建越多越好？

索引作为一个数据表的目录，本身的存储就需要消耗很多的磁盘和内存存储空间。

并助在写入数据表数据时，每次都需要更新索引，所以索引越多，写入就越慢。

尤其是糟糕的索引，建得越多对数据库的性能影响越大。

问题11：MyISAM与InnoDB在处理索引上有什么不同？

MyISAM 存储引擎是非聚族索引，索引与数据是分开存储的，索引文件中记录了数据的指针

而 InnoDB 存储引擎是聚族索引，即索引跟数据是放在一块的， InnoDB 一般将主键与数据放在一块，如果没有主键，则将 unique key 作为主键，如果没有 unique key ，则自动创建一个 rowid 作为主键，其他二级索引叶子指针存储的是主键的位置。

问题12：什么是索引的最左前缀原则？

MySQL 数据库不单可以为单个数据列创建索引，也可以为多个数据列创建一个联合索引，比如：

CREATE TABLE test(
    a INT NOT NOT,
    b INT NOT NOT,
    KEY(a,b)
);

当我们使用下面的查询语句时，由于 WHERE 语句中查询的条件就是联合索引，所以可以很快查询到数据。

SELECT * FROM test WHERE a=1 AND b=1;

同样，下面的语句也会利用上面创建的联合索引，这是因为 MySQL 会按照索引创建的顺序进行排序，然后根据查询条件从索引最左边开始检测查询条件是否满足该索引，由于字段 a 在最左边，所以满足索引。

SELECT * FROM test WHERE a=1;

而使用 字段b 进行查询时，则为满足，因为从最左边匹配到的是 字段a ，所以 MySQL 判断为不满足索引条件。

SELECT * FROM test WHERE b=1;

从上面例子可以很好地了解索引的最左前缀原则，同时也说明了索引顺序的重要性。

问题13：什么是覆盖索引？

如果一个索引中包含查询所要的字段时，此时不需要再回表查询，我们就称该索引为覆盖索引。

比如下面的查询中，字段id是主键索引，所以可以直接返回索引的值，显著提升了查询的性能。

SELECT id FROM users WHERE id BETWEEN 10 AND 20;

小结

当然，上面列出的只是索引的一小部分知识点，有什么回答不对的地方，欢迎指出。

以上がマスターする必要がある MySQL インデックスの 13 の知識ポイントの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。