MYSQLは、クエリは以下の通りです

Question

計画を説明し、

select * 
from lab this_ 
inner join visits v1_ on this_.visit_id=v1_.id 

v1_.idは、クエリの主キーであるTYPE「ALL」を登録しよう。

完了までに1分以上かかります。

以下は計画です。

id select_type table type possible_keys key  
1  SIMPLE  v1_  ALL <null>  <null> 
1  SIMPLE  this_ ALL <null>  <null> 

プライマリキーがキーとして選択されている理由がわかりません。また、ALLと入力します。

Answer 1

代替プランが効率的であると考えられる場合、クエリの実行中にインデックスが無視されることがあります。いくつかの点を考慮する：

1. テーブルのサイズ。 visitsテーブルが小さい場合は、インデックスの使用に多すぎるポイントはありません。

2. 選択性。 2つのテーブルを結合しますが、フィルタリングはなく、両方のテーブルのすべてのフィールドが必要です。これは、mysqlがvisitsテーブルから大部分のレコードを返さなければならないことを意味し、インデックスはidカラムだけをカバーします。したがって、mysqlは訪問データテーブルの大部分のレコードをスキャンしてデータを返すため、インデックスを使用することでそれ以上の利益は得られません。

3. 結合の反対側のフィールドの索引。 labs.visit_idフィールドがインデックスに登録されているかどうかについては言及していません。もしそうでなければ、再度visitsテーブルのpkを使うことで得られる得点は少なくなります。

使用されるインデックスに依存しない結果を生成する速度が、それはまた、結果セット（両方のレコードとフィールド数）、MySQLの設定、および基礎となるシステムの全体的なパフォーマンスのサイズに依存します。それにもかかわらず、mysqlがvisitsテーブルのpkを使用すると思われる場合は、クエリにindex hintを使用して、インデックスを使用する必要があることを強調します。 mysqlがインデックスヒントの影響を受けている場合は、explainで確認できます。