MySQL 查詢優(yōu)化器的成本模型是用於估算不同執(zhí)行計(jì)劃開銷的機(jī)制，以選擇成本最低的執(zhí)行路徑。其核心因素包括表的數(shù)據(jù)量、索引的選擇性、I/O 與CPU 成本、統(tǒng)計(jì)信息準(zhǔn)確性等。數(shù)據(jù)量越大，全表掃描成本越高；索引選擇性越高，效率越高；性別字段等低選擇性字段建索引效果差。 I/O 和CPU 成本由內(nèi)部默認(rèn)權(quán)重決定，如順序讀和隨機(jī)讀的區(qū)別。統(tǒng)計(jì)信息不準(zhǔn)確可能導(dǎo)致執(zhí)行計(jì)劃錯(cuò)誤，可通過ANALYZE TABLE 更新。查看執(zhí)行計(jì)劃可用EXPLAIN 或EXPLAIN FORMAT=JSON，其中JSON 格式可顯示read_cost、cpu_cost 和total_cost 等具體數(shù)值。影響優(yōu)化器判斷的方法有：1. 更新統(tǒng)計(jì)信息；2. 強(qiáng)制使用索引（USE INDEX）；3. 調(diào)整系統(tǒng)變量（如innodb_io_capacity）；4. 合理設(shè)計(jì)索引。但應(yīng)慎用FORCE INDEX，以免因數(shù)據(jù)分佈變化導(dǎo)致性能下降。理解成本模型有助於寫出高效SQL 並分析慢查詢。

MySQL 的查詢優(yōu)化器在選擇執(zhí)行計(jì)劃時(shí)，會(huì)根據(jù)一個(gè)成本模型（Cost Model）來估算不同執(zhí)行路徑的開銷。理解這個(gè)模型有助於寫出更高效的SQL 查詢，也能幫助我們更好地分析慢查詢。

什麼是MySQL 查詢優(yōu)化器的成本模型？

簡(jiǎn)單來說，MySQL 優(yōu)化器會(huì)在多個(gè)可能的執(zhí)行計(jì)劃中選擇一個(gè)“成本”最低的方案。這裡的“成本”通常指的是I/O 操作次數(shù)和CPU 使用量的估算值。比如，它會(huì)評(píng)估是走索引快還是全表掃描快，或者用哪個(gè)索引來連接表更劃算。

這個(gè)模型不是固定的，它是基於統(tǒng)計(jì)信息動(dòng)態(tài)計(jì)算的。所以即使你沒改SQL，數(shù)據(jù)分佈或索引變化後，執(zhí)行計(jì)劃也可能變。

成本模型的關(guān)鍵因素有哪些？

了解影響成本的主要因素，能幫你判斷優(yōu)化器為什麼會(huì)選某個(gè)執(zhí)行計(jì)劃。

• 表的數(shù)據(jù)量：行數(shù)越多，全表掃描的成本越高。
• 索引的選擇性：唯一值越多，索引效率越高。例如性別字段加索引意義不大。
• I/O 成本與CPU 成本：MySQL 內(nèi)部為這些操作設(shè)定了默認(rèn)權(quán)重，比如一次順序讀取vs 隨機(jī)讀取。
• 統(tǒng)計(jì)信息是否準(zhǔn)確：如果表沒有ANALYZE TABLE 更新統(tǒng)計(jì)信息，優(yōu)化器可能做出錯(cuò)誤判斷。

舉個(gè)例子：一張訂單表有幾百萬條記錄，但你在order_status 字段上建立了索引。如果大部分訂單狀態(tài)是“已發(fā)貨”，那麼使用該索引可能不會(huì)節(jié)省多少成本，優(yōu)化器可能會(huì)選擇不走索引。

如何查看執(zhí)行計(jì)劃中的成本？

你可以通過EXPLAIN或者EXPLAIN FORMAT=JSON來查看優(yōu)化器對(duì)執(zhí)行計(jì)劃的估算成本。

 EXPLAIN SELECT * FROM orders WHERE status = 'pending';

如果你看到type 是index，並且rows 值比較小，說明優(yōu)化器認(rèn)為走索引比全表掃描更省資源。

在JSON 格式下還能看到更詳細(xì)的cost 值：

 EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE status = 'pending';

輸出結(jié)果裡會(huì)包含類似這樣的字段：

 "cost_info": {
  "read_cost": "1234.56",
  "cpu_cost": "789.01",
  "total_cost": "2023.57"
}

這些數(shù)字就是優(yōu)化器估算的開銷，總成本越低，越有可能被選中。

如何影響優(yōu)化器的成本判斷？

有時(shí)候優(yōu)化器選錯(cuò)了執(zhí)行計(jì)劃，我們可以做一些調(diào)整來引導(dǎo)它。

• 更新統(tǒng)計(jì)信息：運(yùn)行ANALYZE TABLE可以讓優(yōu)化器獲得最新的索引分佈情況。
• 強(qiáng)制使用索引： SELECT * FROM table USE INDEX (index_name)可以繞過優(yōu)化器的判斷。
• 調(diào)整系統(tǒng)變量：如innodb_io_capacity 、 innodb_read_io_threads等參數(shù)會(huì)影響I/O 成本估算。
• 合理設(shè)計(jì)索引：避免冗餘索引，同時(shí)保證高頻查詢字段有合適索引支持。

不過要小心使用FORCE INDEX ，因?yàn)橐坏?shù)據(jù)分佈變了，原來的強(qiáng)制可能反而拖慢性能。

基本上就這些。理解了MySQL 的成本模型之後，你會(huì)發(fā)現(xiàn)很多看似奇怪的執(zhí)行計(jì)劃其實(shí)是有原因的。關(guān)鍵是要結(jié)合實(shí)際數(shù)據(jù)來看，而不是只看語句本身。

以上是了解MySQL查詢優(yōu)化器成本模型的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！