共計 3788 個字符，預(yù)計需要花費 10 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章給大家分享的是有關(guān) MySQL 數(shù)據(jù)庫執(zhí)行 analyze 采集信息的示例的內(nèi)容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考。一起跟隨丸趣 TV 小編過來看看吧。

故障簡介

之前，有開發(fā)找到我，說應(yīng)用的某個功能查詢比以前慢了很多，讓開發(fā)提供了慢的 SQL 語句，去對應(yīng)的 MySQL 數(shù)據(jù)庫看了一下執(zhí)行計劃，發(fā)現(xiàn)執(zhí)行計劃不正確，第一反應(yīng)就是其中的一個表的統(tǒng)計信息不準確，導(dǎo)致了 SQL 語句的執(zhí)行計劃不對，從高效的查詢 SQL 變成了慢 SQL。定位到問題之后，自然是 analyze 一下，重新采集信息，這個時候，卻發(fā)現(xiàn) analyze 表上的所有 select 突然卡住了，不返回任何結(jié)果，然后應(yīng)用就炸了，各種告警短信。

故障復(fù)盤

當時執(zhí)行 analyze 操作的是一個 slave 庫，受影響基本是 select 查詢，所以在這里模擬的是查詢操作。

創(chuàng)建模擬表

mysql select * from t_test_1;
+----+--------+-------+--------+
| id | name | name2 | status |
+----+--------+-------+--------+
| 1 | name1 | 1001 | 0 |
| 2 | name1 | 1002 | 1 |
| 3 | name1 | 1003 | 1 |
| 4 | name1 | 1004 | 0 |
| 5 | name1 | 1005 | 1 |
| 6 | name1 | 1006 | 0 |
| 7 | name1 | 1007 | 2 |
| 8 | name1 | 1008 | 0 |
| 9 | name1 | 1009 | 1 |
| 10 | name10 | 1001 | 0 |
+----+--------+-------+--------+
10 rows in set (0.00 sec) 復(fù)制代碼 

模擬慢查詢，由于這里數(shù)據(jù)量不夠，所以用 sleep 代替
session1：模擬慢查詢

mysql select sleep(1000) from t_test_1; 復(fù)制代碼 

session2：模擬收集表的統(tǒng)計信息

mysql analyze table t_test_1; 復(fù)制代碼 

session3：模擬執(zhí)行 analyze 命令之后，在 t_test_1 表上執(zhí)行一次 select 查詢

mysql select * from t_test_1 where id=5; 復(fù)制代碼 

session4：查詢所有會話信息

mysql select * from processlist order by time desc;
+----+------+-----------+--------------------+---------+------+-------------------------+----------------------------------------------+
| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO |
+----+------+-----------+--------------------+---------+------+-------------------------+----------------------------------------------+
| 21 | root | localhost | testdb | Query | 242 | User sleep | select sleep(1000) from t_test_1 |
| 23 | root | localhost | testdb | Query | 180 | Waiting for table flush | analyze table t_test_1 |
| 24 | root | localhost | testdb | Query | 3 | Waiting for table flush | select * from t_test_1 where id=5 |
| 22 | root | localhost | information_schema | Query | 0 | executing | select * from processlist order by time desc |
+----+------+-----------+--------------------+---------+------+-------------------------+----------------------------------------------+
4 rows in set (0.00 sec) 復(fù)制代碼 

從 session4 獲取的所有會話信息中，可以看到有 2 個會話的狀態(tài)是“Waiting for table flush”。

Waiting for table flush 原因

當 MySQL 數(shù)據(jù)庫做 FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, or OPTIMIZE TABLE 這些操作時，會導(dǎo)致需要關(guān)閉內(nèi)存中的表，并重新打開表，加載新的表結(jié)構(gòu)到內(nèi)存中。但是關(guān)閉表，需要等待所有的在這個表上的操作執(zhí)行結(jié)束（包括 select,insert,update,lock table 等），所以當有一個特別慢的 select 一直在執(zhí)行時，analyze table 命令就一直無法結(jié)束。

解決方案

既然知道什么原因?qū)е碌?Waiting for table flush，就開始定位慢 sql 語句。在這里可以看到我們執(zhí)行的是采集 t_test_1 表，所以需要查詢涉及 t_test_1 表的慢查詢，并且執(zhí)行時間比 analyze table t_test_1 的執(zhí)行時間還要長的會話。

mysql select * from processlist where info like %t_test_1% and time =(select time from processlist where id=23) order by time desc;
+----+------+-----------+--------+---------+------+-------------------------+----------------------------------+
| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO |
+----+------+-----------+--------+---------+------+-------------------------+----------------------------------+
| 21 | root | localhost | testdb | Query | 1187 | User sleep | select sleep(1000) from t_test_1 |
| 23 | root | localhost | testdb | Query | 1125 | Waiting for table flush | analyze table t_test_1 |
+----+------+-----------+--------+---------+------+-------------------------+----------------------------------+
2 rows in set (0.37 sec) 復(fù)制代碼 

用上面的 sql 語句，很容易就定位到 id=21 的會話，導(dǎo)致 analyze table t_test_1 卡死，所以需要 kill 掉會話 21.

mysql kill 21;
Query OK, 0 rows affected (0.01 sec)
mysql show full processlist;
+----+------+-----------+--------------------+---------+------+----------+-----------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+--------------------+---------+------+----------+-----------------------+
| 22 | root | localhost | information_schema | Query | 0 | starting | show full processlist |
| 23 | root | localhost | testdb | Sleep | 1205 | | NULL |
| 24 | root | localhost | testdb | Sleep | 1028 | | NULL |
+----+------+-----------+--------------------+---------+------+----------+-----------------------+
3 rows in set (0.00 sec) 復(fù)制代碼 

殺掉會話，故障解除。

建議

生產(chǎn)執(zhí)行 analyze table 建議
1. 執(zhí)行之前，先估算一下表的數(shù)據(jù)量，根據(jù)經(jīng)驗預(yù)估需要消耗的時間，同時查看是否有采集信息表的慢 SQL，長事務(wù)在執(zhí)行。

2. 避免在業(yè)務(wù)高峰期執(zhí)行 analyze table 進行統(tǒng)計信息采集。

感謝各位的閱讀！關(guān)于 MySQL 數(shù)據(jù)庫執(zhí)行 analyze 采集信息的示例就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！

向 AI 問一下細節(jié)

丸趣 TV 網(wǎng) – 提供最優(yōu)質(zhì)的資源集合！