在面試中，SQL 調(diào)優(yōu)經(jīng)常是被問及的問題，它可以考察候選人對于 SQL 整體性能優(yōu)化的理解和掌握程度。一般來說，SQL 調(diào)優(yōu)的步驟可以從以下幾個方面入手。
首先，需要準確地定位問題。在面試中，最好能結(jié)合具體的業(yè)務(wù)場景進行說明，例如某次線下報警引發(fā)的慢 SQL 問題，或者性能分析顯示接口響應(yīng)時間過長，根源是 SQL 查詢效率不佳。無論何種情況，都需要提供背景信息。
一旦問題定位清楚，接下來就是對問題進行深入分析。
首先，需要通過各類監(jiān)控平臺或工具準確定位到具體的 SQL 語句。一旦定位到了問題 SQL 語句，我們就能夠確定是哪張表或哪個 SQL 語句執(zhí)行速度較慢。
接下來，需要進行詳細的分析。一般而言，一個 SQL 語句執(zhí)行緩慢可能有以下幾種原因：
索引未被有效利用
多表連接
查詢字段過多
數(shù)據(jù)量過大的表
索引的區(qū)分度不高
數(shù)據(jù)庫連接數(shù)不足
數(shù)據(jù)庫表結(jié)構(gòu)不合理
數(shù)據(jù)庫的 IO 或 CPU 負載過高
數(shù)據(jù)庫參數(shù)設(shè)置不合理
長時間事務(wù)
鎖競爭引起的等待
因此，進行一次全面的 SQL 調(diào)優(yōu)時，通常需要考慮上述幾個因素，往往會涉及其中一個或多個問題。接下來，需要逐一進行優(yōu)化。
首先，處理索引失效的問題通常要通過執(zhí)行計劃分析是否正確使用了索引，以及使用的索引是否符合預(yù)期。如果索引設(shè)計不合理或者因索引失效導(dǎo)致問題，可以考慮調(diào)整索引設(shè)計，修改 SQL 語句，或者強制使用特定的索引。
其次，多表連接（join）也是導(dǎo)致 SQL 執(zhí)行速度較慢的常見原因之一。
接下來，如果是索引區(qū)分度不高的話，這個其實也和索引不合理有關(guān)，但是其實到底快不快，用不用索引，并不是因為區(qū)分度高不高導(dǎo)致，其實還是索引掃描的行數(shù)的成本導(dǎo)致。所以，有的時候不能認為區(qū)分度不高就一定會效率低，或者一定就不適合創(chuàng)建索引。
查詢字段過多有時是因為誤用了?SELECT *，通常情況下，查詢少于 100 個字段并不是大問題，除非字段數(shù)目極多。解決方法有兩種：一是只查詢必要的字段，避免檢索不需要的數(shù)據(jù)；二是進行垂直分表，將數(shù)據(jù)分散存儲到多張表中。然而，這種分散存儲也可能帶來需要多表連接的問題，因此在進行分表時需要考慮數(shù)據(jù)冗余的問題。對于表中數(shù)據(jù)量過大的情況，一般而言，超過 1000 萬條數(shù)據(jù)會顯著降低查詢效率，即使使用了索引也可能不夠快。因此，解決方法包括：
數(shù)據(jù)歸檔，將歷史數(shù)據(jù)移出，只保留近期數(shù)據(jù)，例如保留最近半年數(shù)據(jù)，將半年前的數(shù)據(jù)歸檔。
分庫分表或分區(qū)。通過拆分數(shù)據(jù)來分散存儲，以減輕單表的壓力。具體的分庫分表和分區(qū)策略可以參考詳細文檔，這里不展開說明。
考慮使用支持大數(shù)據(jù)量查詢的第三方數(shù)據(jù)庫，如 OceanBase、TiDB，或者搜索引擎如 Elasticsearch 等。
數(shù)據(jù)庫連接數(shù)不足也需要具體分析原因?？赡茉虬ǎ簶I(yè)務(wù)量過大，單個數(shù)據(jù)庫無法處理；存在慢 SQL 或長事務(wù)導(dǎo)致連接阻塞，進而影響其他查詢速度。
數(shù)據(jù)庫表結(jié)構(gòu)不合理通常是一個關(guān)鍵原因。例如，某些字段可能存儲了過長的內(nèi)容，或者沒有進行合理的數(shù)據(jù)冗余，導(dǎo)致需要頻繁進行多表關(guān)聯(lián)查詢等情況。解決方法通常是進行數(shù)據(jù)庫結(jié)構(gòu)重構(gòu)或者進行表的分解。
數(shù)據(jù)庫的 IO 或 CPU 負載較高也是常見問題。當數(shù)據(jù)庫整體的 IO 或 CPU 負載升高時，查詢速度可能會受到影響。因此，需要深入分析其背后的原因，并采取相應(yīng)的解決策略。
存在長事務(wù)和慢 SQL 類似，都會占用數(shù)據(jù)庫連接，從而導(dǎo)致其他請求需要等待。
鎖競爭導(dǎo)致的等待則是在高并發(fā)情況下，多個請求競爭共享資源，導(dǎo)致鎖定等待時間增長，進而使得 SQL 執(zhí)行變慢。這一過程也可以參考上述導(dǎo)致 CPU 負載過高的問題。
數(shù)據(jù)庫參數(shù)設(shè)置不合理也是常見問題，針對具體的業(yè)務(wù)場景進行適當?shù)膮?shù)調(diào)整，有時能顯著提升 SQL 的效率。例如調(diào)整內(nèi)存大小、緩存大小以及線程池大小等。
擴展知識
參數(shù)優(yōu)化
假設(shè)我們管理的數(shù)據(jù)庫名為 mydb，其中包含一個名為 mytable 的 InnoDB 表。該表具有自增主鍵 id，一個整數(shù)類型的 age 字段和一個字符串類型的 name 字段。我們希望對這個表進行優(yōu)化。
首先，可以通過執(zhí)行?SHOW VARIABLES LIKE 'innodb%';?命令來查看當前 InnoDB 參數(shù)的設(shè)置情況。這些參數(shù)涵蓋了緩沖池大小、刷新間隔、日志大小等核心設(shè)置。
接下來，我們可以嘗試調(diào)整幾個關(guān)鍵參數(shù)來優(yōu)化數(shù)據(jù)庫的性能：
innodb_buffer_pool_size：緩沖池大小是 InnoDB 存儲引擎的關(guān)鍵參數(shù)之一，它決定了 InnoDB 存儲引擎在內(nèi)存中使用的大小。通常建議將該參數(shù)設(shè)置為系統(tǒng)可用內(nèi)存的 70% 到 80%。例如，如果系統(tǒng)總內(nèi)存為 8GB，我們可以將 innodb_buffer_pool_size 設(shè)置為 6GB。在 MySQL 中，可以使用以下命令進行設(shè)置：
復(fù)制SET GLOBAL innodb_buffer_pool_size=6G;
1.
**innodb_read_io_threads?和?innodb_write_io_threads **這兩個參數(shù)控制著 InnoDB 存儲引擎的 I/O 線程數(shù)量。一般建議將它們設(shè)置為可用 CPU 核心數(shù)的一半。在 MySQL 中，您可以使用以下命令進行設(shè)置：
復(fù)制SET GLOBAL innodb_read_io_threads=4; SET GLOBAL innodb_write_io_threads=4;
1.
2.
innodb_log_file_size?參數(shù)控制著事務(wù)日志文件的大小。默認情況下，其大小為 5M，這通常是不足夠的。在 MySQL 中，您可以使用以下命令進行設(shè)置：
復(fù)制SET GLOBAL innodb_log_file_size=1G;
1.
一般來說，在設(shè)置這個參數(shù)之前，需要先進行數(shù)據(jù)采樣。可以觀察業(yè)務(wù)高峰期約 2 小時內(nèi)寫入的日志量，然后將這個量作為設(shè)定事務(wù)日志文件大小的參考。通常建議設(shè)置為約 1G 左右，或者系統(tǒng)內(nèi)存的 1/4。
區(qū)分度不高的字段建索引一定沒用嗎
關(guān)于剛剛上面提到的區(qū)分度不高的字段。做一下解釋，這個區(qū)分度不高的字段建立索引到底有沒有用呢。
答案是：不一定。
在某些情況下，索引的有效性并不完全取決于字段的區(qū)分度。例如，如果一個表中包含性別字段，僅有兩個可能的取值：男和女，那么通常情況下這個字段的區(qū)分度較低，使用該字段進行查詢可能無法有效地過濾大量數(shù)據(jù)，從而無法充分發(fā)揮索引的優(yōu)勢。
然而，也存在特殊情況。比如，如果性別的分布比例是 95%男性和 5%女性，那么當以"女"作為性別查詢條件時，依然可以通過索引進行高效查詢，因為它能夠快速過濾掉大部分數(shù)據(jù)，從而提升性能。這種情況下，索引仍然能夠顯著提升效率。
類似的情況在任務(wù)表中也很常見。例如，任務(wù)表中可能有一個狀態(tài)字段，大多數(shù)任務(wù)處于成功狀態(tài)（SUCCESS），只有少數(shù)任務(wù)處于初始化狀態(tài)（INIT）。在這種情況下，為狀態(tài)字段添加索引可以顯著提升查詢效率。這樣在掃描任務(wù)表并執(zhí)行任務(wù)時，可以更快地定位到需要處理的任務(wù)。
因此，雖然字段的區(qū)分度影響索引的效果，但在特定的數(shù)據(jù)分布情況下，即使區(qū)分度不高的字段仍然可以通過索引來優(yōu)化查詢性能。
