事务提交失败本质是前置dml因非法字符（如'、emoji、损坏utf-8）报错（如error 1366），导致事务中断或回滚，后续commit因无活跃事务而报error 1373；需通过show variables、show create table比对字符集，并检查输入字符串本身是否含非法字节或控制符。
事务提交失败不是字符问题本身，而是字符引发的前置DML报错未被捕获，导致COMMIT执行时已无活跃事务可提交。
为什么“非法字符”会让COMMIT报错？
MySQL 的 COMMIT 命令本身几乎不会直接因字符报错；真正出问题的是它前面那条 INSERT 或 UPDATE——比如插入含未转义单引号的字符串 'O'Reilly'，或向 latin1 字段写入 utf8mb4 emoji（如 ?），触发 ERROR 1366 (HY000): Incorrect string value。此时事务已中断，再执行 COMMIT 就会收到类似 ERROR 1373: Cannot modify an existing transaction 的提示。
- 错误常被误判为“提交失败”，实际是 DML 阶段已失败，事务自动回滚或进入无效状态
-
SHOW ENGINE INNODB STATUSG中看不到该事务，SELECT @@in_transaction;返回 0 - 应用层若只监听
COMMIT结果，会漏掉真正的错误源头
如何快速定位是字符集还是字符串内容的问题？
先区分两类非法字符：
-
字符集不匹配：表字段是
utf8mb4，但客户端连接用latin1发送数据 → 报ERROR 1366 -
字符串含非法字节序列：字段是
utf8mb4，但插入了损坏的 UTF-8（如截断的 4 字节字符）→ 同样报ERROR 1366 -
SQL 语法级非法字符：未转义的
'、"、导致解析失败 → 报ERROR 1064
立即执行：SHOW VARIABLES LIKE 'character_set%';SHOW CREATE TABLE your_table;
比对 character_set_client、character_set_connection 和字段定义是否一致。不一致就是字符集问题；一致却仍报错，大概率是输入字符串本身损坏或含控制字符。
生产环境不能停服时的应急修复步骤
别改配置、别重启服务，优先保业务可用：
- 在应用层 SQL 执行前加日志，记录原始参数值（尤其字符串字段），确认是否含不可见字符（如
u202ERTL 控制符） - 对高危字段（姓名、地址、备注）做预检：
SELECT HEX(col) FROM t WHERE col REGEXP '[^[:print:]]' LIMIT 1;，查出十六进制异常字节 - 临时绕过：将问题字段 UPDATE 为安全字符串（如
REPLACE(REPLACE(col, "'", "\'"), '"', '\"')），再重试业务逻辑 - 若确认是连接层编码错，Java 应用立刻在 JDBC URL 加
?characterEncoding=utf8mb4；PHP 立即加$pdo->exec("SET NAMES utf8mb4");
避免下次再踩坑的关键配置点
字符问题总在深夜爆发，因为开发和测试环境往往没复现生产的数据分布和客户端链路：
- 所有新建库/表强制指定：
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - MySQL 配置文件
[mysqld]段必须有：character-set-server = utf8mb4；[client]和[mysql]段必须有：default-character-set = utf8mb4 - 应用连接池初始化 SQL 加一句：
SET NAMES utf8mb4（注意不是SET CHARACTER SET utf8mb4） - 禁止在事务中混用 DDL（如
ALTER TABLE）——它会隐式提交，导致后续COMMIT失效
最易被忽略的是：客户端操作系统终端编码（如 Windows CMD 默认 GBK）与 MySQL 连接编码不一致时，即使配置全对，mysql -u root -p 直连也会在输入密码或执行 INSERT 时悄悄引入乱码字节。生产排查务必从终端环境开始看。
