MySQLのインデックスを理解する：パート2

このブログ投稿は、MySQLのインデックスに関する一連のブログの第2部です。 MySQLインデックスに関するブログ投稿シリーズの最初の部分では、それらが何であるか、それらが何をするか、それらのタイプが何であるか、最適なデータ型を選択する方法、および使用するインデックスのMySQL文字セットを含む非常に多くのことをカバーしました。 MySQLでインデックスを使用することのメリットとデメリットを確認しました。使用するのに最適なインデックスを選択する方法、クエリのパフォーマンスを向上させ、MySQLがインデックスを使用するようにする方法、必要なインデックスの数について説明しました。また、ストレージエンジンに関連するいくつかの考慮事項についても説明しました。このブログ投稿では、シリーズの最初の部分で説明したコンテンツの一部について詳しく説明します。 MySQLのインデックスとストレージエンジンの相関関係から始めます。

MySQLのインデックスとストレージエンジン

以前のブログ投稿ですでに述べたように、MySQLで特定のストレージエンジンを使用する場合、インデックスなどに何らかの制限がある可能性があります。それらのいくつかを次に示します-それらのいくつかを定義します（それらのいくつかはブログシリーズの最初の部分でカバーされていたので、何かが足りない場合はおそらくそこにあります）、次にそれらをより詳細にカバーします分析：

MySQLのドキュメントによると、インデックスの最大数、キーの最大長、およびインデックスの最大長は次のとおりです。ストレージエンジンごとに定義されます。以前のブログ投稿ですでに述べたように、MyISAMテーブルとInnoDBテーブルあたりのインデックスの最大数は64、両方のストレージエンジンのインデックスあたりの最大列数は16、InnoDBの最大キー長は3500バイト、最大MyISAMのキーの長さは1000バイトです。
CREATEINDEXを使用して主キーを作成することはできません。代わりにALTERTABLEを使用してください。
BLOBおよびTEXT列は、InnoDB、MyISAM、およびBLACKHOLEストレージエンジンを実行しているテーブルに対してのみインデックス付けできます。
列のプレフィックスのみにインデックスを付ける場合は、プレフィックスのサポートとその長さも同じであることに注意してください。ストレージエンジンに依存します。 REDUNDANTまたはCOMPACT行フォーマットを使用するInnoDBテーブルの場合、プレフィックスの長さは最大767バイトになりますが、DYNAMICまたはCOMPRESSED行フォーマットの場合、プレフィックス長の制限は3072バイトに増加します。 MyISAMテーブルの場合、プレフィックス長の制限は1000バイトです。 NDBストレージエンジンはプレフィックスをまったくサポートしていません。
厳密なSQLモードが有効になっていて、インデックスプレフィックスが最大列データ型サイズを超える場合、CREATEINDEXはスローします。エラー。厳密なSQLモードが有効になっていない場合、CREATEINDEXは警告を生成します。 UNIQUE INDEXが作成されると、エラーが発生します。
通常、MySQLでは特定のテーブルに最大16個のインデックスしか作成できません。
PRIMARY KEYインデックスを使用している場合、テーブルごとに持つことができる主キーは1つだけです。 FULLTEXT、UNIQUE INDEX、およびINDEXにはこの制限はありません。
FULLTEXTインデックスを使用している場合は、InnoDBまたはMyISAMストレージエンジンでのみ使用できることに注意してください。 CHAR、VARCHAR、またはTEXT列の場合。また、MySQLはMATCH（）AGAINST（）句が使用されている場合にのみFULLTEXTインデックスを使用し、必要に応じて同じ列にインデックスとフルテキストインデックスを同時に持つことができ、FULLTEXTインデックスには使用中のストレージエンジンに固有のストップワードの独自のセット。
Bツリーインデックスは、ワイルドカードで始まるLIKEクエリを使用する場合に役立つことがありますが、特定の場合に限ります。シナリオ。

MySQLのインデックスがどのように機能するかを理解しようとしている場合は、これらのインデックスの制限を知っておくと便利です。ただし、理解することがさらに重要なのは、インデックスが実際にMySQLで使用されていることを確認する必要があるという事実です。これらのシリーズの最初のパート（「使用するのに最適なインデックスを選択する方法」）でこれについて簡単に触れましたが、インデックスが実際にMySQLで使用されていることを確認する方法については説明していません。これを行うには、EXPLAINを使用してそれらの使用法を確認します。EXPLAINを説明可能なステートメントと一緒に使用すると、MySQLはステートメントの実行プランに関するオプティマイザーからの情報を表示します。

主キーに関する考慮事項

MySQLのPRIMARYKEYインデックスに関連する基本的な考慮事項のいくつかには、主にテーブル内のレコードを一意に識別するために使用され、AUTO_INCREMENTing値で頻繁に使用されるという事実が含まれます。これは、次の場合に非常に役立つ可能性があることを意味します。たとえば、IDフィールドを作成しています。 PRIMARY KEYフィールドには一意の値を含める必要があり、NULL値を含めることはできません。

