发布于2026-07-02 阅读(0)
扫一扫,手机访问
PDO事务还真不是调个beginTransaction就完事的活,不少开发者在这上面吃过亏。真正卡人的地方,集中在配置、错误捕获、边界控制和兜底逻辑这四个点上。哪一点没照顾到,上线后就可能留下数据不一致的隐患。
咱们先看第一点:错误模式得设对。
PDO默认的PDO::ERRMODE_SILENT模式,看着挺安静——execute()或query()失败了只返回个false,连个异常都不抛。这意味着什么?你辛辛苦苦写的try-catch结构,根本抓不住SQL本身的错误,比如字段名敲错了、表不存在了、权限不够了。最后你只能手动去查errorInfo(),但说实话,大多数人不会特意去做这件事。结果就是:没报错,数据却凭空消失了。
正确的做法是,建立连接后立刻设置:$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)。顺手的话,再把PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC也加上,省得每次fetch()都要写参数。记住,不设这个,你的catch只能捕获到连接失败那种级别的异常,真正的SQL执行错误会直接溜过去。
接下来,事务的三个动作一个都不能少。
PDO默认是自动提交的,autocommit为true。在这种状态下调用beginTransaction(),其实是个空操作——你发出去的SQL还是立即生效了。事务真正生效的前提,是显式地把自动提交功能关掉。
具体怎么操作?可以在构造连接时就配好:new PDO($dsn, $user, $pass, [PDO::ATTR_AUTOCOMMIT => false])。或者连接后立刻运行:$pdo->setAttribute(PDO::ATTR_AUTOCOMMIT, false)。这里有个细节要注意:commit()和rollback()执行完后,会隐式地把autocommit重置为true。所以,如果你想连续执行多个事务,每个事务开始前都必须重新调用beginTransaction()。漏掉任何一步——比如只写了beginTransaction()却没关autocommit——整个事务就是形同虚设的。
最关键的一步来了:异常处理。
很多人写事务就只记得beginTransaction()和commit(),中间该有的异常处理却被忽略了。这其实等于白做了事务——一旦中间某步操作失败,比如网络突然中断、磁盘写满了、SQL语法报错,后续代码就不会执行,commit()也永远不会被调用。结果就是,数据库连接里一直挂着一个未完成的事务,这个事务可能会锁住数据表,阻塞其他请求,严重时甚至会拖垮整个数据库。
正确的写法是:用try包住所有数据库操作,在catch块里的第一行就写上$pdo->rollback()。千万别依赖finally,因为在这个块里你没办法判断是该提交还是该回滚,事务的状态已经丢失了。另外,如果事务跨越了多个函数调用,一定要确保异常能够透出到最外层的事务块,否则回滚操作会被跳过。
最后一个容易被忽略的点:事务里别什么都往里塞。
query()执行的是纯字符串SQL,不走预处理。如果你在事务中执行了DROP TABLE或ALTER TABLE这类DDL语句,MySQL会自动帮你提交当前事务(InnoDB引擎下DDL是自动提交的)。这样一来,你后续写的rollback()就彻底失效了。
事务内应该只做DML操作:INSERT、UPDATE、DELETE,以及SELECT ... FOR UPDATE。还要避免在里面做文件读写、HTTP请求、sleep()这些耗时操作,它们会长时间持有锁,增加死锁的风险。至于选prepare()还是query(),如果不确定要不要复用语句,统一用prepare()加execute()的组合;对于不需要用户输入的简单语句,比如"SELECT COUNT(*) FROM user",直接用query()就足够了,轻量且没有额外开销。

说到底,事务真正的复杂点不在语法本身,而在于它和数据库引擎行为、PHP异常传播机制、HTTP请求生命周期这三者之间的耦合。一次没被捕获的异常,一次没重置的autocommit,一次混进来的DDL,这些都可能让原本应该原子化的操作,变成一个半途而废的残局。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8