postgresql中使用IN子句的性能
发布时间：2020-12-13 15:55:31 所属栏目：百科 来源：网络整理
导读：如果您在查询中有类似的内容,那么性能方面有哪些： ... 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,
|
如果您在查询中有类似的内容,那么性能方面有哪些：
... 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 ... 我应该避免这种情况还是可以而且足够快？ 谢谢 解决方法
你当然想检查执行计划.根据数据,它可能是也可能不是“好的”.
如果表足够大,PG可能会将其转换为“数组包含”操作,并决定不对其使用索引.这可能会导致seq扫描(如果此表上没有其他WHERE条件). 在某些情况下,OR优于IN,因为它是作为两个索引扫描执行并组合的.但是在你的情况下可能不适用,因为那里有很多值.同样,取决于数据. 除非您的表很小,否则在这种情况下,您通常需要依赖其他易于索引的标准,例如日期,状态,“类型”等.然后,此IN仅仅是对有限数据的“重新检查”过滤器. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |