使用主键分块从大表中删除时仍然会看到锁等待超时

Question

我有一个分布式应用程序,可以将数百万条记录记录到MySQL.有时每天一百万或一周,具体取决于用户.

我最近重写了一个"清除"系统,可以自动删除过时的记录.它每12小时运行一次,并根据用户设置的规则清除数据.由于数据库通常平均可以包含5000多万条记录,因此我设计了查询以使用主键分块.

每个删除查询仅按主键扫描有限数量的行.根据我的理解,这减少了"包含"其他条件所需的锁的数量.然后,下一个删除查询将在几秒钟后运行.

但是,我们的许多用户仍然看到"锁定等待超时",他们总是回到清除查询.

DELETE FROM prism_data WHERE prism_data.id >= 7564001 AND prism_data.id < 7568001 AND prism_data.epoch <= '1388566847'

以下是引擎状态报告的一部分:

mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1248, 1 row lock(s)
MySQL thread id 458, OS thread handle 0x7efed0c62700, query id 779832 localhost 127.0.0.1 prism updating
DELETE FROM prism_data WHERE prism_data.id >= 7564001 AND prism_data.id < 7568001 AND prism_data.epoch <= '1388566847'
------- TRX HAS BEEN WAITING 37 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 606 n bits 1272 index `epoch` of table `prism`.`prism_data` trx id 208A7E lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 52d7d976; asc R  v;;
 1: len 4; hex 00000001; asc     ;;

就这样你有了,这是表格的架构:

CREATE TABLE IF NOT EXISTS `prism_data` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `epoch` int(10) unsigned NOT NULL,
  `action_id` int(10) unsigned NOT NULL,
  `player_id` int(10) unsigned NOT NULL,
  `world_id` int(10) unsigned NOT NULL,
  `x` int(11) NOT NULL,
  `y` int(11) NOT NULL,
  `z` int(11) NOT NULL,
  `block_id` mediumint(5) DEFAULT NULL,
  `block_subid` mediumint(5) DEFAULT NULL,
  `old_block_id` mediumint(5) DEFAULT NULL,
  `old_block_subid` mediumint(5) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `epoch` (`epoch`),
  KEY `location` (`world_id`,`x`,`z`,`y`,`action_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

增加锁定等待超时通常会有所帮助,但令人惊讶的是,减少每次清除查询扫描的记录范围似乎没有什么区别.有些用户无权更改mysql设置.有什么我可以做的,以改善我们删除记录的方式,以避免导致锁定等待超时？

更新每条评论的附加信息:

我们的一位用户报告了此错误:

[13:43:47 INFO]: [Prism]: Database connection error: Lock wait timeout exceeded; try restarting transaction
[13:43:47 WARN]: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
[13:43:47 WARN]:        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
[13:43:47 WARN]:        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3593)
[13:43:47 WARN]:        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3525)
[13:43:47 WARN]:        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1986)
[13:43:47 WARN]:        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2140)
[13:43:47 WARN]:        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2620)
[13:43:47 WARN]:        at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1662)
[13:43:47 WARN]:        at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1581)
[13:43:47 WARN]:        at me.botsko.prism.actionlibs.ActionsQuery.delete(ActionsQuery.java:346)
[13:43:47 WARN]:        at me.botsko.prism.purge.PurgeTask.run(PurgeTask.java:84)

并立即运行SHOW FULL PROCESSLIST,只显示一个有效的清除查询:

http://i.imgur.com/DxL4Rk1.png

链接到错误提到的代码

Answer 1

您可以使用INFORMATION_SCHEMA.LOCK_WAITS和INNODB_TRX表找到阻止DELETE的源查询.

SELECT r.trx_id waiting_trx_id,  
       r.trx_mysql_thread_id waiting_thread,
       r.trx_query waiting_query,
       b.trx_id blocking_trx_id, 
       b.trx_mysql_thread_id blocking_thread,
       b.trx_query blocking_query
   FROM       information_schema.innodb_lock_waits w
   INNER JOIN information_schema.innodb_trx b  ON  
    b.trx_id = w.blocking_trx_id
  INNER JOIN information_schema.innodb_trx r  ON  
    r.trx_id = w.requesting_trx_id;

有关详细信息,请参阅"示例14.2识别阻止事务"下的http://dev.mysql.com/doc/refman/5.5/en/innodb-information-schema.html#innodb-information-schema-examples.

重新评论和截图:

因为它blocking_query是NULL,这告诉我另一个线程完成了它的查询,但保留了它的锁.

事务将保持锁定直到事务结束,即使它不再处理任何给定的查询.

您应该在完成工作后立即执行COMMIT或ROLLBACK事务.这将减少锁的持续时间,并减少阻塞其他线程的机会.

另一个提示:听起来你已经开发出了与pt-archiver相同的工具.例如:

$ pt-archiver h=localhost,D=mydatabase,t=prism_data
    --purge --bulk-delete --commit-each --limit 1000 --where "epoch <= 1388566847"

将在1000行的块中循环遍历尽可能多的块,每次都提交.