mysqlヒントとは何ですか

mysql では、ヒントは「クエリ最適化ヒント」を指し、オプティマイザに特定の方法で最適化のための実行プランを生成するよう促し、ユーザーの SQL ステートメントをより柔軟にします。ヒントはテーブルの内容に基づくことができます。接続順序、メソッド、アクセス パス、並列処理などのルールは、DML (データ操作言語) ステートメントに影響します。

このチュートリアルの動作環境: Windows7 システム、mysql8 バージョン、Dell G3 コンピューター。

テーブル、フィールド、またはインデックスを操作するときにコメントを追加して、コードの可読性を高め、他の人がコードをすぐに理解できるようにすることができます。これはデータベースを使用する人向けのヒントです。同様に、別のヒントもあります。ヒントと呼ばれる、データベースへのヒントです。

ヒントとは

ヒントは「クエリ最適化ヒント」を指します。これは、オプティマイザーに特定の方法で最適化するよう促します。 SQL ステートメントがより柔軟になり、クエリが高速になります。もちろん、遅くなる場合もあります。すべてはオプティマイザーの理解とシナリオの理解に依存します。

SQL ステートメントを実行すると、MySQL が実行プランを生成し、ヒントがクエリ オプティマイザーに指示した方法で実行プランを生成するように指示することがわかっています。

ヒントは、テーブルの接続順序、メソッド、アクセス パス、並列処理、その他のルールに基づいて DML (データ操作言語) ステートメントに作用できます。範囲は次のとおりです:

使用的优化器类型；
基于代价的优化器的优化目标，是all_rows还是first_rows；
表的访问路径，是全表扫描，还是索引扫描，还是直接用rowid；
表之间的连接类型；
表之间的连接顺序；
语句的并行程度；

一般的に使用されるヒント

• 強制インデックス FORCE INDEX
  SELECT * FROM tbl FORCE INDEX (FIELD1) …

• インデックスを無視 IGNORE INDEX
  SELECT * FROM tbl IGNORE INDEX (FIELD1, FIELD2) …

• 閉じるクエリ バッファ SQL_NO_CACHE
  SELECT SQL_NO_CACHE field1, field2 FROM tbl;
  リアルタイム データをクエリする必要があり、頻度が高くない場合は、バッファをオフにすることを検討できます。この SQL が実行されたかどうかに関係なく、MySQL はバッファ内を調べません。

• 強制クエリ キャッシュ SQL_CACHE
  SELECT SQL_CACHE * FROM tbl;
  この関数は前の関数とは逆ですが、私の関数では query_cache_type のみが使用されます。 .ini は 2 時に動作するように設定されています。

• 優先操作 HIGH_PRIORITY
  HIGH_PRIORITY を選択および挿入操作で使用すると、この操作が優先されることを MYSQL に知らせることができます。
  SELECT HIGH_PRIORITY * FROM tbl;

• ##遅延操作 LOW_PRIORITY

  LOW_PRIORITY を挿入および更新操作で使用して、この操作が遅れていることを mysql に知らせることができます。
  
  update LOW_PRIORITY tbl set field1= where field1= …

• 遅延挿入 INSERT DELAYED

  
  INSERT DELAYED INTO tbl set field1= … は、クライアントがデータを挿入するアプリケーションを送信すると、MySQL は OK ステータスを返しますが、実際には実行されず、メモリに保存されてキューに入れられ、mysql が空いているときに挿入されることを意味します。
  重要な利点は、複数のクライアントからの挿入リクエストがグループ化されて 1 つのブロックに書き込まれることです。これは、多数の挿入を個別に実行するよりもはるかに高速です。
  欠点は、自動インクリメント ID を返せないことと、システムがクラッシュすると、MySQL がまだ挿入する時間がなかったデータが失われることです。
  

• 接続シーケンスを強制する STRAIGHT_JOIN

  
  SELECT tbl.FIELD1, tbl2.FIELD2 FROM tbl STRAIGHT_JOIN tbl2 WHERE…上記からわかるように、 SQL ステートメントは、STRAIGHT_JOIN を介して、MySQL に tbl、tbl2 の順序でテーブルを結合させます。 MySQL が推奨する順序よりも独自の順序で結合する方が効率的であると思われる場合は、STRAIGHT_JOIN を使用して接続順序を決定できます。
  

一般的には使用されません

