会，MySQL服务端在连接异常中断（如网络断开、超时、崩溃）且autocommit=0时自动回滚未提交事务；PDO不主动回滚，仅在下次查询时抛出异常。
PHP 7.2 中使用 PDO 执行事务时，若连接在事务中途意外断开（如网络中断、MySQL 进程崩溃、超时 kill、服务器重启等），事务**不会由 PDO 主动触发回滚**，而是依赖数据库服务端的自动清理机制——是否真正回滚，取决于 MySQL 的连接终止方式和事务当前状态。
连接异常中断时事务的实际行为
当 PHP 进程与 MySQL 的 TCP 连接突然断开（非正常 close），MySQL 服务端会检测到客户端失联，并在一定时间后（由 wait_timeout 或 interactive_timeout 控制）主动关闭该连接。此时：
- 若事务尚未提交（
COMMIT）且未显式回滚（ROLLBACK），MySQL 会**自动回滚该连接上所有未完成的事务更改**； - 该行为由 MySQL 服务端保证，与 PDO 版本（包括 PHP 7.2）、驱动类型（pdo_mysql）或是否启用持久连接无关；
- PDO 层本身不感知“连接已断”，也不会在断连后补发
ROLLBACK—— 它只会在下次执行查询时抛出异常（如SQLSTATE[HY000] [2006] MySQL server has gone away），此时事务早已被 MySQL 清理完毕。
哪些场景下事务可能“未被回滚”？
看似“中断后数据残留”，往往不是事务没回滚，而是事务其实已经提交或发生了隐式提交：
-
DDL 语句触发隐式提交：在事务中执行
CREATE TABLE、DROP INDEX等 DDL 后，MySQL 立即提交此前所有更改，后续断连不影响这部分数据； -
autocommit 被意外开启：若代码中调用过
$pdo->setAttribute(PDO::ATTR_AUTOCOMMIT, true)或执行了SET autocommit = 1，后续每个语句都会独立提交； - 连接复用导致事务上下文错乱：在长生命周期进程（如 CLI 脚本、Swoole Worker）中复用 PDO 实例，但未重置事务状态（例如前次异常未 rollback，下次直接 beginTransaction），可能造成“事务已开启却无感知”；
-
MyISAM 表误用：MyISAM 不支持事务，
beginTransaction()调用成功但实际无效，所有操作立即生效，断连自然无回滚可言。
PHP 7.2 下如何增强事务可靠性
不能依赖“断连=安全回滚”，必须从编码和配置层面主动防御：
立即学习“PHP免费学习笔记（深入）”；
-
始终启用异常模式：
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)，确保 SQL 错误、连接异常都能被try/catch捕获并显式rollback()； -
避免跨请求复用事务连接：PHP-FPM 每次请求是独立进程，天然隔离；但 CLI 或 Swoole 中需确保每次事务使用新连接，或在事务结束后显式
$pdo = null并重建； -
检查存储引擎与 DSN 配置：确认表为 InnoDB，DSN 中包含
;charset=utf8mb4，避免因字符集协商失败导致事务上下文异常； - 关键业务加幂等校验：例如转账后查余额、生成唯一业务流水号，即使极端情况下事务状态模糊，也能通过业务层兜底识别并修复。
验证事务是否真被回滚的小技巧
在开发/测试环境快速判断：
- 手动 kill MySQL 连接：
KILL CONNECTION {id}（先用SHOW PROCESSLIST查 ID），再观察数据是否还原； - 在事务中间插入
sleep(30)，同时在另一终端 kill 对应连接，观察最终数据状态； - 开启 MySQL general_log，查看断连前后是否有
COMMIT或ROLLBACK日志痕迹（注意日志性能开销）。
