常见原因是ALTER TABLE后事务状态异常或连接缓存旧元数据：自动提交触发导致后续INSERT在新事务中静默失败；新增NOT NULL字段无默认值致插入被拒；视图/触发器引用旧字段名；JDBC预编译语句缓存旧结构。
ALTER TABLE 后 INSERT/UPDATE 失败但无报错
常见现象是执行完 alter table，后续写入操作看似成功（没报错），但查不到新数据，或 select 返回旧结构字段。本质往往是事务未提交、隐式回滚，或 ddl 触发了自动提交导致后续语句在新事务中运行而连接状态异常。
- 确认当前会话是否处于自动提交模式：
SELECT @@autocommit;—— 若为 0，且你没手动COMMIT，那ALTER TABLE自身已触发隐式提交，但后续 INSERT 可能因连接复用、连接池超时或事务隔离问题被丢弃 - 检查应用层是否在
ALTER TABLE后立即复用了同一个数据库连接，却没重置事务状态（比如没调conn.commit()或conn.rollback()） - MySQL 8.0+ 中，某些 ALTER 操作（如
ALGORITHM=INSTANT）虽快，但若表上有未提交的长事务，DDL 会被阻塞；一旦它最终执行，可能把等待中的写请求“冲掉”——不是报错，而是连接断开或语句静默失败
MySQL 权限不足导致 DDL 成功但 DML 失效
用户有 ALTER 权限不代表有 INSERT 或 UPDATE 权限；更隐蔽的是：修改表结构后，如果新增了 NOT NULL 字段且没设默认值，所有后续 INSERT 都会因缺失该字段值而失败——错误是 Column 'xxx' cannot be null，但容易误判为权限问题。
- 执行
SHOW GRANTS FOR CURRENT_USER;，确认包含INSERT、UPDATE、SELECT，而不仅是ALTER - 检查新增字段约束：
DESCRIBE table_name;看Null列是否为NO且Default为空；若是，必须显式提供值或改用ALTER TABLE ... MODIFY COLUMN ... DEFAULT ... - 注意视图或触发器依赖原表结构：如果 ALTER 改了字段名或类型，而视图里仍引用旧名，INSERT 到视图会失败，报错类似
Unknown column 'old_name' in 'field list'
事务回滚时 DDL 不可逆，但 DML 被连带丢弃
MySQL 不支持在事务中回滚 DDL；ALTER TABLE 一执行就永久生效。但如果你在同一个事务里先 ALTER 再 INSERT，然后 ROLLBACK，结果是：表结构变更保留，INSERT 数据消失——这会造成“结构变了，数据却没存住”的错觉。
- 永远不要在业务事务中混用 DDL 和 DML；DDL 应单独执行、单独验证
- 若必须原子化变更，改用影子表方案：
CREATE TABLE new_table LIKE old_table→ALTER TABLE new_table ...→INSERT INTO new_table SELECT ... FROM old_table→RENAME TABLE old_table TO old_bak, new_table TO old_table - 使用
pt-online-schema-change工具时，注意它默认不锁表，但会创建触发器同步增量；若触发器权限不足或主从延迟大，DML 可能丢失而不报错
连接池配置引发的“结构已变，写入无效”假象
应用重启后连接池重建，但旧连接仍缓存着表元数据（尤其 JDBC 的 cachePrepStmts=true + prepStmtCacheSize 较大时），导致 PreparedStatement 绑定的列数/类型仍是旧结构，INSERT 实际发到服务端时被静默截断或转成默认值。
- 临时验证：用命令行客户端直连 MySQL，手动 INSERT，看是否正常；若正常，基本锁定是客户端缓存问题
- JDBC 连接串加参数：
&useServerPrepStmts=false&cachePrepStmts=false（开发期排查用） - 生产环境推荐：ALTER 后主动清空连接池（如 Spring Boot 的
/actuator/refresh或重启连接池 Bean），而非等连接自然失效
WARN 级别消息，比盯 ERROR 更有用；还有就是别信应用层返回的“success”，一定要 SELECT 验证。 
