主从表结构不一致时复制会中断吗
不一定立即中断，但大概率出问题。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验证数据行数与关键字段值是否真正一致——结构对了，数据未必对。
