在面試中，SQL 調優經常是被問及的問題，它可以考察候選人對于 SQL 整體性能優化的理解和掌握程度。一般來說，SQL 調優的步驟可以從以下幾個方面入手。

首先，需要準確地定位問題。在面試中，最好能結合具體的業務場景進行說明，例如某次線下報警引發的慢 SQL 問題，或者性能分析顯示接口響應時間過長，根源是 SQL 查詢效率不佳。無論何種情況，都需要提供背景信息。

一旦問題定位清楚，接下來就是對問題進行深入分析。

首先，需要通過各類監控平臺或工具準確定位到具體的 SQL 語句。一旦定位到了問題 SQL 語句，我們就能夠確定是哪張表或哪個 SQL 語句執行速度較慢。

接下來，需要進行詳細的分析。一般而言，一個 SQL 語句執行緩慢可能有以下幾種原因：

• 索引未被有效利用
• 多表連接
• 查詢字段過多
• 數據量過大的表
• 索引的區分度不高
• 數據庫連接數不足
• 數據庫表結構不合理
• 數據庫的 IO 或 CPU 負載過高
• 數據庫參數設置不合理
• 長時間事務
• 鎖競爭引起的等待

因此，進行一次全面的 SQL 調優時，通常需要考慮上述幾個因素，往往會涉及其中一個或多個問題。接下來，需要逐一進行優化。

首先，處理索引失效的問題通常要通過執行計劃分析是否正確使用了索引，以及使用的索引是否符合預期。如果索引設計不合理或者因索引失效導致問題，可以考慮調整索引設計，修改 SQL 語句，或者強制使用特定的索引。索引失效可參考歷史文章：

一篇文章聊透索引失效有哪些情況及如何解決

其次，多表連接（join）也是導致 SQL 執行速度較慢的常見原因之一。

接下來，如果是索引區分度不高的話，這個其實也和索引不合理有關，但是其實到底快不快，用不用索引，并不是因為區分度高不高導致，其實還是索引掃描的行數的成本導致。所以，有的時候不能認為區分度不高就一定會效率低，或者一定就不適合創建索引。

查詢字段過多有時是因為誤用了 SELECT *，通常情況下，查詢少于 100 個字段并不是大問題，除非字段數目極多。解決方法有兩種：一是只查詢必要的字段，避免檢索不需要的數據；二是進行垂直分表，將數據分散存儲到多張表中。然而，這種分散存儲也可能帶來需要多表連接的問題，因此在進行分表時需要考慮數據冗余的問題。對于表中數據量過大的情況，一般而言，超過 1000 萬條數據會顯著降低查詢效率，即使使用了索引也可能不夠快。因此，解決方法包括：

• 數據歸檔，將歷史數據移出，只保留近期數據，例如保留最近半年數據，將半年前的數據歸檔。
• 分庫分表或分區。通過拆分數據來分散存儲，以減輕單表的壓力。具體的分庫分表和分區策略可以參考詳細文檔，這里不展開說明。
• 考慮使用支持大數據量查詢的第三方數據庫，如 OceanBase、TiDB，或者搜索引擎如 Elasticsearch 等。

數據庫連接數不足也需要具體分析原因。可能原因包括：業務量過大，單個數據庫無法處理；存在慢 SQL 或長事務導致連接阻塞，進而影響其他查詢速度。

數據庫表結構不合理通常是一個關鍵原因。例如，某些字段可能存儲了過長的內容，或者沒有進行合理的數據冗余，導致需要頻繁進行多表關聯查詢等情況。解決方法通常是進行數據庫結構重構或者進行表的分解。

數據庫的 IO 或 CPU 負載較高也是常見問題。當數據庫整體的 IO 或 CPU 負載升高時，查詢速度可能會受到影響。因此，需要深入分析其背后的原因，并采取相應的解決策略。

存在長事務和慢 SQL 類似，都會占用數據庫連接，從而導致其他請求需要等待。

鎖競爭導致的等待則是在高并發情況下，多個請求競爭共享資源，導致鎖定等待時間增長，進而使得 SQL 執行變慢。這一過程也可以參考上述導致 CPU 負載過高的問題。

數據庫參數設置不合理也是常見問題，針對具體的業務場景進行適當的參數調整，有時能顯著提升 SQL 的效率。例如調整內存大小、緩存大小以及線程池大小等。

擴展知識

參數優化

假設我們管理的數據庫名為 mydb，其中包含一個名為 mytable 的 InnoDB 表。該表具有自增主鍵 id，一個整數類型的 age 字段和一個字符串類型的 name 字段。我們希望對這個表進行優化。

首先，可以通過執行 SHOW VARIABLES LIKE 'innodb%'; 命令來查看當前 InnoDB 參數的設置情況。這些參數涵蓋了緩沖池大小、刷新間隔、日志大小等核心設置。

接下來，我們可以嘗試調整幾個關鍵參數來優化數據庫的性能：

innodb_buffer_pool_size：緩沖池大小是 InnoDB 存儲引擎的關鍵參數之一，它決定了 InnoDB 存儲引擎在內存中使用的大小。通常建議將該參數設置為系統可用內存的 70% 到 80%。例如，如果系統總內存為 8GB，我們可以將 innodb_buffer_pool_size 設置為 6GB。在 MySQL 中，可以使用以下命令進行設置：

SET GLOBAL innodb_buffer_pool_size=6G;

**innodb_read_io_threads 和 innodb_write_io_threads **這兩個參數控制著 InnoDB 存儲引擎的 I/O 線程數量。一般建議將它們設置為可用 CPU 核心數的一半。在 MySQL 中，您可以使用以下命令進行設置：

SET GLOBAL innodb_read_io_threads=4;
SET GLOBAL innodb_write_io_threads=4;

innodb_log_file_size 參數控制著事務日志文件的大小。默認情況下，其大小為 5M，這通常是不足夠的。在 MySQL 中，您可以使用以下命令進行設置：

SET GLOBAL innodb_log_file_size=1G;

一般來說，在設置這個參數之前，需要先進行數據采樣。可以觀察業務高峰期約 2 小時內寫入的日志量，然后將這個量作為設定事務日志文件大小的參考。通常建議設置為約 1G 左右，或者系統內存的 1/4。

區分度不高的字段建索引一定沒用嗎

關于剛剛上面提到的區分度不高的字段。做一下解釋，這個區分度不高的字段建立索引到底有沒有用呢。

答案是：不一定。

在某些情況下，索引的有效性并不完全取決于字段的區分度。例如，如果一個表中包含性別字段，僅有兩個可能的取值：男和女，那么通常情況下這個字段的區分度較低，使用該字段進行查詢可能無法有效地過濾大量數據，從而無法充分發揮索引的優勢。

然而，也存在特殊情況。比如，如果性別的分布比例是 95%男性和 5%女性，那么當以"女"作為性別查詢條件時，依然可以通過索引進行高效查詢，因為它能夠快速過濾掉大部分數據，從而提升性能。這種情況下，索引仍然能夠顯著提升效率。

類似的情況在任務表中也很常見。例如，任務表中可能有一個狀態字段，大多數任務處于成功狀態（SUCCESS），只有少數任務處于初始化狀態（INIT）。在這種情況下，為狀態字段添加索引可以顯著提升查詢效率。這樣在掃描任務表并執行任務時，可以更快地定位到需要處理的任務。

因此，雖然字段的區分度影響索引的效果，但在特定的數據分布情況下，即使區分度不高的字段仍然可以通過索引來優化查詢性能。