性能與PostgreSQL的

，如果你有這樣的事情在查詢什麼是性能方面的條款：性能與PostgreSQL的

... AND x.somfield IN (
33620,262,394,450,673,674,675,2331,2370,2903,4191,4687,5153,6776,6898,6899,7127,7217,7225, 
     7227,7757,8830,8889,8999,9036,9284,9381,9382,9411,9412,9423,10088,10089,10304,10333,10515, 
     10527,10596,10651,11442,12636,12976,13275,14261,14262,14382,14389,14567,14568,15792,16557, 
     17043,17459,17675,17699,17700,17712,18240,18370,18591,18980,19023,19024,19025,19026,19211, 
     19272,20276,20426,20471,20494,20833,21126,21315,21990,22168,22284,22349,22563,22796,23739, 
     24006,24321,24642,24827,24867,25049,25248,25249,25276,25572,25665,26000,26046,26646,26647, 
     26656,27343,27406,27753,28560,28850,29796,29817,30026,30090,31020,31505,32188,32347,32629 
     ,32924,32931,33062,33254,33600,33601,33602,33603,33604,33605,33606,33607,33608,34010,34472, 
     35800,35977,36179,37342,37439,37459,38425,39592,39661,39926,40376,40561,41226,41279,41568, 
     42272,42481,43483,43867,44958,45295,45408,46022,46258) AND ...

應該怎麼避免這種情況還是很好，而且速度不夠快？

感謝

來源

2010-07-09 helle

嘗試執行解釋以檢查查詢執行計劃 – pcent 2010-07-09 13:21:42

你一定要檢查執行計劃。根據數據，它可能會或可能不會「好」。

如果表格足夠大，PG可能會將其轉換爲「數組包含」操作，並決定不使用索引。這可能會導致seq掃描（如果您在此表上沒有其他WHERE條件）。

在某些情況下，OR比IN更好，因爲它是作爲兩個索引掃描執行並組合的。可能不適用於你的情況，因爲你有那麼多的價值。再次依賴於數據。

除非您的表格很小，在這種情況下，您通常需要依賴其他易於編制索引的標準，例如日期，狀態，「類型」等。然後，此IN僅僅是對有限數據的「重新檢查」過濾器。

來源

2010-07-13 05:58:17

如果查詢使用索引的x.somfield - 這將是速度不夠快。

正如之前提到的 - 你應該使用「解釋」和「解釋分析」來真正理解那裏發生了什麼。

來源

2010-07-13 02:03:50 2can

性能與PostgreSQL的

回答

相關問題