I have a big DELETE
query (deleting 20M rows from a 600M row table with condition according to indexed column) that is stuck – running already for 17hrs. Because it's an InnoDB table, killing it will result in a rollback, which as far as I understood will at least double the time I've waited so far. I'm trying to figure a way to recover from this situation. I don't care if the query will only update some of the rows it was supposed to, or if it will actually rollback, just that the table won't be corrupted.
The Table:
CREATE TABLE `conv_with` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`user_id_from` int(11) NOT NULL,
`user_id_to` int(11) NOT NULL,
`counter` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `user_id_to` (`user_id_to`,`user_id_from`),
KEY `from` (`user_id_from`)
) ENGINE=InnoDB AUTO_INCREMENT=643019605 DEFAULT CHARSET=utf8
The Delete Query: DELETE FROM conv_with WHERE user_id_from IN (uid1, uid2, ..., uid100000)
Best Answer
You should let the table rollback fully. If you kill the mysqld process, crash recovery will happen anyway.
As far as the DELETE query goes, you may want to execute it in chunks or all-in-one. I would like to suggest an alternate method for deletion. Here is a DELETE JOIN method:
conv_with
Here is the SQL for it
You can either load
conv_with_delete
with all 20M ids, or cycle throughone user_id_from
at a time. Perhaps a stored procedure might work for you.First let's make some sample data:
Here is the creation of the sample data:
OK, the table has 1,966,080 rows. Let's go about deleting anything whose user_id_from is 13 or 23.
OK so the
DELETE JOIN
works in practice manually executed.OK now for the Stored Procedure to Encapsulate This
Let's Test it with :
DELETE JOIN
DELETE JOIN
DELETE JOIN
Here we go:
Hey, not bad. Deleted 131,072 rows in 5.49 seconds. You need to use the stored procedure passing in a comma-separated list of
used_id_from
values.Give it a Try !!!