1. 索引優(yōu)化實戰(zhàn)從原理到落地MySQL索引優(yōu)化是數(shù)據(jù)庫性能調優(yōu)的核心戰(zhàn)場。我處理過的90%慢查詢案例最終都通過合理的索引設計得到解決。但很多開發(fā)者對索引的理解停留在加個索引就能快的層面這往往會導致更嚴重的性能問題。1.1 B樹索引的底層運作機制理解索引優(yōu)化必須從B樹開始。與教科書上的抽象圖示不同實際工作中的B樹有這樣幾個關鍵特征非葉子節(jié)點只存儲鍵值和指針不存儲數(shù)據(jù)記錄。這意味著一次磁盤I/O可以加載更多索引條目葉子節(jié)點通過雙向鏈表連接這對范圍查詢至關重要。我曾通過EXPLAIN觀察到當使用WHERE id BETWEEN 100 AND 200時MySQL只需定位到id100的葉子節(jié)點然后沿著鏈表掃描即可默認情況下InnoDB的索引鍵最大長度是767字節(jié)utf8mb4字符集下約191個字符。超出時需要使用前綴索引重要提示在utf8mb4字符集下VARCHAR(255)字段建索引會失敗因為255*41020字節(jié)超過限制。這是新手常踩的坑。1.2 最左前綴原則的實戰(zhàn)應用某電商平臺商品表有聯(lián)合索引(category_id, price, sales)。以下SQL能否命中索引SELECT * FROM products WHERE price 100 ORDER BY sales DESC;答案是否定的。這就像電話簿按姓氏-名字排序時無法快速查找所有叫Michael的人。必須使用索引的最左列-- 有效用法 SELECT * FROM products WHERE category_id5 AND price100 ORDER BY sales DESC; -- 另一種有效用法 SELECT * FROM products WHERE category_id5 ORDER BY price, sales; -- 排序字段符合索引順序1.3 索引選擇性量化你的優(yōu)化決策索引選擇性 不重復索引值數(shù)量 / 表記錄總數(shù)。經(jīng)驗值高于0.2優(yōu)秀候選0.1-0.2考慮使用低于0.1通常不值得計算示例SELECT COUNT(DISTINCT gender)/COUNT(*) AS gender_selectivity, COUNT(DISTINCT city)/COUNT(*) AS city_selectivity FROM users;對于性別這種低選擇性字段加索引往往適得其反。我曾見過在gender字段建索引導致寫入性能下降30%的案例。2. 排序分組深度調優(yōu)超越ORDER BY當執(zhí)行計劃出現(xiàn)Using filesort時就意味著MySQL不得不在內存或磁盤上進行額外排序。以下是幾個關鍵優(yōu)化策略2.1 利用索引消除排序最理想的排序優(yōu)化是不排序。對于這個查詢SELECT * FROM orders WHERE user_id100 ORDER BY create_time DESC;創(chuàng)建索引(user_id, create_time)后數(shù)據(jù)已經(jīng)按需排列EXPLAIN中的Using filesort會消失。2.2 排序緩沖區(qū)調優(yōu)當無法避免filesort時sort_buffer_size就至關重要。通過監(jiān)控可以確定是否需要調整SHOW STATUS LIKE Sort_merge_passes; -- 若值持續(xù)增長需增大sort_buffer_size配置建議默認值4MB通常太小建議設置為2-4MB乘以并發(fā)連接數(shù)但不要超過總內存的5%我在處理一個報表系統(tǒng)時將sort_buffer_size從4MB調整到16MB排序操作耗時從1.2秒降至0.3秒。2.3 分組操作的隱藏成本GROUP BY的常見性能陷阱SELECT category_id, COUNT(*) FROM products GROUP BY category_id;如果category_id沒有索引MySQL會創(chuàng)建臨時表。更糟的是SELECT category_id, COUNT(*) FROM products WHERE price100 GROUP BY category_id;即使category_id有索引WHERE條件可能迫使全表掃描。解決方案是創(chuàng)建聯(lián)合索引(price, category_id)。3. 執(zhí)行計劃深度解析看懂EXPLAIN的每一個字段3.1 type字段的實戰(zhàn)含義執(zhí)行計劃中的type列揭示了訪問方式按性能從優(yōu)到劣system系統(tǒng)表單行查詢const主鍵或唯一索引等值查詢eq_ref關聯(lián)查詢中被驅動表的主鍵匹配ref非唯一索引等值查詢range索引范圍掃描index全索引掃描ALL全表掃描我曾將type從ALL優(yōu)化到range的案例查詢時間從1200ms降到15ms。3.2 Extra字段的關鍵信息Using index覆蓋索引無需回表Using filesort需要額外排序Using temporary使用臨時表Using where存儲引擎返回數(shù)據(jù)后服務器層再過濾特別注意Using index condition這是ICP優(yōu)化(Index Condition Pushdown)MySQL5.6可以將WHERE條件下推到存儲引擎層。4. 高級索引策略應對復雜場景4.1 索引合并的利與弊當WHERE中有多個條件時MySQL可能使用索引合并SELECT * FROM users WHERE mobile13800138000 OR emailtestexample.com;如果有mobile和email的單列索引執(zhí)行計劃會顯示Using union。但要注意只適合高選擇性字段比聯(lián)合索引效率低優(yōu)化器可能判斷錯誤更好的方案是創(chuàng)建函數(shù)索引ALTER TABLE users ADD INDEX idx_contact (mobile, email);4.2 函數(shù)索引的妙用MySQL8.0支持函數(shù)索引-- 為JSON字段創(chuàng)建索引 ALTER TABLE products ADD INDEX idx_specs ((CAST(specs-$.weight AS DECIMAL(10,2)))); -- 為日期部分創(chuàng)建索引 ALTER TABLE orders ADD INDEX idx_order_date ((DATE(create_time)));我曾用這種方法優(yōu)化了一個JSON字段查詢性能提升40倍。5. 實戰(zhàn)問題排查手冊5.1 索引失效的六大場景隱式類型轉換WHERE mobile13800138000mobile是varchar使用函數(shù)WHERE DATE(create_time)2023-01-01前導通配符WHERE name LIKE %張使用OR條件除非所有列都有索引不符合最左前綴索引列參與計算WHERE price101005.2 慢查詢日志分析技巧配置my.cnfslow_query_log1 slow_query_log_file/var/log/mysql/mysql-slow.log long_query_time1 log_queries_not_using_indexes1使用mysqldumpslow工具分析mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log5.3 性能優(yōu)化檢查清單所有查詢都使用EXPLAIN驗證過嗎是否避免了全表掃描排序操作是否利用了索引聯(lián)合索引的列順序是否合理索引選擇性是否足夠高是否定期分析表ANALYZE TABLE更新統(tǒng)計信息6. 參數(shù)調優(yōu)關鍵配置項解析6.1 InnoDB緩沖池優(yōu)化# 建議設置為可用內存的70-80% innodb_buffer_pool_size12G # 緩沖池實例數(shù)建議每GB配1個實例 innodb_buffer_pool_instances12監(jiān)控命中率SELECT (1-(SELECT variable_value FROM performance_schema.global_status WHERE variable_nameInnodb_buffer_pool_reads)/ (SELECT variable_value FROM performance_schema.global_status WHERE variable_nameInnodb_buffer_pool_read_requests))*100 AS hit_ratio;6.2 連接相關參數(shù)# 最大連接數(shù)根據(jù)應用需求調整 max_connections200 # 連接超時秒 wait_timeout300 # 交互式連接超時 interactive_timeout60檢查連接使用情況SHOW STATUS LIKE Threads_%;7. 真實案例電商系統(tǒng)優(yōu)化實錄某電商平臺商品搜索接口響應慢平均800ms優(yōu)化過程原SQLSELECT * FROM products WHERE category_id5 AND status1 ORDER BY sales DESC LIMIT 20;問題診斷雖然有(category_id,status)索引但排序字段不在索引中每次查詢需要排序約10萬條記錄解決方案ALTER TABLE products ADD INDEX idx_cat_status_sales (category_id, status, sales);優(yōu)化結果查詢時間降至50msCPU使用率下降30%8. 未來優(yōu)化方向MySQL8.0新特性降序索引CREATE INDEX idx_desc ON t1 (a DESC, b ASC)隱藏索引ALTER TABLE t1 ALTER INDEX i_idx INVISIBLE函數(shù)索引如前文所述直方圖統(tǒng)計優(yōu)化器能獲得更準確的數(shù)據(jù)分布信息-- 創(chuàng)建直方圖 ANALYZE TABLE products UPDATE HISTOGRAM ON price WITH 100 BUCKETS;這些新特性在特定場景下能帶來顯著性能提升。比如降序索引可以使ORDER BY id DESC避免filesort操作。