删除行导致锁超时
当我尝试从表中删除行时,我不断收到这些错误。这里的特殊情况是我可能同时运行5个进程。
该表本身是一个 Innodb 表,约有 450 万行。我的 WHERE 子句中使用的列没有索引。其他指数均按预期运行。
这是在事务中完成的,首先我删除记录,然后插入替换记录,并且只有当所有记录都被插入时才应该提交事务。
错误信息:
查询错误:超过锁定等待超时;尝试在执行 DELETE FROM tablename WHERE column=value 时重新启动事务
在此处引用的列上创建索引是否有帮助?我应该显式锁定行吗?
我发现了一些有问题的附加信息 #64653 但我认为它没有涵盖我的情况完全。
是否确定是 DELETE 语句导致了错误,还是查询中的其他语句导致了错误? DELETE 语句是第一个语句,因此看起来合乎逻辑,但我不确定。
I keep getting these errors when trying to delete rows from a table. The special case here is that I may be running 5 processes at the same time.
The table itself is an Innodb table with ~4.5 million rows. I do not have an index on the column used in my WHERE clause. Other indices are working as supposed to.
It's being done within a transcation, first I delete records, then I insert replacing records, and only if all records are inserted should the transaction be commited.
Error message:
Query error: Lock wait timeout exceeded; try restarting transaction while executing DELETE FROM tablename WHERE column=value
Would it help to create an index on the referenced column here? Should I explicitly lock the rows?
I have found some additional information in question #64653 but I don't think it covers my situation fully.
Is it certain that it is the DELETE statement that is causing the error, or could it be other statements in the query? The DELETE statement is the first one so it seems logical but I'm not sure.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
索引肯定会有帮助。如果您尝试替换已删除的记录,我建议您修改查询以使用更新而不是 DELETE 后跟 INSERT(如果可能):
An index would definitely help. If you are trying to replace deleted records I would recommend you modify your query to use an update instead of a DELETE followed by an INSERT, if possible:
索引绝对有帮助。我曾经研究过一个包含用户数据的数据库。有时 Web 前端和用户删除会出现问题。白天它工作得很好(尽管花了很长时间)。但在下午晚些时候,它有时会超时,因为数据库服务器由于一天结束的处理而承受更多负载。
破坏了受影响列上的索引,从此一切顺利。
An index definitely helps. I once worked on a DB containing user data. There was sometimes a problem with the web front end and user deletion. During the day it worked fine (although it took quite long). But in the late afternoon it sometimes timed out, because the DB server was under more load due to end of day processing.
Whacked an index on the affected column and everything ran smoothly from there on.