主从表结构不一致时复制不一定立即中断但大概率出问题；mysql默认不校验表结构，主库执行含新字段操作时从库因缺少字段报错1054，sql线程停止。
主从表结构不一致时复制会中断吗
不一定立即中断，但大概率出问题。MySQL 主从复制默认只校验 binlog 事件的执行逻辑，不主动比对表结构。一旦主库执行了依赖新字段的操作（比如 UPDATE t1 SET new_col = 1 WHERE id = 1），而从库表里没有 new_col，就会报错 ERROR 1054 (42S22): Unknown column 'new_col' in 'field list'，SQL 线程停止，SHOW SLAVE STATUS\G 中 Seconds_Behind_Master 变为 NULL，Slave_SQL_Running 为 No。
如何快速发现主从表结构差异
不能只靠肉眼比对 SHOW CREATE TABLE，尤其当字段顺序、注释、默认值、字符集或索引名有细微差别时。推荐用 pt-table-checksum（Percona Toolkit）配合 pt-table-sync，它能跨实例比对实际结构和数据一致性：
pt-table-checksum --no-check-binlog-format --replicate=test.checksums h=master_host,u=user,p=pass h=slave_host,u=user,p=pass
若只想快速查结构差异，可在主从分别导出建表语句并 diff：
- 主库执行：
mysqldump -h master -u user -p --no-data --skip-triggers database table > master_table.sql - 从库执行：
mysqldump -h slave -u user -p --no-data --skip-triggers database table > slave_table.sql - 本地对比：
diff master_table.sql slave_table.sql
注意：--skip-triggers 和 --no-data 必须加，否则可能混入数据或触发器干扰判断。
修复结构不一致的三种安全方式
直接在从库执行 ALTER TABLE 是最常见做法，但必须避开主从冲突点：
- 确保主库当前没有对该表的写入（或业务低峰期），避免
ALTER被复制到从库后引发二次冲突 - 从库先停复制：
STOP SLAVE;，再执行ALTER TABLE ... ADD COLUMN new_col INT DEFAULT 0; - 执行完立刻检查：
SHOW CREATE TABLE确认字段已存在且类型/约束一致 - 重启复制：
START SLAVE;，观察Seconds_Behind_Master是否回落、无错误
如果主库已执行过 DDL 并同步失败，可临时跳过该事件（仅限明确知道不影响业务的场景）：
SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;
但跳过之后务必立刻补结构，否则后续同表操作仍会失败。更稳妥的方式是用 pt-online-schema-change 在主库变更结构，它会自动兼容从库结构同步节奏。
为什么从库加字段后仍可能复制失败
常见被忽略的点：
-
DEFAULT值不一致：主库字段定义为col VARCHAR(10) DEFAULT 'abc'，从库漏了DEFAULT，INSERT 不带该字段时行为不同 - 字符集/排序规则差异：主库是
utf8mb4_unicode_ci，从库是utf8mb4_general_ci，某些字符串比较结果不一致，导致基于条件的 UPDATE/DELETE 复制异常 - 索引缺失或名称不同：主库有
INDEX idx_name (col)，从库没建或建成了INDEX idx_col (col)，虽不影响 DML 执行，但可能导致主从查询计划不同，间接影响基于 GTID 的事务一致性 - 外键约束：从库开了
FOREIGN_KEY_CHECKS=1，而主库关闭了，主库删父记录成功，从库因外键报错中断
修复后别只看 SQL 线程是否运行，一定要用 SELECT COUNT(*) 或 pt-table-checksum 验证数据行数与关键字段值是否真正一致——结构对了，数据未必对。
