問題タブ [full-table-scan]

次のビューを検討してください

some_table何百万もの行があり、 +another_tableにインデックスがあります。 a_idother_column

ここで、次の SQL を考えてみましょう。

この sql クエリが でフル テーブル スキャンを実行している理由を誰か教えてもらえますsome_tableか? another_table目標は、other_columnequalsから行数を返すビューを持つことです'ABC'。

LEFT JOIN my_viewクエリをに置き換えるとLEFT JOIN ( the AS CLAUSE from the view )、完全なテーブル スキャンは実行されず、a_id + other_column インデックスが使用されます。

私は困惑しています。どんな助けでも大歓迎です。

MySql Indexes Optimization のドキュメントを読んでいます。

--max-seeks-for-key=1000 という設定を見つけました。ここで MySQL の「サーバー システム変数」を確認しました。
それによると

「これを低い値 (たとえば 100) に設定することで、MySQL にテーブル スキャンではなくインデックスを優先させることができます」

.
FULL TABLE SCANから私が理解していることは次のとおりです。

クエリでほとんどの行にアクセスする必要がある場合、インデックスを使用するよりも順次読み取る方が高速です。シーケンシャル読み取りは、クエリにすべての行が必要でない場合でも、ディスク シークを最小限に抑えます。

したがって、MySQL がディスク シークを最小限に抑えるフル テーブル スキャンを実行している場合、ディスク シークを増加させる可能性のあるインデックス スキャンを優先するために --max-seeks-for-key=1000 を使用するのはなぜですか。

ドキュメント8.3.1.20 では、フル テーブル スキャンを回避する方法が、フル スキャンを回避するためのステップとして言及されています。

したがって、 --max-seeks-for-key の実用的で意味のある使用法があるかどうか知りたいです。

ここ数か月で、いくつかのテーブルを MYiSAM から InnoDB に移行しました。複数のWebスクレイピングインスタンスを介して個々の行を更新しているため、理論的には行ロックの利点のためにこれを行いました. 現在、slow_query_log (10 秒) に何万もの slow_queries が蓄積されています。そして多くのフルテーブルスキャン。1行の非常に単純な更新（4または5列の更新）に28秒かかるイベントがあります。(私たちの I/O と効率は非常に良好で、試行の失敗/中止は非常に低く < 0.5%)

最も頻繁に更新する 2 つのテーブルは、主キーとして ID (int 11) を持っています。InnoDB では、主キーはクラスター化されたキーであるため、ID 順にインデックス付けされたディスクに書き込まれます。しかし、列を識別する 2 つの最も重要なレコードはBillsofLadingand Container(両方とも varchar22) です。ほとんどの DML クエリは、これら 2 つの列に基づいてレコードを検索します。また、インデックスもありBillsofLading、container. 私が理解しているように、InnoDB はこれら 2 つのセカンダリ インデックスを作成するときに主キーも使用します。

したがって、ID=1 とBillsofLading='z' のレコードと、ID=9 とBillsofLading='a' の別のレコードを持つことができます。BillsofLadingInnoDB インデックスでは、SELECT where ='a' に基づいてレコードを更新するときに、インデックスがID?

ここでロジックを手伝ってくれてありがとう！

次のようなクエリがあります。

問題は、このテーブルが非常に大きく、Oracle が完全なテーブル スキャンを実行していることです。このクエリを高速化するインデックス (status、child_id、parent_id 列を含む) を作成しようとしましたが、Oracle はヒントがあってもこのインデックスを使用していません。

このクエリを高速化する方法はありますか?