Mysql deletes data very slowly
1. Preface
My mysql table data volume is about 100 million, and then directly delete a batch of data, deletion operation is extremely slow, after a long time can not be deleted successfully. I'll stop this operation.
2. problem
But the deletion operation is performed again, but when it is executed according to the partition, the problem encountered is that deletion is very fast at the beginning, but the slower the deletion is. The implementation process is as follows:
mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180523; Query OK, 15640 rows affected (1.09 sec) mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180524; Query OK, 15534 rows affected (1.08 sec) mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180525; Query OK, 18189 rows affected (1.90 sec) mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180526; Query OK, 21520 rows affected (1.42 sec) mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180527; Query OK, 18468 rows affected (1.47 sec) mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180528; Query OK, 15444 rows affected (6.64 sec) mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180529; Query OK, 16111 rows affected (58.20 sec) mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180530; Query OK, 16402 rows affected (59.01 sec) mysql> delete from fact_sales_temp where process_id = 181017201954166180 and pay_feed_back_date_Key = 20180531; Query OK, 17129 rows affected (1 min 5.24 sec)
The pay_feed_back_date_Key field is the partition field of the fact_sales_temp table.
3. reasons
Why is it that all operations are performed to delete the same partition, and the data distribution is roughly the same, but the results are different?
My personal guess is as follows:
Although the direct delete operation was not successful, the database has taken some of the eligible data into the buffer. This leads to very fast execution when deleting this part of the data. Conversely, some of the latter data is not added to the buffer, resulting in very slow deletion operations.