Multiple UPDATE in single transaction vs one UPDATE with big WHERE clause - mysql

Question

what is more efficient:
START TRANSACTION
UPDATE mytable SET foo = 'bar' WHERE (col1 = 813242) AND (col2 = 25343);
UPDATE mytable SET foo = 'bar' WHERE (col1 = 312643) AND (col2 = 8353);
UPDATE mytable SET foo = 'bar' WHERE (col1 = 843564) AND (col2 = 41233);
UPDATE mytable SET foo = 'bar' WHERE (col1 = 321312) AND (col2 = 5325);
UPDATE mytable SET foo = 'bar' WHERE (col1 = 554235) AND (col2 = 6321);
... x 10,000 times or more
COMMIT;
or
UPDATE mytable SET foo = 'bar' WHERE
((col1 = 16344) AND (col2 = 5456)) OR
((col1 = 42134) AND (col2 = 5436)) OR
((col1 = 84563) AND (col2 = 2321)) OR
((col1 = 43216) AND (col2 = 4267)) OR
((col1 = 53248) AND (col2 = 6234)) OR
... x 10,000 times or more
Assuming I have UNIQUE index on (col1,col2)
So my guess is 1st option is nice because of index but it's split into multiple queries, 2nd option is nice because it's only one query but on another hand it does full table scan
this is EXPLAIN when not using OR:
type: ref, possible_keys: myindex_UNIQUE, key: myindex_UNIQUE, ref: const
this is EXPLAIN when using OR:
type: ALL, possible_keys: myindex_UNIQUE, key: null, ref: null
and is there any limit for query WHERE clause?
I aim for max speed

Answer 1

Based on the conversation in the comments, a possible solution:
If you have a large table and a list of values to identify the rows to update, you can create a helper table for the list of values.
Based on the example in the question, the table could be something like this:
CREATE TABLE mytable_operation (
col1 INT
, col2 INT
) ENGINE = MEMORY;
Please note, that the create statement contains the ENGINE = MEMORY hint, so the table will be stored in the memory instead of the disk.
Load the values into this table prior the update.
After all values are loaded into the helper table, you can use the following query to update the values in the production table.
UPDATE
mytable
SET
foo = 'bar'
WHERE
EXISTS (SELECT 1 FROM mytable_operation MO WHERE mytable.col1 = MO.col1 AND mytable.col2 = MO.col2)
Of course, you can use any DML statements to manipulate the production data. (UPDATE with joins, DELETE, INSERT..ON DUPLICATE KEY, etc)
When you finished the data manipulation, you can truncate or drop the helper table.
If the amount of rows are slightly larger in the production table, this solution could be faster than the solutions in the question.

Answer 2

I think theoretically the second one will be faster, but it's merely an educated guess.
It's one statement, so it might need less parsing, less initialization, less roundtrips.
The first one might be faster because it uses the index to find the record. But 10.000 index lookups will probably be slower than a full table scan as well, so I think that advantage is gone as well.
One reason multiple statements can be slower, is when you run the separate updates in a loop from a program. In that case, you got 10.000 times the request/response overhead.
As long as you don't do that and just send the update(s) as a single request, I think performance will be similar and any differences will depend on the hardware and configuration of the server, as well as the current load, the amount of data in the table and the number of rows that you update (or will it always be exactly 10.000?). All in all I can't give you an exact answer, but I hope I've given you insight in some of the factors that affect this performance.

Answer 3

use nosql engine for fastest results when inserting/updating
if you want to see how your index is working , replace the update with a SELECT and run it with explain. This should give you an idea if an index is used the way you want
EXPLAIN how to
and don't forget that an index will normally slow down any update/insert
it s useful in the where clause only