锁行为变化会导致死锁或阻塞，因mysql 8.0对间隙锁判定更严格，非唯一索引下select for update、update where等操作易锁住更大范围，隐式类型转换引发全表扫描与锁升级，需通过performance_schema.data_locks和show engine innodb status实测验证。
锁行为变化是否会导致死锁或阻塞？
不是隔离级别变了，而是 InnoDB 对锁范围的判定更严格了。REPEATABLE READ 本身没被限制，但 SELECT FOR UPDATE、UPDATE WHERE 等语句在 8.0 中更容易锁住间隙（Next-Key Lock），尤其在非唯一索引上。5.7 里“侥幸跑通”的逻辑，在 8.0 下可能直接卡住或触发死锁。
- 典型场景：用非唯一字段
UPDATE t SET x=1 WHERE status='pending'—— 8.0 会锁住整个status值对应的所有间隙，而 5.7 可能只锁匹配行 -
SELECT FOR UPDATE查不到数据时：5.7 往往不加锁或只锁索引项；8.0 默认加间隙锁，后续相同条件的INSERT会被阻塞 -
隐式类型转换（如
WHERE mobile = 13800138000，字段是VARCHAR）：8.0 优化器更早放弃走索引，转为全表扫描+锁升级，锁范围剧增
如何实测关键事务的锁范围？
别只看 SELECT @@transaction_isolation，得查真实锁行为。最直接的方式是观察 performance_schema.data_locks，配合并发压测。
- 在测试环境模拟“查-算-更”流程，同时开两个事务执行冲突操作（如并发更新同一范围）
- 执行
SELECT * FROM performance_schema.data_locks WHERE THREAD_ID IN (SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_COMMAND = 'Sleep')，看锁类型（RECORD / GAP / INSERT_INTENTION）和锁住的INDEX_NAME、LOCK_DATA - 运行
SHOW ENGINE INNODB STATUS\G，重点看TRANSACTIONS和LOCK WAIT段落，确认是否有新增等待链
哪些配置或写法会让锁问题更隐蔽？
innodb_locks_unsafe_for_binlog 在 8.0 中已被彻底移除，所有 SELECT ... FOR UPDATE 都强制走 Next-Key Lock。这意味着：过去靠这个变量“降级”锁行为的业务，现在必须重构逻辑。
- 依赖
SELECT ... LOCK IN SHARE MODE读取后做判断再更新的场景，8.0 下容易因锁范围扩大导致并发吞吐骤降 - 事务中混用 DDL（如
ALTER TABLE）：8.0 的原子 DDL 要求更强的元数据锁（MDL），哪怕只是REPEATABLE READ事务，也可能被阻塞更久 - 未显式指定索引的
UPDATE/DELETE：如果走全表扫描，8.0 锁的是所有聚簇索引记录 + 间隙，而 5.7 可能只锁实际命中的行
升级后最容易被忽略的验证点
锁问题往往不会在启动时报错，而是在高并发、特定数据分布下才暴露。上线前必须验证：慢查询日志里有没有新增的 Waiting for table meta 或长时间 Locked 状态；监控中 Innodb_row_lock_waits 是否突增；以及业务高峰期是否出现偶发性超时。
