MySQL死锁错误1213是因事务间加锁顺序不一致形成环路所致，非隔离级别过低引起；盲目提升至SERIALIZABLE会加剧争抢，应统一加锁顺序、缩短事务时间并定位锁竞争路径。
死锁错误 1213 出现时，光调隔离级别没用
MySQL 报 1213（Deadlock found when trying to get lock）不是事务隔离级别太低导致的，而是多个事务以不同顺序加锁、互相等待形成的环路。比如 A 事务先锁行 1 再锁行 2，B 事务先锁行 2 再锁行 1 —— 隔离级别再高也救不了。这时候盲目把 isolation_level 改成 SERIALIZABLE 只会让问题更糟：串行化会扩大锁范围，反而加剧争抢。
真正该做的是：定位锁竞争路径 + 统一加锁顺序 + 缩短事务时间。隔离级别只是辅助手段，不是解药。
SQLALCHEMY_ENGINE_OPTIONS['isolation_level'] 的实际生效范围
这个配置只影响新获取的数据库连接的**默认事务隔离级别**，且仅在连接首次建立或从连接池取出时应用。它不会覆盖已开启的事务，也不会动态改变正在运行的事务行为。
- PostgreSQL 默认是
READ COMMITTED，设成REPEATABLE READ后，同一事务内多次SELECT确保结果一致，但对INSERT/UPDATE加锁行为影响有限 - MySQL InnoDB 中，
REPEATABLE READ是默认值，但它的“可重复读”靠 MVCC 实现，SELECT ... FOR UPDATE仍可能触发间隙锁，这才是死锁高发区 - SQLite 不支持运行时改隔离级别，
isolation_level在 SQLite 上被忽略
所以别指望靠改这一个配置就防住死锁；它更适合解决“不可重复读”类一致性问题，而非并发写冲突。
立即学习“Python免费学习笔记（深入）”；
高并发订单/库存场景下，with_for_update() 必须配合明确的锁顺序
你看到的典型死锁代码往往长这样：
inventory = Inventory.query.filter_by(product_id=pid).with_for_update().first() # … 然后扣减、创建订单
问题在于：如果两个请求分别查 product_id=101 和 product_id=102，但一个按 101→102 顺序加锁，另一个按 102→101，就极易死锁。解决方案不是关掉锁，而是强制统一顺序：
- 对涉及多行更新的业务，提前按主键升序排序后再查，例如：
Inventory.query.filter(Inventory.product_id.in_([101,102])).order_by(Inventory.product_id).with_for_update().all() - 避免在事务中跨表、跨条件分批查询加锁；尽量一次性查全、锁全
- 用
with_for_update(nowait=True)主动失败快抛错，比卡死更好观察和重试 - 事务体必须极短——查库存、扣减、建单、提交，中间不能夹杂 HTTP 调用、日志 IO 或复杂计算
动态提升关键事务隔离级别，比全局配置更安全
全局设成 SERIALIZABLE 会导致所有查询变慢、锁升级、连接池耗尽。真要保强一致性，只应在特定事务里临时提级：
from sqlalchemy import text
with db.session.begin():
# 显式提级（MySQL/PostgreSQL 语法略有差异）
db.session.execute(text("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE"))
# 接着执行核心操作
inventory = Inventory.query.filter_by(product_id=pid).with_for_update().first()
# ...
注意三点：
- MySQL 8.0+ 才支持
SET TRANSACTION在事务内生效；老版本只能靠引擎级配置 - PostgreSQL 的
SERIALIZABLE会触发序列化失败异常（SerializationFailure），需捕获并重试，不能当普通异常回滚了事 - 这种写法绕过了 Flask-SQLAlchemy 的自动 session 管理，务必确保
begin()和异常处理配对，否则连接可能泄漏
最易被忽略的一点：死锁不是配置问题，是数据访问模式问题。哪怕隔离级别设得再高，只要加锁顺序不一致、事务跨度不合理，照样死锁。排查时优先看 SHOW ENGINE INNODB STATUS 输出的 last deadlock section，而不是翻配置文档。
