FrankenPHP Worker模式下未回滚事务致部署后数据丢失，有人遇到过吗？

问题背景 #

使用FrankenPHP的Worker模式运行应用，某脚本逻辑为：满足特定条件时执行BEGIN TRANSACTION → SELECT → INSERT → COMMIT操作，但未满足条件时忘记调用ROLLBACK。

事件时间线 #

• 向生产环境部署新代码
• 用户访问脚本未满足条件→事务启动，但未执行COMMIT或ROLLBACK
• 后续用户访问满足条件→数据成功提交约20次
• 次日，所有已提交记录全部消失，数据库回到部署后初始状态，phpMyAdmin导出也无数据痕迹

关键信息 #

• 运行在FrankenPHP Worker模式（持久化进程）下
• 挂起事务未关闭时，其他会话仍可查询到数据

问题与解答 #

1. 未回滚的事务是否会导致Worker进程重启后后续提交的数据消失？ #

会。FrankenPHP Worker模式是持久化进程，数据库连接会被进程复用：

• 后续满足条件的COMMIT实际是提交了当前未关闭事务内的所有操作，但这些提交并未真正写入数据库持久化存储，仅在当前事务会话内可见（这也解释了其他会话能查到数据的现象——数据库读隔离级别允许读取对应事务状态的数据）。
• 当Worker进程重启时，数据库会自动回滚这个未关闭的事务，所有基于该连接提交的操作都会被撤销，最终导致所有相关数据消失。

2. 有人在FrankenPHP或PHP-FPM Worker模式下遇到过类似情况吗？ #

是的，这类问题在持久化进程+复用数据库连接的场景中十分常见：

• PHP-FPM的Worker进程同样会复用数据库连接，若请求结束时未关闭事务，后续请求会在同一个事务上下文内操作，一旦进程重启，未提交/未回滚的事务会被自动回滚，引发数据丢失。
• FrankenPHP的Worker模式属于长生命周期进程，连接复用逻辑与PHP-FPM类似，社区中已有不少开发者反馈过类似的事务未清理导致的数据异常问题。

3. 除了确保调用ROLLBACK外，还有哪些预防此类问题的最佳实践？ #

• 事务自动清理逻辑：在脚本执行结束时，检查当前连接是否存在未关闭的事务，自动执行ROLLBACK。比如PHP中可注册register_shutdown_function，在请求结束时统一处理未关闭的事务。
• 按需使用短连接：若业务允许，每次请求结束后主动关闭数据库连接，避免连接复用带来的事务上下文污染。但此方法会增加连接开销，需权衡性能。
• 数据库事务超时配置：在数据库（如MySQL）中设置innodb_lock_wait_timeout或wait_timeout，自动终止长时间未完成的事务，避免事务长期挂起。
• 使用ORM管理事务：借助Doctrine、Eloquent等ORM框架的事务管理功能，ORM通常会自动处理事务的开启与关闭，避免手动操作遗漏。
• 进程定期重启：在FrankenPHP/PHP-FPM中配置进程最大请求数（如PHP-FPM的pm.max_requests），当进程处理一定数量请求后自动重启，避免长期复用连接导致的上下文积累问题。

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