主库执行含新字段操作时从库报ERROR 1054，因MySQL主从复制默认不校验表结构，仅回放binlog逻辑；主库UPDATE引用从库不存在的字段即触发该错，导致SQL线程停止、Slave_SQL_Running为No。
主库执行含新字段操作时从库报 ERROR 1054
MySQL 主从复制默认不校验表结构，只按 binlog 事件逻辑回放 SQL。一旦主库执行 UPDATE t1 SET new_col = 1，而从库表里根本没有 new_col 字段，就会立刻触发 ERROR 1054 (42S22): Unknown column 'new_col' in 'field list'，SQL 线程停止，Slave_SQL_Running 变为 No，Seconds_Behind_Master 变成 NULL。
为什么不是所有 DDL 都会立即中断？
有些 DDL 操作本身不会被复制（比如 ALTER TABLE ... COMMENT 或仅改默认值但未影响行格式），或者主库写入的是旧字段、新字段只是新增但未被引用，此时同步还能继续跑——但这只是“侥幸”，隐患已埋下。只要后续任意一条语句用到缺失字段，就必然中断。
-
ADD COLUMN后未被读写：暂无报错，但结构已不一致 -
MODIFY COLUMN类型变窄（如VARCHAR(50) → VARCHAR(10)）：主库成功，从库回放时可能截断或报错，取决于sql_mode -
DROP COLUMN：主库删了字段，从库还保留，后续主库更新其他字段可能正常，但若从库有应用直连并依赖该字段，就出业务问题
如何快速确认主从表结构是否真一致？
别靠肉眼比对 SHOW CREATE TABLE —— 字段顺序、CHARSET、COLUMN_FORMAT、注释、索引名、DEFAULT 值细微差异都可能导致实际不兼容。安全做法是：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 主库导出：
mysqldump -h master -u user -p --no-data --skip-triggers database table > master.sql - 从库导出：
mysqldump -h slave -u user -p --no-data --skip-triggers database table > slave.sql - 本地运行：
diff master.sql slave.sql，关注CREATE TABLE行内所有字段定义和末尾的ENGINE=...、DEFAULT CHARSET=...等
更准的方式是用 pt-table-checksum（它能识别逻辑等价但语法不同的建表语句），但日常巡检用 diff 已足够暴露绝大多数风险点。
修复时最容易被忽略的细节
在从库直接 ALTER TABLE 是最快方式，但必须注意三件事：
- 执行前务必
STOP SLAVE;，否则 ALTER 被复制到主库后可能引发二次冲突（尤其当主库已有同名字段但类型不同） - 执行完立刻
SHOW CREATE TABLE，确认字段名、类型、DEFAULT、NOT NULL约束与主库完全一致——少一个NOT NULL都可能让后续 INSERT 失败 - 重启复制后不要只看
Slave_SQL_Running: Yes，还要查Seconds_Behind_Master是否持续回落、Last_SQL_Error是否为空；如果几秒后又变No，说明还有隐藏差异（比如索引名不同导致外键或触发器行为异常）
真正麻烦的不是字段缺失，而是字段存在但定义不一致——这种问题不会立刻报错，却会在某次业务高峰悄悄拖垮从库性能或返回错误结果。
