クエリが最適化された後、理論的には次のような状況は発生しません。
1. 1つのリクエストが他のリクエストをブロックする
2.一部のリクエストが互いにブロックします
このような状況が発生しないように努めています。
したがって、スマートな「クエリキラー」は優れた「作業能力の監視員」となり、
疑わしい状況を追跡し、データベースを解放します。
このキラーは、データベースがいくつかの重いクエリを実行する状況を可能にします。
しかし、彼は多くの長いリクエストが現れ始めるのを見ると、行動を起こし始めます
予定
クエリキラーの対象は次のとおりです。
1.次の場合の状況の追跡：
1.1。 一部のリクエストは他のリクエストをロックおよびブロックします
1.2。 短い時間内に開始された多数のクエリが互いにブロックする
2. そのような状況のログ
3.次のような状況を解決します。
3.1。 1つの要求が他の要求をブロックする状況の場合-ロックのソースを強制終了します：最も長い要求を強制終了
3.2。 リクエストが互いにブロックする状況の場合-データベースを解放してみてください：いくつかの下限しきい値よりも長い一連のリクエストを強制終了します
したがって、最適化されたキャッシュ生成手順または作業要求が再び失敗し始めても、Qeury-Killerはキャッシュの再生成によるデータベースの曲がりを許可せず、単に再生成を中止してエラーログを記録します。
（キャッシュの再生成は、その死の可能性を提供し、一時テーブルに生成される必要があります。一時テーブルは、後でターゲットに名前が変更されます。）
ロジック-擬似コード
以下はクエリキラーの擬似コードです
-- CONSTANTS: SET @alert_query_duration:=10; SET @alert_queries_max_count:=6; SET @dangerous_query_duration:=15; SET @dangerous_queries_max_count:=30; SET @dangerous_queries_affect_duration_bottom:=5; -- Check long queries: SELECT @alert_queries_count:=COUNT(0) FROM information_schema.processlist WHERE COMMAND != 'Sleep' AND TIME>@alert_query_duration ORDER BY TIME DESC; IF (@alert_queries_count >= @alert_queries_max_count) THEN 1. Report to error_log: module = Query killer error = Maximum amount of long queries reached context = List of all long queries (which longer than @alert_query_duration) 2. Take actions: -- Check if there is a lot of dangerous queries already -- (which may cause each other locks): SELECT @dangerous_queries_count:=COUNT(0) FROM information_schema.processlist WHERE COMMAND != 'Sleep' AND TIME>@dangerous_query_duration ORDER BY TIME DESC; IF (@dangerous_queries_count >= @dangerous_queries_max_count) THEN -- KILL dangerous queries and queries, which probably might be already affected by them -- (so kill all queryes, where TIME>@dangerous_queries_affect_duration_bottom) ... ELSE -- KILL one query (the longes one) which probably locks all others ... END END
状況の例
以下は、危険な状況の例です。
1.リクエストをロックし、それにより他のリクエストをブロックします
たとえば、指定されたキャッシュを生成するリクエストは、常に更新する必要があるテーブルに長いロックをかけます-同様の図が表示されます：
97669965 root localhost gtf 289 Query CREATE TABLE gtf.cache_vw_... 99057101 root localhost:33092 gtf 284 Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057467 root localhost:51863 gtf 276 Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057499 root localhost:51868 gtf 275 Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057840 root localhost:33164 gtf 267 Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057907 root localhost:54313 gtf 266 Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057987 root localhost:59942 gtf 264 Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99059528 root localhost:52062 gtf 229 Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i
ここで、キャッシュテーブルを作成する最初の要求は、メディアテーブルを更新することです
2.短時間で大量のリクエストが開始され、互いにブロックされる
これらは、Use temporaryを使用したクエリかもしれません。 ファイルソートの使用
+------+-------------+-------+--------+----------------------------------+----------------------------------+---------+-----------------+------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+--------+----------------------------------+----------------------------------+---------+-----------------+------+----------------------------------------------+ | 1 | SIMPLE | vw | ref | fk_cache_vw_video_website1 | fk_cache_vw_video_website1 | 4 | const | 8643 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | mtc | eq_ref | PRIMARY,content_id | PRIMARY | 4 | gtf.vw.media_id | 1 | Using where | +------+-------------+-------+--------+----------------------------------+----------------------------------+---------+-----------------+------+----------------------------------------------+
それにもかかわらず、これは通常モードで非常に正常に実行されますが、ピーク負荷でデータベースを曲げます。
このスクリプトは、システムのすべての可能な部分の「時期尚早な」最適化を目的としない開発方法論が適用されるシステムで役立ちます。
そして、最初の最適化が明らかなボトルネックで実行され、その後-システムの動作中に検出された場合。