Rails生产环境偶发查询未执行问题排查求助

这种偶发的问题确实头疼，结合你的场景，我整理了几种可能导致日志输出DELETE语句但数据库记录没删除的情况：

• 事务隐式回滚：如果current_user.promo_code_uses.delete_all是在某个Rails事务块（ActiveRecord::Base.transaction）中执行的，后续代码如果抛出了未被捕获的异常（哪怕是很隐蔽的，比如某个关联操作失败、外部API调用超时等），会触发整个事务回滚。虽然DELETE的SQL日志已经输出（Rails会在生成SQL语句时就打日志，而非执行成功后），但事务没提交，数据库自然不会有变化。建议检查这段代码所在的上下文是否包含事务，同时排查是否有隐藏的异常被上层逻辑吞掉了。

• 数据库连接池/路由问题：

  • 如果你的应用用了读写分离，偶发的路由错误可能把DELETE请求发到了从库（而从库通常是只读的），但数据库驱动没有抛出明确报错，导致日志显示SQL执行但实际没生效。
  • 连接池配置不合理（比如连接超时、连接泄漏）可能导致使用了状态异常的数据库连接，比如某个连接的事务未正确结束，DELETE执行在了未提交的事务上下文里。

• 数据库层面的约束/触发器干扰：

  • 数据库中如果给promo_code表设置了触发器，比如DELETE操作触发了INSERT逻辑把记录恢复，或者触发了其他修改操作，会导致看起来记录没被删除。
  • 如果启用了行级安全策略（RLS），偶发的条件不满足（比如基于时间、用户状态的策略）可能导致当前数据库用户没有权限执行这条DELETE，而数据库没有返回明确报错（取决于配置）。

• 日志的误导性：Rails的SQL日志是在语句准备完成后就输出的，并非在数据库执行成功之后。如果遇到数据库驱动的偶发bug、网络闪断，SQL可能根本没发送到数据库，但日志依然会输出。这种情况通常伴随隐性的连接错误，但如果驱动没有正确上报，日志就不会显示报错。

• 并发冲突或锁问题：

  • 同一时刻有其他进程/线程对这条记录加了排他锁，导致DELETE操作超时或被阻塞，最终没有执行成功，但日志已经提前输出。
  • 如果数据库的锁等待超时设置得较短，可能DELETE请求在等待锁的过程中超时，却没有在日志中留下报错信息。

• 复制延迟的误解：如果你检查数据库记录时查询的是从库，而DELETE操作是在主库执行的，可能主从复制存在延迟，导致短时间内从库还能看到这条记录，误以为DELETE没生效。这种情况要确认你查询的是主库还是从库。

内容的提问来源于stack exchange，提问作者Zain Awais