• 一時テーブル SQL_BUFFER_RESULT の使用を強制します

  
  SELECT SQL_BUFFER_RESULT * FROM tbl WHERE … クエリの結果セットに大量のデータがある場合、SQL_BUFFER_RESULT. オプションを使用して結果セットを一時テーブルに強制的に入れることができるため、MySQL テーブルのロックをすぐに解放できます (他の SQL ステートメントがこれらのレコードをクエリできます))、大規模なレコードセットをクライアントに長期間提供できます。
  

• 一時テーブル SQL_BIG_RESULT および SQL_SMALL_RESULT を使用するグループ

  
  SELECT SQL_BUFFER_RESULT FIELD1, COUNT(*) FROM tbl GROUP BY FIELD1; は SELECT ステートメントに有効です, GROUP BY および DISTINCT クエリに一時テーブルのソートを使用するように MySQL 最適化に指示します。SQL_SMALL_RESULT は、結果セットが小さいため、メモリ内の一時テーブルで直接ソートできることを示します。それ以外の場合、サイズが大きい場合は、ディスク一時テーブルのソートが必要です。
  

• SQL_CALC_FOUND_ROWS
  これは実際にはオプティマイザー プロンプトではなく、オプティマイザーの実行計画にも影響しませんが、mysql によって返される結果セットには、この影響を受ける行の合計数が含まれます。 FOUND_ROWS() と組み合わせる必要がある操作。組み合わせて使用​​します。
  SQL_CALC_FOUND_ROWS 今回処理された行数を記録するように MySQL に通知します。FOUND_ROWS() は記録された行数を取得するために使用され、ページング シナリオに適用できます。
  一般的なページング方法は、まず総数を確認し、ページ数を計算してから、特定のページの詳細をクエリします。
  SELECT COUNT(*) from tbl WHERE …
SELECT * FROM tbl WHERE …制限 m,n
  ただし、SQL_CALC_FOUND_ROWS# を使用します。 ##、これは次の記述に簡略化できます:
  SELECT SQL_CALC_FOUND_ROWS * FROM tbl WHERE … limit m,n;
  SELECT FOUND_ROWS(); 2 番目の記事
  SELECT は、最初の SELECT の合計行数を制限なく返します。そのため、行の合計数を取得するのに時間のかかる複雑なクエリを実行するだけで済みます。同時。

• LOCK IN SHARE MODE, FOR UPDATE

  同様に、これら 2 つは最適化のヒントではありません。これらは SELECT ステートメントを制御するロック メカニズムです。これらは行レベルでのみ有効です。ロック。InnoDB によってサポートされています。
  

知識を広げる:

概念と違い

SELECT ... LOCK IN SHARE MODE 追加されるのは IS ロック (意図的共有ロック) です。つまり、共有ロックは修飾された行に追加されます。他のセッションはレコードを読み取り、IS ロックの追加を続行できます。ただし、それはできません。ロックされたセッションが完了するまで変更できません (完了しないと、直接ロックの待機がタイムアウトになります)。

SELECT ... FOR UPDATE 追加されるのは IX ロック (意図排他ロック)、つまり条件を満たす行に排他が追加され、他のセッションは追加できませんこれらのレコードに対する任意の S ロックまたは X ロック。一貫した非ロック読み取りがない場合、他のセッションはこれらのレコードを読み取り、変更できませんが、innodb には非ロック読み取りがあります (スナップショット読み取りにはロックが必要ありません)。 したがって、
for update のロック メソッドは、lock in share mode## のメソッドよりも select...lock in share mode のクエリをブロックするだけです。 #. このメソッドはスナップショットの読み取りをブロックしません。

アプリケーション シナリオ

共有モードでのロック

は、リレーションシップを持つ 2 つのテーブルの書き込みシナリオに適用できます。公式の mysql の例を使用すると、次のようになります。 table は子テーブル、もう 1 つは親テーブルです。子テーブルの特定の列 child_id が親テーブルの c_child_id 列にマップされているとします。ビジネスの観点から見ると、child_id=100 のレコードを直接挿入するのは危険です。このとき子テーブルに挿入すると、c_child_id=100のレコードが親テーブルから削除され、業務データが不整合になる可能性があります。正しい方法は、最初に select * fromparent where c_child_id=100 lock in share mode を実行し、このレコードを親テーブルでロックしてから、insert into child(child_id) 値 ( 100) 。 [関連する推奨事項:

mysql ビデオ チュートリアル

]

以上がmysqlヒントとは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。