不能直接用 DROP DATABASE 清空测试库，因其受权限限制、会删除用户/权限等配置，并可能误影响共用账号的邻近实例；应优先用按外键顺序执行的 TRUNCATE TABLE 清空数据。
为什么不能直接用 DROP DATABASE 清空测试库
很多同学第一反应是删库重建，但实际在 CI/CD 或共享测试环境里，DROP DATABASE 往往被权限限制，且会连带删除用户、权限、字符集等配置——这些不是“业务数据”，但影响后续快速复现环境。更关键的是，有些测试库和开发库共用账号或连接池，误删可能波及邻近实例。
用 TRUNCATE TABLE 逐表清空的实操要点
安全清空的核心是保留表结构、索引、约束、触发器，只清数据。优先选 TRUNCATE TABLE 而非 DELETE FROM：前者不走事务日志（快）、不触发 DELETE 触发器（稳）、自动重置自增 ID（省心）。
- 必须按外键依赖顺序执行：先清子表，再清父表，否则会报
Cannot truncate a table referenced by a foreign key constraint - MySQL 8.0+ 支持
SET FOREIGN_KEY_CHECKS = 0临时关闭检查，但清完必须立刻设回1，否则后续 DML 可能静默失败 - PostgreSQL 不支持
TRUNCATE级联清空所有依赖表（除非显式加CASCADE），但需注意CASCADE会连带清空视图依赖的物化表，务必确认 - 示例（MySQL 安全模板）：
SET FOREIGN_KEY_CHECKS = 0;<br>TRUNCATE TABLE order_item;<br>TRUNCATE TABLE `order`;<br>TRUNCATE TABLE user_profile;<br>TRUNCATE TABLE user;<br>SET FOREIGN_KEY_CHECKS = 1;
自动化生成清空脚本的可靠方式
手动列表易漏、难维护。推荐用元数据查询动态拼接，避免硬编码表名：
- MySQL：查
information_schema.TABLES过滤业务表（排除sys、mysql库和以log_、tmp_开头的临时表） - PostgreSQL：用
pg_tables+pg_class.relkind = 'r'确保只选普通表 - 注意跳过系统表、审计日志表、迁移历史表（如
flyway_schema_history），这类表清空会导致下次启动失败 - 简单生成逻辑（MySQL 示例）：
SELECT CONCAT('TRUNCATE TABLE ', table_schema, '.', table_name, ';')<br>FROM information_schema.TABLES<br>WHERE table_schema = 'your_test_db'<br> AND table_name NOT IN ('flyway_schema_history', 'schema_version')<br> AND table_name NOT REGEXP '^log_|^tmp_';
执行前必须验证的三件事
哪怕脚本自动生成，也别跳过人工核对环节：
- 确认当前连接的确实是测试库——检查
SELECT DATABASE()或current_database()输出，别在生产连接上粘贴执行 - 确认没有长事务正在写入：MySQL 查
SHOW PROCESSLIST，PostgreSQL 查pg_stat_activity，避免TRUNCATE被阻塞或导致锁表 - 确认备份已就绪：哪怕只是
mysqldump --no-data导出表结构，也比事后手写 DDL 强
最常被忽略的是外键顺序和迁移历史表——它们不报错，但会让下一次单元测试直接卡在数据库初始化阶段。
