WordPress数据库死锁问题求助：执行DELETE语句时触发死锁

[2023年9月29日 09:41:45 UTC] WordPress数据库错误 Deadlock found when trying to get lock; try restarting transaction for query DELETE FROM wp_options WHERE option_name = '_transient_astra-theme-cron-test-ok'，该查询由require('wp-blog-header.php'), wp, WP->main, do_action_ref_array('wp'), WP_Hook->do_action, WP_Hook->apply_filters, Astra_Theme_Background_Updater->install_actions, Astra_Theme_Background_Updater->test_cron, get_transient, delete_option触发。

你执行的REPAIR TABLE wp_option;（注意表名应为wp_options，拼写少了一个s）无法解决死锁问题，因为死锁并非表损坏导致，而是并发事务竞争锁资源引发的。以下是具体可能原因：

• 并发事务操作冲突：同一时间存在多个请求（前端访问、后台操作、Cron任务等）对wp_options表执行读写操作，比如部分请求更新临时缓存（_transient_*类选项），部分请求读取或修改其他选项，不同事务获取锁的顺序不一致，导致循环等待触发死锁。
• Astra主题Cron任务竞争：报错触发路径指向Astra主题后台更新器的Cron测试逻辑，该逻辑运行时会调用delete_option删除临时键。若此时有其他Cron任务或请求也在操作wp_options表（如其他插件的缓存清理、主题/插件更新检测），极易引发锁竞争。
• 数据库事务隔离级别影响：若MySQL事务隔离级别设置过高（默认是REPEATABLE READ，但存在自定义调整的可能），会延长锁的持有时间、扩大锁范围，提升死锁发生概率。
• 缺乏死锁重试逻辑：WordPress核心或Astra主题的代码中，针对delete_option这类操作未添加死锁重试机制，遇到死锁时直接抛出错误，而非自动重试事务。
• 索引缺失或失效：DELETE FROM wp_options WHERE option_name = 'xxx'理论上应使用行锁，但如果option_name字段没有唯一索引（或索引失效），数据库会退化为表锁，此时所有对该表的操作都会竞争表锁，大幅增加死锁可能性。建议检查wp_options表的option_name字段是否存在有效唯一索引。

内容的提问来源于stack exchange，提问作者Waqar Hassan