根本原因是“执行成功”不等于“数据落地”，常见于事务未提交、触发器静默失败、权限不足或约束冲突被忽略；需检查autocommit状态、执行show warnings、验证权限与表结构，并避免仅依赖sql无报错判断结果。
根本原因不是SQL写错了，而是“执行成功”不等于“数据落地”——多数情况是事务没提交、触发器静默失败或权限/约束被忽略。
autocommit=false 且没手动 commit
MySQL 默认客户端开启 autocommit，但 JDBC 连接串里加了 ?autocommit=false，或者 Spring 中 @Transactional 作用域异常退出，都会导致 insert 执行完但事务未提交。此时连接断开或应用重启，数据立刻回滚。
- 检查连接配置：执行
SELECT @@autocommit;，返回0表示关闭 - JDBC 场景下必须显式调用
connection.commit()（且不能漏掉 try-finally 或 try-with-resources 的 close） - Spring 环境注意嵌套事务传播行为：
REQUIRES_NEW会新建事务，若外层没捕获异常，内层 commit 后外层 rollback，照样丢数据
触发器里 signal/throw 但错误被吞掉
MySQL 触发器中写 SIGNAL SQLSTATE '45000' 或字段名拼错，整个 INSERT 会失败，但客户端只收到 Query OK, 0 rows affected ——错误藏在警告里，不查 SHOW WARNINGS 根本看不到。
- 执行 insert 后立刻跟一句
SHOW WARNINGS;，看是否有Warning级别报错（比如Unknown column 'xxx' in 'NEW'） - SQL Server 中
RAISERROR默认不中断事务，必须配ROLLBACK TRANSACTION或启用SET XACT_ABORT ON - 触发器里调用存储过程出错，若没加
DECLARE EXIT HANDLER，也会静默终止而不抛出
INSERT IGNORE 或 REPLACE 导致“影响行数=0”
INSERT IGNORE INTO t (id, name) VALUES (1, 'a') 遇到主键冲突时不会报错，只返回 Rows matched: 1 Changed: 0，业务代码若只判断 executeUpdate() > 0 就认为成功，实际什么都没写进去。
- 避免无脑用
IGNORE：除非明确需要跳过冲突，否则优先用INSERT ... ON DUPLICATE KEY UPDATE - 检查返回值含义：
executeUpdate()返回的是“受影响行数”，不是“插入行数”；INSERT IGNORE冲突时返回 0，REPLACE返回 2（先删后插） - 主键/唯一索引冲突时，MySQL 日志里可能只有
Warning，不会进 error log
权限不足或 schema 解析错位
用户登录时默认 schema 是 backup_db，但执行 INSERT INTO user ... 没带库名，结果数据写进了 backup_db.user 而不是预期的 prod_db.user；或者用户只有 SELECT 权限，没有 INSERT，但 MySQL 在某些 sql_mode 下会静默忽略而非报错。
- 始终用全限定名：
INSERT INTO prod_db.user (...) VALUES (...) - 确认权限：
SHOW GRANTS FOR CURRENT_USER;，重点看是否有INSERT权限 - 检查当前库：
SELECT DATABASE();，别依赖连接串里的database=xxx，有些驱动初始化时不切换库
最容易被忽略的是：事务未提交和触发器错误被吞掉这两类问题，它们既不抛异常也不留明显日志，靠查表、看主键自增跳号、比对 SHOW WARNINGS 才能定位。别只盯着 SQL 本身有没有语法错。
