pdo开启事务后必须手动commit()或rollback()，否则连接关闭时变更丢失；事务内sql错误不会自动回滚，需try/catch捕获pdoexception并手动处理；嵌套事务不被支持，应使用savepoint或拆分逻辑；长时间事务会持锁阻塞，非db操作应移至commit后。
pdo开启事务后不自动提交，必须手动调用commit()或rollback()
PHP里PDO默认是自动提交模式（autocommit = true），一旦执行INSERT/UPDATE就立刻落库。要进事务，得先关掉它——但很多人只调beginTransaction()，忘了后续必须显式控制。没commit()，所有变更在连接关闭时直接丢弃；没rollback()又出错，数据就卡在中间状态。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
-
$pdo->setAttribute(PDO::ATTR_AUTOCOMMIT, false)不是必须的，beginTransaction()内部已自动关闭autocommit，别画蛇添足 - 事务块内任何SQL报错（比如唯一键冲突、字段超长）不会自动触发回滚，得靠
try/catch捕获PDOException再手动rollback() - 连接断开、脚本异常终止、超时退出，PDO不会帮你回滚——除非你注册了
register_shutdown_function()兜底（但有风险，见下条）
事务里执行SELECT查不到自己刚INSERT的数据？检查隔离级别和fetch模式
MySQL默认事务隔离级别是REPEATABLE READ，同一事务内多次SELECT会看到一致快照，但如果你在事务中插入一行又立刻SELECT查不到，大概率是用了PDO::FETCH_OBJ或PDO::FETCH_ASSOC却没检查fetch()返回值是否为false，误以为没查到数据。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认是否真没查到：打印
$stmt->rowCount()，别只看fetch()结果 - 避免在事务中依赖“刚插完就能查到”的逻辑，尤其跨表关联时，优先用
lastInsertId()拿主键，而不是再查一遍 - 如需读己写（read-your-writes），且确定无并发写冲突，可临时设
$pdo->exec("SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED")，但注意这不改变当前事务的快照起点
嵌套事务在PDO里不被支持，beginTransaction()连续调用会报错
PDO本身不实现保存点（savepoint），所谓“嵌套事务”只是应用层模拟。连续两次调beginTransaction()会抛出PDOException: There is already an active transaction。有人试图用try/catch吞掉这个错假装支持嵌套，结果一出错就全回滚，破坏业务语义。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
savepoint替代：MySQL支持SAVEPOINT sp1、ROLLBACK TO sp1，PDO可直接exec()执行，但需自己维护栈结构 - 更稳妥的做法是拆分逻辑：把可能独立回滚的子操作抽成单独函数，由外层事务统一决策是否执行
- 不要在循环体里反复
beginTransaction()，哪怕每次只做一条INSERT——开销大，还容易漏commit()
长时间事务导致锁表、连接堆积，commit()前别做IO或sleep
事务开启后，MySQL会对涉及的行/页加锁，直到commit()或rollback()。如果你在beginTransaction()和commit()之间调API、读文件、等缓存失效、甚至usleep(100000)，锁就一直挂着，轻则慢查询堆积，重则整个表被堵死。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 把所有非数据库操作（如发邮件、写日志、调外部HTTP）移到
commit()之后——哪怕失败也只影响外围，不影响数据一致性 - 事务内SQL尽量用绑定参数，避免拼接字符串引发语法错误导致漏
catch，进而跳过rollback() - 用
SHOW ENGINE INNODB STATUS\G查TRANSACTIONS段，确认有没有lock wait或运行时间过长的事务
事务不是保险箱，是锁的开关。开多大、开多久，得自己算清楚——尤其当SQL里混着FOR UPDATE或LOCK IN SHARE MODE的时候，一个没注意，整条链路就卡住了。
