I was cruising through my slow query log earlier and one of my larger queries occurs in the log file occasionally. So I'm trying to work to optimize it a bit. One part of the query that I was pretty sure was going to be bad when I wrote it is a long OR statement.

This is preceded by a couple of AND statements. There could possibly be several hundred of these 'OR's

Would this portion of the query be better served by something like this?

OR sitedone_dealer.inventory.id IN(1,4,6,87,34,23,676,9877,45,23,....etc)

I'm open to any suggestion or advice.

Thanks in advance for any guidance!

felgall
—
2010-02-18T22:32:24Z —
#2

Using IN for that could be more efficient an certainly couldn't be less efficient. The use of IN lets the database know that all those comparisons are on the one field far more clearly than using all the OR statements does and so the dtabase may be able to come up with a more efficient way of accessing the data.

It would also make the code easier to read regardless of whether it makes the text more efficient.

Dan_Grossman
—
2010-02-19T00:46:53Z —
#3

The query optimizer should end up producing the same query from either one. I would bet the IN() gets rewritten to a bunch of OR's when it's translated to the intermediate query language the individual storage engine gets passed. Some quick testing and checking EXPLAIN estimates seems to verify there's no speed difference.

So there's no technical difference between the two, do whichever is easier to code or more readable for you.

felgall
—
2010-02-19T01:59:36Z —
#4

Dan_Grossman said:

The query optimizer should end up producing the same query from either one.

I agree. It would be a rather stupid optimiser that didn't. The point I was attempting to make was that if there were to be a difference between the two that the difference would have to give the advantage to the IN version as that is more specific - you are comparing one field to a collection of values rather than just doing a collection of comparisons.

The IN version should produce shorter code which should therefore be easier to read.

Of course if you are dynamically generating the query then the OR version may be simpler to code.

The difference is in the $where =, where I find the second one more easy to read.

Another advantage of IN over OR is that the query is shorter, so you are less likely to run into the maximum query length.Although this is slightly far-fetched it's still true :)

guido2004
—
2010-02-19T11:28:34Z —
#6

Another advantage of IN over OR is that it can be added to the WHERE with an AND, so you don't have to worry about adding ( and ) around the conditions

rustybuddy
—
2010-02-19T13:43:02Z —
#7

Dang, this is my third attempt at responding. The site keeps saying my security token is missing?

Anyways, the query is already coded and working with the OR statement so if there's no performance gain I won't change it. I guess I need to EXPLAIN the entire query and try to find out where the bottleneck is.

Many Thanks for the input!

felgall
—
2010-02-19T18:42:50Z —
#8

ScallioXTX said:

I disagree. At least in PHP the IN queries are easier to code.

That depends on how your code is written to generate the query - I said that using OR may fit better with the way you are generating the code in some instances.

In this case where the OP already has the code working there is no reason for changing it just for the sake of converting to use IN.

wwb_99
—
2010-02-19T20:25:04Z —
#9

Dan_Grossman said:

The query optimizer should end up producing the same query from either one. I would bet the IN() gets rewritten to a bunch of OR's when it's translated to the intermediate query language the individual storage engine gets passed. Some quick testing and checking EXPLAIN estimates seems to verify there's no speed difference.

So there's no technical difference between the two, do whichever is easier to code or more readable for you.

Can't speak to MySql but for MSSQL, IN() gets rewritten as a temp table and a join in general, which is hella fast.

Loomy
—
2010-02-20T13:23:40Z —
#10

Could it be worth experimenting with using BETWEEN where the id are +1 from the previous? (and keep doing ORs or IN() on those that aren't)

Might be worth a try, although I suspect the query optimizer will end up doing the exact same query as with ORs and IN().

r937
—
2010-02-20T15:10:33Z —
#11

wwb_99 said:

Can't speak to MySql but for MSSQL, IN() gets rewritten as a temp table and a join in general, which is hella fast.

that's awesome

but what does MSSQL do for the series of OR conditions?

e39m5
—
2010-02-20T18:39:07Z —
#12

Are those ID's hard coded? If they're coming from another query, you could use a Subquery or Join to speed up to code.

Dr_John
—
2010-02-20T23:54:52Z —
#13

It seems a bit strange to me to have written a query like that. Where do these IDs come from? If they just happen to be all the existing IDs in the database, then I think you're doing it wrong. If they are from a known subset with a common feature, again you're doing it wrong.

I too wonder if a join is the correct answer.

wwb_99
—
2010-02-22T00:33:42Z —
#14

r937 said:

that's awesome

but what does MSSQL do for the series of OR conditions?

Logically, in is the same as a big list (X or Y or Z . . )

r937
—
2010-02-22T00:34:46Z —
#15

so, logically, it creates a temp table in that case too?

wwb_99
—
2010-02-22T12:41:15Z —
#16

Can't really say, not horribly familiar with the internals of the MySql query parsing and optimization. Or if MySql even has in-memory temp tables these days.

r937
—
2010-02-22T12:49:45Z —
#17

no, i was asking about msqql, you said mssql creates a temp table for an IN list, and i was asking whether mssql creates a temp table for a series of OR conditions as well

i realize that this is a mysql thread but the mssql example is relevant in that it would show how different sql can lead to different execution paths...

wwb_99
—
2010-02-22T14:18:22Z —
#18

Gotcha. Answer is that I think it optimizes both clauses the same under the hood at the end of the day.

MickoZ
—
2010-02-24T23:35:52Z —
#19

This would all depend on the internal of MySQL and that could change from version to version too in theory. That is a reason that I sometime write code a way I feel the "right way" (which can be subjective!), unless there is a real need to optimize for a specific version or a real need to optimize over the reading quality for example. The "right way" might get a good chance overtime to be optimized as well if not already.

I would personally be more interested in the comparison of performance with EXISTS and IN with a subquery on the same table with an equivalent condition (at least I have noticed difference with some DBMS in the past even if it was the same condition). But that is another topic.

However the "IN" version is also shorter in length. Therefore less data to send to the MySQL server. If it was an heavily used query, it could improve the performance for that part of the process.

Another thought, you could as well test it yourself with a lot of your OR condition. Make sure when you run your query to use SQL_NO_CACHE, else they might both run at the same speed because the result has been cached.

You can also analyze the query with DESCRIBE.

I personally tried a simple version on my side and both the "multiple OR" and the "IN" versions had the same execution plan with a "range" search type. So there is a good chance they will be optimized the same way by the MySQL server.

You might let us know what you find.

rustybuddy
—
2010-02-25T13:42:16Z —
#20

A JOIN may very well be the most proper solution. I'll look into this further and let you guys know the result.

The OR is composed of a SELECT all from a table that holds only the id's used in the OR statement. The id's in this table relate to a separate database full of products. Each dealer only has access to a certain number of products in the main product database.

I'll have another look at the query and see if a JOIN is the more proper solution.