如何“醫(yī)治”一條慢SQL？
前言
"蘇工，訂單列表又崩了！"
接到電話時(shí)，我對著監(jiān)控大屏上999ms的SQL響應(yīng)時(shí)間哭笑不得。
幾年來，我發(fā)現(xiàn)一個(gè)定律：所有SQL問題都是在凌晨三點(diǎn)爆發(fā)！
今天抽絲剝繭，教你用架構(gòu)師的思維給慢SQL開刀手術(shù)。
希望對你會有所幫助。
1.術(shù)前檢查：找準(zhǔn)病灶
1.1 EXPLAIN 查看執(zhí)行計(jì)劃
使用EXPLAIN查看SQL語句的執(zhí)行計(jì)劃，相當(dāng)于給SQL拍了張X光。
下面是一個(gè)典型的SQL問題，它是某電商平臺歷史訂單查詢的SQL語句：
SELECT *
FROM orders o
LEFTJOINusers u ON o.user_id = u.id
LEFTJOIN products p ON o.product_id = p.id
WHERE o.create_time > '2023-01-01'
AND u.vip_level > 3
AND p.category_id IN (5,8)
ORDERBY o.amount DESC
LIMIT1000,20;使用EXPLAIN關(guān)鍵字查看執(zhí)行計(jì)劃的結(jié)果如下：
+----+-------------+-------+------+---------------+------+---------+------+---------+---------------------------------+
| id | select_type | table | type | possible_keys | key | rows | Extra| key_len |
+----+-------------+-------+------+---------------+------+---------+------+---------+---------------------------------+
| 1 | SIMPLE | o | ALL | idx_user_time | NULL | 1987400 | Using where; Using filesort |
| 1 | SIMPLE | u | ALL | PRIMARY | NULL | 100000 | Using where |
| 1 | SIMPLE | p | ALL | PRIMARY | NULL | 50000 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+---------+---------------------------------+診斷報(bào)告：
- 全表掃描三連擊（type=ALL）
- filesort暴力排序（內(nèi)存警告）
- 索引全軍覆沒
2.手術(shù)方案：精準(zhǔn)打擊
2.1 單表代謝手術(shù)
如果通過執(zhí)行計(jì)劃查到是索引有問題，我們就需要單獨(dú)優(yōu)化索引。
病根：JSON字段索引失效
錯(cuò)誤用法：
ALTER TABLE users ADD INDEX idx_extend ((extend_info->'$.is_vip'));extend_info字段是JSON類型的字段，即使創(chuàng)建了索引，索引也會丟失。
正解姿勢（MySQL 8.0+）：
ALTER TABLE users ADD INDEX idx_vip_level (vip_level);
ALTER TABLE orders ADD INDEX idx_create_user (create_time, user_id) COMMENT '組合索引覆蓋查詢';創(chuàng)建組合索引覆蓋查詢。
2.2 血管疏通術(shù)
卡點(diǎn)分析：
原始join順序是：
orders → users → products優(yōu)化后的方案：
(子查詢過濾users) → products → orders調(diào)整執(zhí)行順序，用小表驅(qū)動(dòng)大表。
重寫后的SQL：
SELECT o.*
FROM products p
INNERJOIN (
SELECT o.id, o.amount, o.create_time
FROM orders o
WHERE o.create_time > '2023-01-01'
) o ON p.id = o.product_id
INNERJOIN (
SELECTid
FROMusers
WHERE vip_level > 3
) u ON o.user_id = u.id
WHERE p.category_id IN (5,8)
ORDERBY o.amount DESC
LIMIT1000,20;術(shù)后效果：
- 先掃小表（users過濾后只有100條）
- 消除冗余字段傳輸
- 減少Join時(shí)臨時(shí)表生成
2.3 開顱手術(shù)
通過執(zhí)行計(jì)劃鎖定了問題，走錯(cuò)索引了，該怎么處理呢？
可以通過FORCE INDEX強(qiáng)制指定索引：
SELECT /*+ INDEX(o idx_create_user) */
o.id, o.amount
FROM orders o FORCE INDEX (idx_create_user)
WHERE o.create_time > '2023-01-01';使用衍生表加速：
SELECT *
FROM (
SELECTid, amount
FROM orders
WHERE create_time > '2023-01-01'
ORDERBY amount DESC
LIMIT1020
) tmp
ORDERBY amount DESC
LIMIT1000,20;醫(yī)囑：
- 警惕OR導(dǎo)致的索引失效
- 用覆蓋索引避免回表查詢
- CTE表達(dá)式謹(jǐn)慎使用
2.4 生命體征監(jiān)測
查看索引使用：
SHOW INDEX FROM orders;監(jiān)控索引使用率：
SELECT object_schema, object_name, index_name,
count_read, count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL;3.術(shù)后護(hù)理：體系化治理
3.1 SQL消毒中心
需要制定優(yōu)秀的代碼規(guī)范，否則可能會出現(xiàn)全表掃描的問題。
在日常工作中，我們要盡可能減少Java代碼感染源。
MyBatis危險(xiǎn)寫法：
@Select("SELECT * FROM orders WHERE #{condition}")
List<Order> findByCondition(@Param("condition") String condition);condition參數(shù)可以傳入任何內(nèi)容，如何傳入了1=1，可能會導(dǎo)致查詢所有的數(shù)據(jù)，走全表掃描，讓查詢效率變得非常低。
正確做法（參數(shù)化查詢）：
@Select("SELECT * FROM orders WHERE create_time > #{time}")
List<Order> findByTime(@Param("time") Date time);消毒方案：
- SQL審核平臺接入（如Yearning）
- MyBatis攔截器攔截全表更新
- 自動(dòng)化EXPLAIN分析流水線
3.2 查殺大表癌癥
如果遇到大表的癌癥病例，可以用分庫分表的方案解決。
病歷案例：3億訂單表終極解決方案
// Sharding-JDBC分片配置
spring.shardingsphere.rules.sharding.tables.orders.actual-data-nodes=ds$0..1.orders_$->{2020..2023}
spring.shardingsphere.rules.sharding.tables.orders.table-strategy.standard.sharding-column=create_time
spring.shardingsphere.rules.sharding.tables.orders.table-strategy.standard.sharding-algorithm-name=time_range化療方案：
- 時(shí)間維度分片（2020~2023年度表）
- 用戶ID取模分庫
- 冷熱分離（OSS歸檔歷史數(shù)據(jù)）
醫(yī)囑總結(jié)
優(yōu)化三板斧：
- 定位：慢查詢?nèi)罩?執(zhí)行計(jì)劃分析
- 切割：化繁為簡拆分多步執(zhí)行
- 重建：符合業(yè)務(wù)場景的數(shù)據(jù)結(jié)構(gòu)
避坑口訣：
- 索引不是銀彈，覆蓋才是王道
- Join水深，能拆就拆
- Order By+Limit≠分頁優(yōu)化
最后送上蘇三的傳秘方：當(dāng)你優(yōu)化SQL到懷疑人生時(shí)，不妨試試這三味藥：
- 刪業(yè)務(wù)邏輯
- 加緩存
- 換數(shù)據(jù)庫
保證藥到病除（老板打不打死你我就不管了，哈哈哈）！
