主从表结构不一致导致复制中断，因mysql默认不校验结构，从库缺失字段时直接报error 1054使sql线程停止；需用mysqldump --no-data --skip-triggers导出结构再diff确认差异；从库alter table修复前须stop slave、确保主库无写入，并验证版本兼容性；pt-table-sync不可用于系统库，因其仅支持用户库且要求结构严格一致。
主从表结构不一致时为什么复制会中断？
MySQL默认不校验表结构，只按binlog事件逻辑执行。主库执行UPDATE t1 SET new_col = 1时，如果从库表里没有new_col字段，就会立刻报ERROR 1054 (42S22): Unknown column 'new_col' in 'field list'，SQL线程停止，Slave_SQL_Running变为No。
怎么快速确认主从表结构差异？
别靠肉眼比SHOW CREATE TABLE——字段顺序、默认值、字符集、注释等细微差别都会导致后续复制失败。安全做法是导出结构再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
必须加--no-data和--skip-triggers，否则可能混入数据或触发器干扰判断。
在从库执行ALTER TABLE修复要注意什么？
这是最常用方式，但稍有不慎就会引发二次冲突：
- 先确保主库对该表无写入（或选业务低峰期），避免
ALTER被复制到从库后与主库原DDL冲突 - 从库执行前务必
STOP SLAVE;，防止SQL线程正在回放期间结构被改 - 执行完立刻验证：
SHOW CREATE TABLE table_name确认字段名、类型、约束、默认值完全一致 - 重启后观察
Seconds_Behind_Master是否回落、Last_SQL_Error是否清空
注意：若主库已用ALGORITHM=INSTANT新增字段，而从库版本低于8.0.12，则ALTER可能失败——小版本兼容性必须核对清楚。
为什么不能直接用pt-table-sync修复系统库结构？
pt-table-sync只处理用户数据库中的表数据，对mysql、performance_schema等系统库完全无效。它依赖表结构严格一致，而系统库的字段、索引、权限模型在不同MySQL版本间差异极大（比如mysql.user.authentication_string字段加密方式变更）。强行覆盖或跳过会导致后续所有用户操作失败。
真正能动的只有用户库；系统库结构不一致，说明主从版本已不兼容——这时候该看SELECT VERSION()和@@sql_mode，而不是修表。
