MySQL Processlist中的統計狀態
我有一個
busy MySQL Server疑問SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592885621) FOR UPDATE
pqr_sess_id表在哪裡Primary Key。當我獨立執行查詢時，它正在完成，
0.00 secs,但我多次觀察到查詢掛起是帶有狀態統計資訊的程序列表。可能是什麼問題，我發現這個查詢在慢日誌中的計數超過 10K 次。
mysql> show full processlist; +------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 2899 | root | 192.168.9.217:49340 | abdulrony | Query | 58 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592885621) FOR UPDATE | | 2977 | root | 192.168.9.217:35082 | abdulrony | Query | 30 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=593059341) FOR UPDATE | | 3010 | root | 192.168.9.217:44607 | abdulrony | Query | 3 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595647701) FOR UPDATE | | 3011 | root | 192.168.9.217:44287 | abdulrony | Query | 33 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=593503321) FOR UPDATE | | 3014 | root | 192.168.9.217:49280 | abdulrony | Query | 3 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595641601) FOR UPDATE | | 3016 | root | 192.168.9.217:60243 | abdulrony | Query | 51 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592248641) FOR UPDATE | | 3033 | root | 192.168.9.217:49695 | abdulrony | Query | 22 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=594780861) FOR UPDATE | | 3034 | root | 192.168.9.217:44473 | abdulrony | Query | 27 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=594503601) FOR UPDATE | | 3038 | root | 192.168.9.217:55093 | abdulrony | Query | 1 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595625241) FOR UPDATE | +------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 22 rows in set (0.00 sec)我知道我可以
optimizer_search_depth通過將其設置為一些低值來進行調整預設值如下，但我有一個涉及查詢的表，所以我認為不會有幫助。SHOW variables like 'optimizer_search_depth'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | optimizer_search_depth | 62 | +------------------------+-------+ 1 row in set (0.00 sec)
如果查詢 thead 停留的時間更長，
statistics則表明伺服器可能正在磁碟綁定執行其他工作。如何減少磁碟綁定：
1）增加innodb_buffer_pool_size的大小
如果您正在使用
Innodb表，那麼當表數據記憶體在 InnoDB 緩衝池中時，可以通過查詢一遍又一遍地處理它，而無需任何磁碟 I/O。使用 innodb_buffer_pool_size 選項指定緩衝池的大小。這個記憶體區域非常重要，繁忙的數據庫通常會指定大約為物理記憶體量的 80% 的大小。
在某些版本的 GNU/Linux 和 Unix 中，使用 Unix fsync() 呼叫（InnoDB 預設使用）和類似方法將文件刷新到磁碟非常慢。如果數據庫寫入性能有問題，請使用設置為 O_DSYNC 的 innodb_flush_method 參數進行基準測試。
增加innodb_log_buffer_size的大小- 設置分配給儲存 InnoDB 預寫日誌條目的緩衝區的記憶體量。對於大型事務，可以將日誌載入到日誌緩衝區中，而不是將日誌寫入磁碟上的日誌文件，直到每次事務送出時刷新日誌緩衝區。如果您在執行時的 show innodb status 輸出中看到大量日誌 I/O，您可能需要為 innodb_log_buffer_size 參數設置更大的值以節省磁碟 I/O。
4）增加用於記憶體表和查詢的記憶體-檢查它們的記憶體命中率檢查並增加這些MySQL變數：
query_cache_size,query_cache_limit,query_cache_min_res_unit,tmp_table_size,join_buffer_size等sort_buffer_size。
- 確保將正確的索引應用於伺服器上的所有表並使用正確的數據類型。
您可以參考這些連結來解決磁碟綁定問題： http ://dev.mysql.com/doc/refman/5.5/en/disk-issues.html https://blogs.oracle.com/luojiach/entry/mysql_innodb_performance_tuning_for
我認為統計狀態令人困惑。前幾天我也遇到了同樣的情況，我搜了google也想出了optimizer_search_depth。但是當我查看 information_schema.innodb_trx 表時，發現這些 SQL 都處於 LOCK WAIT 狀態。這意味著這些查詢只是在等待主鍵上的鎖定，也許您有多個查詢選擇相同的值進行更新。