場景描述

業務側云數據庫TaurusDB實例上以往執行耗時8秒的查詢，在11:00后耗時超過30秒。

原因分析

1. 查看查詢變慢對應的時間段中，實例CPU監控指標并無飆升情況且使用率一直都較低，因此排除了CPU沖高導致查詢變慢的可能。
2. 分析對應時間段該實例的慢日志，該SQL執行快時其掃描行數為百萬級，當SQL執行慢時其掃描行數為千萬級，與業務確認該表短期內并無大量數據插入，因此推斷執行慢是因為未走索引或選錯索引。且通過EXPLAIN查看該SQL的執行計劃確實是全表掃描。

圖 慢日志

3. 在實例上對該表執行SHOW INDEX FROM檢查三個字段的基數,。

圖 查看基數

可知基數最小的字段“query_date”在聯合索引的第一位，基數最大的字段“group_id”在聯合索引最后一位，而且原SQL包含對“query_date”字段的范圍查詢，導致當索引走到“query_date”就會停止匹配，后面兩個字段已經無序，無法走索引。

所以該SQL本質上只能利用到對“query_date”這一列的索引，而且還有可能因為基數太小，導致優化器成本估計時選擇了全表掃描。

業務重新創建了聯合索引將“group_id”字段放在第一位，“query_date”字段放在最后一位后，查詢耗時符合預期。

解決方案

1. 查詢變慢首先確認是否由于CPU利用率達到性能瓶頸導致執行慢。
2. 庫表結構設計不合理，索引缺失或索引設置不恰當會導致慢SQL。
3. 表數據大批量插入刪除等操作可能會導致統計信息未能及時更新，建議定期執行ANALYZE TABLE防止執行計劃走錯。