外键冲突时不能直接删子表再删父表，因跨服务/库操作难保一致性且易遗漏临时表、归档表，DELETE还可能触发级联或触发器放大冲突；应让数据库按依赖图谱顺序执行，而非手动干预。
外键冲突报错 Cannot delete or update a parent row 时，为什么不能直接删子表再删父表？
因为业务逻辑里常有跨服务、跨库操作，手动按依赖顺序删表既难保证一致性，又容易漏掉临时表或归档表。更麻烦的是，delete 本身会触发触发器或级联动作，反而放大冲突。真正要做的不是“删得更小心”，而是让数据库自己按图谱顺序执行——靠 foreign_key_checks=0 临时关检查，只适用于单次脚本，不解决自动化场景下的依赖推导问题。
用 mysqldump --skip-triggers --no-create-info --add-locks=FALSE 导出数据时，怎么保留外键顺序？
默认导出不保顺序，mysqldump 按表名 ASCII 排序，跟外键依赖完全无关。必须加 --order-by-primary 配合 --skip-extended-insert，让每条 INSERT 按主键升序排列，再配合人工调整表导出顺序（先子表后父表），否则还原时照样报错。但这样没法自动化——所以实际推荐换思路：不用 dump 还原，改用 SELECT ... INTO OUTFILE + LOAD DATA INFILE 分表导出，再用 Python 或 Shell 解析 INFORMATION_SCHEMA.KEY_COLUMN_USAGE 表生成执行顺序。
Windows 批处理调用 mysql -e 执行多语句时，为什么第二条总被忽略？
因为 mysql -e 默认只执行一条语句，分号不是语句分隔符，而是 SQL 语法的一部分；批处理里写 mysql -e "DELETE FROM t1; DELETE FROM t2;" 实际只执行了第一个 DELETE。正确做法是用 -e 调一次，里面用 DELIMITER 包裹多语句，或者更稳妥地：把 SQL 写进文件，用 mysql 方式执行。另外注意，计划任务里运行批处理时，<code>%PATH% 可能不含 MySQL bin 目录，得写绝对路径调用 mysql.exe。
计划任务里执行 SQL 清理脚本，为什么凌晨三点总失败？
失败通常不是 SQL 本身问题，而是权限和上下文差异：计划任务默认以 SYSTEM 用户运行，它没有访问网络驱动器、读取用户配置文件（比如 my.cnf）的权限；而且如果脚本里用了相对路径（如 ./data/t1.sql），在计划任务工作目录下根本找不到。解决方法只有两个：显式指定 --defaults-file=C:\path\to\my.cnf，以及所有路径都用绝对路径，包括 SQL 文件、日志输出、甚至临时文件夹。顺便提醒：EVENT 功能虽可替代计划任务，但它依赖 MySQL 服务持续运行，一旦服务重启或崩溃，事件就停摆，不如 Windows 任务管理器可靠。
外键同步真正的难点不在命令怎么写，而在每次表结构微调后，依赖关系图就得重算一遍——没人会手动更新批处理里的表顺序，所以自动化脚本里必须包含动态拓扑排序逻辑，哪怕只是用几行 SELECT 查 INFORMATION_SCHEMA 生成临时执行列表。
