Oracle IN clause has limit of 1000 for static data,but it accepts unlimited data from sub queries. why?
相关问题
- Can I skip certificate verification oracle utl_htt
- how to calculate sum time with data type char in o
- keeping one connection to DB or opening closing pe
- System.Data.OracleClient not working with 64 bit O
- How can I get rid of dynamic SQL
相关文章
- node连接远程oracle报错
- oracle 11g expdp导出作业调用失败,提示丢包。
- 执行一复杂的SQL语句效率高,还是执行多少简单的语句效率高
- Oracle equivalent of PostgreSQL INSERT…RETURNING *
- Difference between FOR UPDATE OF and FOR UPDATE
- Oracle USING clause best practice
- Is there a method in PL/SQL to convert/encode text
- PHP PDO installation on windows (xampp)
Try using 'exists' than 'in'.You can as well create sub queries using 'exists'.
This is because IN has very poor performance with large number of values in the list. It's just shortcut for OR clause, and at the database level the engine will change IN to OR's.
You should also avoid doing subqueries inside IN clause - better use EXISTS.
It's a restriction on any expression list:
Why 1000? Presumably the implementation needs some kind of limit, and that probably seemed like more than enough. There may well be, or certainly may have been when that limit was set decades ago, a performance reason for the limit as well, particularly as the
IN
is converted to multipleOR
statements by the optimiser in this case (which you can see if you look at the execution plan).I'd struggle to come up with a reasonable scenario that needed to get anywhere near that, with fixed values that couldn't be derived from other data anyway as a subquery.
I suspect it's somewhat related to the logical database limits which say you can't have more than 1000 columns in a table, for instance; since an expression list is used in an insert statement to list both the columns and the values being inserted, the expression list has to be able to match that, but maybe has no reason to exceed it.
Speculation of course... without seeing the internals of the software you're unlikely to get a definitive answer.