次のタイプの低速クエリが大量に発生している 130 万行の非常にトラフィックの多いテーブルがあります。
UPDATE app_info SET data1=269223, data2=0, data3=164, last_update='2012-08-30'
WHERE slice_id=7636 AND app_id=375 AND user_id=21012286 AND mode_id=1;
それでも、このクエリの説明計画は最適な計画を示しています (主キーを使用しています)。
explain select * from app_info
where slice_id=7636 and app_id=375 and user_id=21012286 and mode_id=1\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: app_info
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 18
ref: const,const,const,const
rows: 1
Extra:
スロークエリログは次のとおりです。
Time: 120830 3:23:37
# User@Host: rest_service[rest_service] @ app01.peak.mindjolt.com [10.0.0.174]
# Thread_id: 10091395 Schema: platform Last_errno: 0 Killed: 0
# Query_time: 68.559347 Lock_time: 0.000045 Rows_sent: 0 Rows_examined: 1 Rows_affected: 1 Rows_read: 2
# Bytes_sent: 52 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# InnoDB_trx_id: 575CBF3B9
UPDATE app_info SET data1=269223, data2=0, data3=164, last_update='2012-08-30' WHERE slice_id=7636 AND app_id=375 AND user_id=21012286 AND mode_id=1;
すべてのクエリの約 30% が 1 秒を超えており、すべてのクエリの約 10% が 10 秒を超えています (!)。
このクエリの実行速度が遅い原因は何ですか? 私が知る限り、計画は完璧で、1 行だけがスキャンされ、ロックの取得に時間はかかりませんでした。それで、どうなりますか?
更新: サーバーの仕様を含めるのを忘れました。これは、64G Quad Xeon X5650 2.66GHz (24 コア)、Mysql 5.1.52-rel11.6-log Percona サーバー 11.6、12 ディスク PERC H700 RAID アレイ上にあります。このサーバーは長い間完全に機能していました (稼働時間は 565 日を示しています)。
更新 2: このテーブルには 1 つのインデックスしかありません。これは、タプル (app_id、user_id、slice_id、mode_id) で構成されるプライマリ インデックスです。さらに、これは書き込み専用のマスターであり、他の 3 つのスレーブ サーバーがすべての読み取りを処理します。