MySQL批量清空数据必须用TRUNCATE TABLE而非DROP DATABASE，因需保留表结构、索引、外键及权限；TRUNCATE是DDL操作，不可回滚、重置自增ID、不写binlog，但受外键约束限制，需临时禁用外键检查或按依赖顺序执行。
MySQL 批量 TRUNCATE TABLE 为什么不能直接用 DROP DATABASE？
因为你要保留表结构、索引、外键、权限等元信息，只清空数据——DROP DATABASE 连结构一起删了，恢复成本高，还可能触发权限重置或应用连接失败。
而 TRUNCATE TABLE 是最接近“清空”的原生命令：快、不写 binlog（默认）、重置自增主键。但 MySQL 不支持 TRUNCATE TABLE *，必须逐表执行。
- 外键约束会直接阻止
TRUNCATE，报错Cannot truncate a table referenced in a foreign key constraint - 如果表名含特殊字符或属于非默认 schema，必须用反引号包裹，比如
`my-db`.`user_log` -
TRUNCATE是 DDL 操作，无法回滚（即使在事务中），执行前务必确认库环境
如何安全生成并执行批量 TRUNCATE 语句？
核心思路：先查出所有目标表名，拼成 TRUNCATE TABLE `xxx`; 语句，再统一执行。关键在绕过外键检查 + 控制顺序。
- 临时禁用外键检查：
SET FOREIGN_KEY_CHECKS = 0;，执行完再设回1 - 按依赖关系倒序清空（先子表后父表）太麻烦，简单做法是清两次：第一次清掉无外键依赖的表，第二次再清剩下的（需手动补漏）
- 更稳妥的做法：用
information_schema.TABLES查表，排除系统库（如mysql、information_schema），并按TABLE_SCHEMA过滤
示例生成语句（在目标库内运行）：
SELECT CONCAT('TRUNCATE TABLE `', table_name, '`;')
FROM information_schema.TABLES
WHERE table_schema = 'your_db_name'
ORDER BY table_name;
用 shell 脚本自动执行时要注意哪些坑？
人工复制粘贴 SQL 容易漏、错、乱序；用脚本自动化才真正“高效”，但几个细节不处理就会卡住。
- MySQL 登录凭据不能硬编码在脚本里，建议用
~/.my.cnf配置文件，避免密码泄露和命令行历史残留 - 输出语句带分号，但 MySQL 客户端默认以分号为语句结束符，直接
mysql -e会报错，得用mysql -e "source /tmp/trunc.sql"或管道方式 - 某些表名含破折号或大小写（如
user-2023），不加反引号会导致语法错误，生成时必须包上` - 如果某张表正在被长事务占用，
TRUNCATE会等待锁释放，脚本可能 hang 住，建议加超时：mysql --connect-timeout=5 --wait-timeout=5 ...
为什么不用 DELETE FROM 替代 TRUNCATE？
看起来都能删数据，但行为和代价完全不同。
-
DELETE FROM是 DML，逐行删除、记录 binlog、触发触发器、不重置自增 ID，大表会非常慢且撑爆 undo log -
TRUNCATE是 DDL，直接释放数据页，几乎瞬时完成，但要求你有DROP权限（MySQL 8.0+ 改为需要TRUNCATE权限） - 有些托管数据库（如阿里云 RDS、AWS RDS）默认禁用
TRUNCATE，只允许DELETE，这时就得看权限策略，不能硬上
真正要“快速”清空，TRUNCATE 是唯一合理选择；但它的不可逆性和权限门槛，意味着你得提前验证好账号权限和外键状态，而不是等到执行时报错才回头改脚本。
