17370845950

MySQL升级后事务异常主因是默认配置变更，需重点排查：1.隔离级别默认值（5.7为RR，8.0.22+可能为RC）；2.RC下一致性读更严格（每SELECT用最新快照）；3.autocommit下DDL隐式提交更严格；4.sql_mode严格化导致警告变错误。

MySQL 升级后事务行为出现异常，通常不是“bug”，而是版本间默认配置、隔离级别实现或 SQL 模式调整导致的预期变化。重点排查 事务隔离级别默认值、READ-COMMITTED 下的一致性读行为、autocommit 默认状态、SQL_MODE 对事务语义的影响 这四类核心差异。

隔离级别默认值变了（尤其 5.7 → 8.0）

MySQL 5.7 默认隔离级别是 REPEATABLE-READ，而 MySQL 8.0.22+ 在启用 transaction_isolation 系统变量（替代旧的 tx_isolation）后，若未显式配置，可能受启动参数或配置文件影响，部分云厂商镜像甚至默认设为 READ-COMMITTED。

• 执行 SELECT @@transaction_isolation; 确认当前会话/全局实际值
• 检查 my.cnf 是否有 transaction_isolation = READ-COMMITTED 或类似配置
• 应用中若依赖 RR 的可重复读特性（如多次 SELECT 同一数据不变化），升级后变 RC 就会看到“幻读”或“不可重复读”现象

READ-COMMITTED 下一致性读逻辑更严格（8.0 改进）

MySQL 8.0 对 RC 隔离级别的 MVCC 实现做了优化：每个 SELECT 语句都基于最新已提交快照，而非事务开始时的快照。这导致同一事务内多次 SELECT 可能返回不同结果——这是标准 SQL 行为，但老版本（尤其 5.6）因实现限制反而“看起来更稳定”。

• 不要在 RC 下假设“事务内 SELECT 结果不变”；需强一致性场景应显式用 SELECT ... FOR UPDATE 或升至 RR
• 避免在 RC 中写“先查后更”的业务逻辑（如查余额→判断→扣减），改用原子更新：UPDATE account SET balance = balance - ? WHERE id = ? AND balance >= ?

autocommit 默认开启，但隐式提交规则更明确

所有 MySQL 版本默认 autocommit = 1，但升级后对 DDL 语句触发隐式提交 的处理更严格。例如，在事务中执行 CREATE TABLE 或 ALTER TABLE，8.0 会立即提交当前事务并清空保存点，而 5.6/5.7 可能允许部分 DDL 在事务块内（非标准且已被弃用）。

• 检查代码中是否在 BEGIN … COMMIT 块内混用 DDL —— 升级后会导致事务提前结束、后续 DML 不再受控
• 将 DDL 和 DML 分开执行，DDL 单独成事务，DML 显式控制
• 用 SHOW VARIABLES LIKE 'completion_type'; 确认是否启用了 NO_CHAIN 或 CHAIN，它会影响 COMMIT 后的行为

SQL_MODE 影响事务边界（尤其 STRICT_TRANS_TABLES / ONLY_FULL_GROUP_BY）

MySQL 8.0 默认启用更严格的 sql_mode（含 STRICT_TRANS_TABLES）。当 INSERT/UPDATE 出现警告（如截断字符串、零日期）时，严格模式会让语句直接报错并回滚当前语句——若在事务中，可能打断预期流程，甚至让应用误判为“整个事务失败”。

• 执行 SELECT @@sql_mode; 对比新旧环境差异
• 若应用依赖“警告即成功”，可临时调整为兼容模式（不推荐长期使用）：SET GLOBAL sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,...'; 去掉 STRICT*
• 更稳妥做法：在应用层捕获 SQL 错误码（如 1265、1366），区分警告与错误，避免把警告当致命异常

不复杂但容易忽略。升级前做事务路径回归测试，重点覆盖“查-判-改”、并发更新、DDL 混用、空值/边界值写入这几类典型场景。