小量数据、结构一致、低频同步用INSERT ... SELECT最轻量；大表、需断点续传或跨版本/服务器则mysqldump + mysql重放更稳但非实时。
MySQL跨库同步用INSERT ... SELECT还是mysqldump？
直接说结论：小量数据、结构一致、频率不高（如每天一次）用insert ... select最轻量；大表、需断点续传、跨版本或跨服务器，mysqldump + mysql重放更稳，但无法实时。
关键区别在事务边界和锁行为：INSERT ... SELECT在源库会持读锁（取决于隔离级别和引擎），目标库是普通写入；而mysqldump默认加--single-transaction可避免全表锁，但要求源库是InnoDB且没DDL在跑。
- 别在业务高峰期跑
INSERT ... SELECT大表，容易堵住源库的SELECT和目标库的INSERT -
mysqldump --where="created_at >= '2024-01-01'"能做增量导出，但要注意时间字段是否带时区、是否被索引覆盖 - 如果目标库有自增主键，记得加
SET FOREIGN_KEY_CHECKS=0;和SET UNIQUE_CHECKS=0;再导入，否则唯一冲突或外键报错
定时任务里怎么安全执行跨库SQL？
别直接在crontab里写裸mysql -e "INSERT ..."——密码明文、错误无捕获、失败不告警。
正确做法是封装成脚本，用配置文件存连接参数，并检查影响行数。MySQL 8.0+ 支持ROW_COUNT()返回上条语句变更数，这是判断同步是否“真生效”的唯一可靠依据。
- 用
mysql --defaults-extra-file=/etc/my-sync.cnf -e "INSERT INTO db2.t SELECT * FROM db1.t WHERE updated_at > NOW() - INTERVAL 1 DAY;"，其中my-sync.cnf里只放[client]段，含host、user、password，权限设为600 - 执行后立刻查
mysql -Nse "SELECT ROW_COUNT();"，结果为0不等于“成功”，可能是条件没命中，也可能是WHERE写错 - 加
|| exit 1到命令末尾，让crontab能识别失败并触发邮件通知（配合MAILTO=）
遇到ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist怎么办？
这是跨库同步视图、存储过程或事件时高频报错，本质是目标库缺定义者账号，不是权限问题。
有两种解法：临时绕过或彻底修复。绕过快但不治本，修复要改元数据，得停写窗口。
- 同步前在目标库执行
CREATE USER 'xxx'@'%' IDENTIFIED BY '';（空密码仅限内网可信环境） - 更稳妥的是导出时加
--skip-definer，让mysqldump自动把DEFINER=`xxx`@`%`替换成DEFINER=CURRENT_USER - 如果已导入出错，用
mysqldump --no-create-info --skip-triggers --skip-routines先清掉有问题的对象，再重新导
异构迁移（比如从MySQL 5.7到8.0）最常卡在哪？
不是语法兼容性，而是隐式类型转换和sql_mode收紧。MySQL 8.0默认开启STRICT_TRANS_TABLES，而5.7很多业务依赖宽松模式容忍截断、零日期等。
典型表现是同步脚本中途退出，日志里看不到明显报错，只有一行Warning: Data truncated for column 'xxx'被忽略——这在8.0下会直接变错误。
- 目标库启动前先确认
SELECT @@sql_mode;，若含STRICT_TRANS_TABLES，同步前临时设为SET sql_mode='';（仅会话级，不影响其他连接） - 用
SHOW CREATE TABLE比对源/目标字段长度，特别是VARCHAR(255)vsVARCHAR(191)（因utf8mb4索引限制） - 时间字段统一用
DATETIME，别混用TIMESTAMP——后者受时区和explicit_defaults_for_timestamp影响极大
跨库同步真正的麻烦从来不在“怎么连上”，而在“哪一行数据悄悄变了样”。字段默认值、字符集隐式转换、时区偏移、甚至SQL_NO_CACHE这种废弃语法残留，都可能让两个库在某天凌晨三点开始慢慢漂移。留个CHECKSUM TABLE定期核对，比啥监控都实在。
