MySQL のスローログ監視の誤報問題の分析と解決

以前は、さまざまな理由により、一部のアラームは真剣に受け止められませんでした。最近、休暇中に、すぐにいくつかの潜在的な人的要因を排除し、データベースのスローログアラームが少しおかしいことに気付きました。主な兆候は、スローログアラームが真実ではなかったことです。アラームのインスタントメッセージリマインダーを受け取った後、しばらくしてデータベースにアクセスして確認したところ、スローログのパフォーマンスはそれほど悪くないことがわかりました（しきい値を60に設定しました）。

コード レベルでロジックを数回チェックした結果、明らかな問題は見つかりませんでした。しかし、数回の試行後も問題は解決しませんでした。このことが、問題を修正するきっかけとなり、原因を詳しく調べることにしました。

バックエンドは ORM ベースのモデルを使用し、データはモデル MySQL_slowlog_sql_history に対応するテーブルに保存されます。

コード レベルには次のロジックがあります。

MySQL_slowlog_sql_history.objects.filter(create_time__gt='2020-01-29 11:00:00'、Query_time_pct_95__gt=60)

渡される時間は動的で、しきい値は 60 秒です。予想どおり、アラームがトリガーされた場合は問題が発生しているはずです。

さらに検証するために、しきい値時間を 600 に変更しましたが、それでもエラーが報告され、実行に 7 ～ 8 秒かかる遅いクエリが報告されました。

ORM によって解析された SQL を取得するためにデバッグを使用しました。

SELECT ... `mysql_slowlog_sql_history`.`create_time`、`mysql_slowlog_sql_history`.`memo` 
`mysql_slowlog_sql_history` から 
WHERE (`mysql_slowlog_sql_history`.`create_time` > '2020-01-29 11:00:00' AND `mysql_slowlog_sql_history`.`Query_time_pct_95` > '600') LIMIT 21; 
引数=(u'202​​0-01-29 11:00:00', u'600')

SQLを見ても問題はありません。

クライアント側で実行したところ、問題なく動作し、600 秒以上かかった結果のみがフィルター処理されました。

mysql_slowlog_sql_history から ip_addr、db_port を選択 
create_time>'2020-01-29 00:00:00' かつ Query_time_pct_95 > 600 の場合;

この結果を見て、私はその理由は何だったのかを考え始めました。

モデルのフィールド定義を見て理解し始め、すぐに検証しました。

説明のために、テスト テーブル test_dummy を作成しました。

テーブル test_dummy(id int primary key auto_increment,Query_time_pct_95 varchar(100)) を作成します。

いくつかのデータを初期化します。

test_dummy(Query_time_pct_95) に値('8.83736'),('7.70056'),('5.09871'),('4.32582') を挿入します。
+----+-------------------+
| id | クエリ時間 PCT 95 |
+----+-------------------+
| 1 | 8.83736 |
| 4 | 7.70056 |
| 7 | 5.09871 |
| 10 | 4.32582 |
+----+-------------------+
セット内の 4 行 (0.00 秒)

次に、次の 2 つのステートメントを使用して比較テストを実行します。

mysql> test_dummy から * を選択します。ここで、Query_time_pct_95>600;
空のセット (0.00 秒)

mysql> test_dummy から * を選択します。Query_time_pct_95>'600';
+----+-------------------+
| id | クエリ時間 PCT 95 |
+----+-------------------+
| 1 | 8.837364 |
| 2 | 7.700558 |
+----+-------------------+
セット内の 2 行 (0.00 秒)

整数値を使用すると結果が返されませんが、文字型を使用すると、一致する結果が最も左端の一致パターンに従ってフィルタリングされることがわかります。これは、データベース レベルでの浮動小数点数の処理が依然として大きく異なることを意味します。

したがって、この問題の簡単な解決策は、データベース レベルでデータ テーブル タイプを float に変更することであり、これによる精度の低下への影響はごくわずかです。

再度検証したところ、問題は再発しませんでした。

上記は、MySQL のスロー ログ監視の誤報問題の詳細な分析と解決方法です。MySQL のスロー ログ監視の誤報の詳細については、123WORDPRESS.COM の他の関連記事をご覧ください。