列プレフィックスの一致インデックスは列プレフィックスと一致することもあります。インデックスへのこのアプローチは、列が文字列列であり、列全体にインデックスを追加すると多くのディスク領域を消費する可能性があると考える場合に役立ちます。インデックスは次のように列プレフィックスと一致する可能性があります：

ALTER TABLE demo_table ADD INDEX index_name(column_name(length));

上記のクエリは、定義された列プレフィックスに対してのみ、column_nameという名前の列にインデックスindex_nameを追加します。インデックスを作成するのに十分な長さを選択するには、プレフィックスを使用して列の値の一意性を最大化するようにします。テーブル内の行数を見つけて、目的の行の一意性が得られるまでさまざまなプレフィックス長を評価します。

MySQLのフルテキストインデックス

MySQLのFULLTEXTインデックスは、まったく別の獣です。それらには固有の多くの制限があり（たとえば、InnoDBには36語で構成されるストップワードリストがあり、MyISAMストップワードリストは143語で構成されます）、固有の検索モードもあります。それらのいくつかには自然言語モードが含まれています（このような検索モードをアクティブにするには、修飾子なしで全文検索クエリを実行します）、検索を拡張することもできます（これを行うには、WITH QUERY EXPANSION修飾子を使用します-このような検索モードは、 2回検索しますが、2回目の検索では、最初の検索からの最も関連性の高いレコードがいくつか含まれます（ユーザーが何かの知識を暗示している場合によく使用されます）。ブール演算子を使用して検索するには、INBOOLEANMODE修飾子を使用します。 FULLTEXTインデックスは、検索クエリがInnoDBの場合は最低3文字、MyISAMの場合は最低4文字で構成されている場合にのみ使用されます。

ワイルドカードでのBツリーインデックスの使用

インデックスは、検索エンジンに似たものを構築する場合にも頻繁に使用されます。そのため、値の一部のみを検索して結果を返したいことがよくあります。ここでワイルドカードが介入します。ワイルドカードを使用する単純なクエリでは、LIKEクエリと％記号を使用して、テキストの後の「何か」を示します。たとえば、そのようなクエリは、「検索」という単語で始まり、その後に何かがある結果を検索します。

SELECT * FROM … WHERE demo_column LIKE ‘search%’;

このようなクエリでは、「検索」という単語があり、その後に何かがある、何かで始まる結果を検索します。

SELECT * FROM … WHERE demo_column LIKE ‘%search%’;

ただし、ここに問題があります。上記のクエリではインデックスは使用されません。なんで？それ自体の先頭にワイルドカードがあり、MySQLは列を何から始める必要があるかを理解できないためです。そのため、ワイルドカードインデックスがその役割を果たしていると述べましたが、これは特定のシナリオ、つまり検索クエリの最初にワイルドカードがないシナリオに限られます。

ClusterControlを使用したクエリのパフォーマンスの監視

EXPLAINを使用する以外に、ClusterControlを使用してクエリのパフォーマンスを監視することもできます。ClusterControlは、データベースインスタンスとクエリのパフォーマンスを追跡できる一連の高度な監視およびレポート機能を提供します。。たとえば、クラスターをクリックすると、「クエリモニター」タブが表示されます。それをクリックすると、ClusterControlを使用してデータベースインスタンス内のクエリのステータスを監視できます。

ClusterControlのこの部分では、低速および長時間の上位のリストを表示できます-クエリを実行しながら、クエリをフィルタリングすることもできます。たとえば、少し前に@@ log_binで構成されるクエリを実行したことがわかっている場合は、用語を検索するだけで、ClusterControlが結果のリストを返します。

お気づきかもしれませんが、使用するホストでクエリをフィルタリングすることもできますまたは、発生によって、20、100、200などの一連の行を表示するように選択することもできます。ClusterControlは、クエリが最後に表示された日時、合計実行時間、返された行数も通知します。調べた行数など。 ClusterControlは、MySQL、MariaDB、MongoDB、PostgreSQL、またはTimescaleDBインスタンスでインデックスが実際にどのように使用されているかを観察したい場合に役立ちます。

概要

このブログ投稿では、MySQLのインデックスに関するいくつかの制限と利点について説明し、ClusterControlがデータベースのパフォーマンス目標の達成にどのように役立つかについても説明しました。 MySQLのインデックスについても、さらに深く掘り下げて説明しますが、これまでの説明を締めくくるには、MySQLのインデックスには確かに独自の場所があることを忘れないでください。つまり、インデックスを最大限に活用するためです。それらがストレージエンジンとどのように相互作用するか、それらの利点と制限、特定のタイプのインデックスをいつどのように使用し、賢明に選択するか。