我正在觀察我試圖理解的奇怪行為。
MySQL版本：5.7.33 我有以下查詢：
select * from a_table where time>='2022-05-10' and guid in (102,512,11,35,623,6,21,673);
a_table 在 time、guid 上有主鍵，在 guid 上有索引
我上面寫的查詢具有非常好的性能，根據(jù)解釋計(jì)劃是 using index condition;使用地點(diǎn)；使用MRR
當(dāng)我增加 in 子句中的值數(shù)量時(shí)，效能會(huì)受到顯著影響。
經(jīng)過一些演練，我得到了一個(gè)粗略的數(shù)字。對(duì)於小於 ~14500 的值，解釋計(jì)劃與上方相同。對(duì)於高於此值的數(shù)量，僅解釋計(jì)劃 使用 where 並且需要永遠(yuǎn)運(yùn)行我的查詢。
換句話說(shuō)，例如，如果我在 in 子句中放入 14,000 個(gè)值，則解釋計(jì)劃將具有預(yù)期的 14,000 行。但是，如果我在 in 子句中放入 15,000 個(gè)值，則解釋有 221200324 行。我的整個(gè)表中甚至沒有這麼多行。
我正在嘗試?yán)斫膺@種行為，並知道是否有任何方法可以解決這個(gè)問題。
謝謝
1
0
0
當(dāng) IN() 謂詞中有大量值時(shí)，它會(huì)在查詢最佳化步驟中使用更多記憶體。在某些情況下這被認(rèn)為是一個(gè)問題，因此最近版本的 MySQL 設(shè)定了最大記憶體限制（預(yù)設(shè)為 8MB）。
如果優(yōu)化器發(fā)現(xiàn)它需要比限制更多的內(nèi)存，則查詢中沒有其他條件可以用來(lái)優(yōu)化，它會(huì)放棄嘗試優(yōu)化，並訴諸表掃描。我推斷您的表統(tǒng)計(jì)資料實(shí)際上顯示該表有約 2.21 億行（儘管表統(tǒng)計(jì)資料是不準(zhǔn)確的估計(jì)）。
我不能說(shuō)我知道給定值列表需要多少記憶體的確切公式，但根據(jù)您觀察到的行為，我們可以猜測(cè)，考慮到14k 項(xiàng)，每個(gè)項(xiàng)平均約為600 位元組有效，但更多則無(wú)效。
您可以設(shè)定range_optimizer_max_mem_size = 0來(lái)停用記憶體限制。這會(huì)產(chǎn)生過度使用記憶體的風(fēng)險(xiǎn)，但它避免了優(yōu)化器「放棄」。我們?cè)谏弦环莨ぷ髦性谒?MySQL 實(shí)例上設(shè)定了這個(gè)值，因?yàn)槲覀儫o(wú)法教育開發(fā)人員避免在他們的查詢中建立巨大的值清單。
