在数据库事务中运行整个 php 应用程序的理论和实践缺点是什么,以确保脚本中引起的任何意外错误或异常都会恢复数据库中所做的每个更改,从而避免由于以下原因而出现的状态:未完成的脚本,一些表已更新,另一些则没有?显然这似乎不是也不会被推荐为良好实践,但我想详细了解原因。
最佳答案
数据库事务确保多个操作遵守 ACID 属性:
原子 - 这是您在问题中提到的属性,事务中的每个操作要么成功,要么全部失败;
一致 - 此属性确保数据库状态始终有效;
隔离 - 此属性确保并发事务(即来自不同连接的事务)像串行执行一样发生;和
持久 - 一旦提交,更改就是永久性的。
为了确保第三个属性“隔离”,MySQL 等 RDBMS 系统会执行“锁定”来确保,例如,一个事务不会在另一事务写入记录时写入记录正在从中读取(当一条记录被锁定时,其他事务必须等待锁被释放才能继续)。
如果您的事务过长,则会导致过度锁定和过度等待。它甚至可能导致不必要的死锁,即事务正在等待彼此持有的锁,并且在至少一个回滚之前无法继续。
出于性能(和持久性)的原因,您应该努力将事务保持在保持一致性绝对必要的范围内。
关于php - 将整个应用程序封装在数据库事务中,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10914179/