直接删除从库同名表再启动复制是最稳妥解法；因主从数据不一致，从库已存在表而主库发CREATE TABLE导致1050错误；需确认库上下文、结构一致性及业务访问后，再STOP/ DROP/START SQL线程恢复。
直接删掉从库上多余的同名表，再启动复制，是最稳妥、最可控的解法。跳过错误或重置复制链容易掩盖数据不一致，后续可能引发更隐蔽的同步断裂或查询异常。
为什么1050错误只在从库报，主库却能正常建表
根本原因是主从数据状态不一致：从库上已存在同名表（可能是人为提前创建、历史残留、或之前同步中断后残留），而主库发来的是 CREATE TABLE 语句——MySQL从库 SQL 线程执行时不会自动加 IF NOT EXISTS，遇到已存在的表就直接报 Error_code: 1050 并中止复制。
常见诱因包括：
- 运维人员在从库手动执行过
CREATE TABLE t1，但主库还没建； - 主从切换或重建后，旧表未清理干净；
- 使用
mysqldump --no-create-info或类似方式导入数据时漏掉了DROP TABLE步骤。
手动删除冲突表前必须确认的三件事
别急着 DROP TABLE，先验证是否真能删、该不该删：
- 确认当前数据库上下文：
USE test;（test是报错里Default database: 'test'指定的库名）； - 检查表结构是否和主库一致：
SHOW CREATE TABLE t3;—— 如果字段、引擎、字符集明显不同，说明它不是主库同步来的，大概率可删； - 查一下有没有业务正在读写这张表：
SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE INFO LIKE '%t3%';，避免误删活跃表。
标准清理 + 恢复流程（推荐顺序执行）
这是生产环境最常验证有效的操作路径，不依赖跳过计数器，也不重置整个复制关系：
- 停止从库 SQL 线程：
STOP SLAVE SQL_THREAD;（保留 IO 线程继续拉日志，避免位点丢失）； - 删除冲突表：
DROP TABLE t3;（注意：不是DROP TABLE IF EXISTS，因为你要明确知道它存在且要删）； - 启动 SQL 线程：
START SLAVE SQL_THREAD;； - 立刻验证：
SHOW SLAVE STATUS \G，确认Slave_SQL_Running: Yes且Seconds_Behind_Master开始回落。
容易被忽略的两个细节
第一，DROP TABLE 后如果仍报 1050，大概率是表文件残留（尤其 MyISAM 引擎或异常关机后）。此时需登录服务器，进到对应数据库目录（如 /var/lib/mysql/test/），手动删除 t3.MYD、t3.MYI、t3.frm（MyISAM）或 t3.ibd + t3.frm（InnoDB），再重启 MySQL 进程。
第二，InnoDB 表即使 SHOW TABLES 看不到，也可能因元数据损坏“幽灵存在”。这时执行 REPAIR TABLE t3; 会报错，但 DROP TABLE IF EXISTS t3; 可能静默失败——必须用 mysqlcheck --repair test t3 或直接删物理文件。
