"超級攻略：如何快速排查和優(yōu)化慢SQL，提升系統(tǒng)速度！"
慢查詢指的是數(shù)據(jù)庫中執(zhí)行時間超過指定閾值的 SQL 語句。不同業(yè)務(wù)場景下，這個閾值通常各不相同。在我們公司內(nèi)部，這個閾值被設(shè)定為 1 秒鐘。也就是說，任何執(zhí)行時間超過 1 秒的 SQL 語句都會被視為慢查詢。
對慢查詢進行問題排查通常分為以下幾個步驟：
發(fā)現(xiàn)問題
一般而言，慢查詢問題相對容易發(fā)現(xiàn)。如果有完善的監(jiān)控體系，系統(tǒng)會定期統(tǒng)計慢 SQL 并通過報警方式提醒。
此外，如果使用了某些數(shù)據(jù)庫中間件，例如 TDDL，它們通常會記錄慢 SQL 的日志：
Cause: ERR-CODE: [TDDL-4202][ERR_SQL_QUERY_TIMEOUT] Slow query leads to a timeout exception, please contact DBA to check slow sql. SocketTimout:12000 ms,如果只依賴 MySQL 本身的話
- 找到 MySQL 的配置文件 my.cnf（或者在 Windows 系統(tǒng)下可能是 my.ini），通常它們位于 MySQL 安裝目錄下的 etc 或 conf 文件夾中。
- 啟用慢查詢?nèi)罩竟δ埽赫堈业揭韵屡渲庙棧⑵淙∠⑨專ㄈ绻炎⑨專_保以下行存在或添加到配置文件中：
slow_query_log = 1
slow_query_log_file = /path/to/slow-query.log
long_query_time = 1- 保存配置文件后，重新啟動 MySQL 服務(wù)以使配置生效。
- 查看慢查詢?nèi)罩荆菏褂梦谋揪庉嬈鞔蜷_慢查詢?nèi)罩疚募Ｈ罩疚募穆窂酵ǔＴ谂渲梦募兄付ā＠纾?Linux 系統(tǒng)上，可以使用以下命令來查看慢查詢?nèi)罩疚募?/li>
sudo vi /var/log/mysql/mysql-slow.log請將路徑 /var/log/mysql/mysql-slow.log 替換為實際配置文件中指定的慢查詢?nèi)罩韭窂健Ｅ渲猛戤吅螅琈ySQL 會將執(zhí)行時間超過 long_query_time 設(shè)置的時間閾值的 SQL 語句記錄到慢查詢?nèi)罩局小?/p>
如果有慢 SQL，內(nèi)容如下：
# Time: 2023-06-04T12:00:00.123456Z
# User@Host: hollis[192.168.0.1]:3306
# Query_time: 2.345678 Lock_time: 0.012345 Rows_sent: 10 Rows_examined: 100
SET timestamp=1650000000;
SELECT * FROM orders WHERE status = 'pending' ORDER BY gmt_created DESC;定位問題
在上述各種監(jiān)控、報警和日志中，我們可以定位到具體的慢 SQL 語句，然后可以進一步分析為什么這個 SQL 語句執(zhí)行緩慢，主要是排查以下幾個可能的原因：
- 缺少索引：沒有為查詢涉及的列創(chuàng)建適當?shù)乃饕瑢?dǎo)致數(shù)據(jù)庫需要全表掃描來找到匹配的行。
- 錯誤使用索引：使用了索引但不符合最左前綴原則，或者索引選擇度不高（即索引列的唯一性不夠高），導(dǎo)致數(shù)據(jù)庫選擇不到最優(yōu)的索引執(zhí)行查詢。
- 查詢字段過多：SELECT 語句中涉及的字段過多，增加了數(shù)據(jù)傳輸和處理的開銷。
- 多次回表：查詢執(zhí)行過程中需要多次訪問磁盤以獲取額外的數(shù)據(jù)行，例如對主鍵的索引掃描后，需要再次根據(jù)主鍵進行查詢。
- 多表連接：涉及多個表的 JOIN 操作，若 JOIN 條件不合適或者 JOIN 操作沒有利用到索引，會導(dǎo)致性能下降。
- 深度分頁：需要返回大量數(shù)據(jù)中的某一頁，但是沒有合適的方式來快速定位和獲取這一頁數(shù)據(jù)。
- 其他因素：還有一些其他可能的原因，例如復(fù)雜的子查詢、數(shù)據(jù)庫服務(wù)器負載高、SQL 語句寫法不佳等。
針對這些問題，可以通過優(yōu)化數(shù)據(jù)庫表結(jié)構(gòu)、添加合適的索引、優(yōu)化 SQL 語句寫法、調(diào)整數(shù)據(jù)庫配置參數(shù)等方式來改進 SQL 查詢的性能。
對于大多數(shù)情況下的慢 SQL 問題，通常可以通過執(zhí)行計劃分析找出根本原因，主要集中在索引和 JOIN 操作上。
解決問題
定位問題后，解決問題就會變得容易起來。
實際上，最大的挑戰(zhàn)不在于解決問題，而在于準確定位問題。因為一旦問題被準確定位，解決起來就變得相對簡單。例如，缺少索引就添加索引，JOIN 操作過多就進行拆分。這里不再詳細展開。
