简介面向MySQL数据库管理员和PHP开发者的实用小工具用于批量删除带有相同前缀的数据表。在开发或测试环境中如需清理 temp_、bak_ 之类的临时表或旧表手动逐表删除既费时又易出错通过指定前缀即可一次删除所有匹配表显著提升维护效率并降低误删风险。压缩包内共3个文件含核心PHP脚本、.htm格式说明文档及一个TXT文本文件整体仅3KBPHP脚本负责连接数据库、查询前缀匹配的数据表并执行删除说明文档介绍配置与运行步骤TXT文件则可能是来源或补充信息。已有197人学习下载适合希望快速掌握批量删表思路或直接复用脚本的开发者。参考包内文档和源码可了解参数配置、备份与安全检查等注意事项并将其改造用于自己的数据库清理场景。1. 批量删除 MySQL 相同前缀的数据表这个 v1.0 要做的事与安全底线一个 MySQL 数据库跑上一年业务库和测试库里总会堆出一批以相同前缀命名的数据表tmp_开头的中间表、bak_开头的备份表、批量导入时自动生成的分段表。手工一张张删不现实按前缀写一条删除 SQL 又怕把正式表一起带走。批量删除 MySQL 相同前缀的数据表 v1.0 就是用来解决这个清理问题的先通过 information_schema 拿到准确的待删表清单再逐表执行 DROP带 dry-run、日志和白名单。适合手里有几十上百张同前缀表要清理又不打算引入完整数据管理平台的运维、后端和测试。核心原则只有一句先查清单再删数据永远不要用肉眼数表名。2. 先用 information_schema 查出“该删的表”隔离前缀别靠肉眼清理数据库表的第一件事不是写 DROP而是确认哪些表真的该删。常见的做法是直接看SHOW TABLES LIKE tmp_%这确实快但只适合表量小、命名规律清晰的场景。表量一旦过百我会直接查 information_schema.tables它才是 MySQL 事实上的“表清单字典”也是后续所有批量删除工具的数据来源。2.1 表和库的属主TABLE_SCHEMA 与 TABLE_NAME 两个字段决定删谁information_schema.tables 里每一行描述一张表最核心的字段就两个TABLE_SCHEMA表示表属于哪个库TABLE_NAME表示表名本身。批量删除的逻辑本质上就是一个二维条件数据库等于指定库表名以指定前缀开头。这两个字段同时满足才进入删除候选集。除此之外还可以用几个附加字段缩小删除面降低误删风险。ENGINE只删 InnoDB 表、只删 MyISAM 表按存储引擎隔离。TABLE_COMMENT有些团队会在表注释里写“保留”“勿删”可以用注释过滤。UPDATE_TIME只删 30 天前就不再更新的表给“休眠表”单独开一条清理路径。TABLE_ROWS这个值是估算值不建议作为删除条件但可以拿来预估删除量。查询基础语句长这样SELECT table_schema, table_name, engine, table_comment, update_time FROM information_schema.tables WHERE table_schema report_db AND LEFT(table_name, 4) tmp_ ORDER BY table_name;逻辑说明先锁定table_schema report_db再用LEFT(table_name, 4) tmp_判断表名前四个字符。LEFT()做的是纯字符串比较不涉及 LIKE 的通配符规则后面避坑章节会专门说为什么不用LIKE tmp_%。这段查询跑出来的结果就是 v1.0 实际要处理的候选表清单。参数说明4 是前缀tmp_的字符长度如果前缀是bak_就改成 4如果是temp2024_这种变长前缀建议改成LEFT(table_name, LENGTH(temp2024_)) temp2024_避免手工数错位数。加ORDER BY table_name是为了让输出稳定方便后续 diff 对比。2.2 用 left() 定位前缀不用 LIKE 绕开下划线通配符很多人在这一步会自然写出WHERE table_name LIKE tmp_%。这句 SQL 看起来没毛病但 MySQL 的 LIKE 里下划线_是单字符通配符tmp_%实际匹配的是以tmp开头、第四个字符任意、后面接任意内容的表名。也就是说tmpxxx、tmp2024、tmpbackup全会命中它们并不是“以 tmp_ 这个前缀开头”的表。v1.0 里我统一用LEFT(table_name, N) 固定前缀来定位相同前缀。它不解析通配符前缀里的下划线就是普通下划线匹配结果和人类理解的“前缀”完全一致。如果前缀本身包含%或_也完全不需要转义。还有一种写法是LIKE tmp\_%用反斜杠把下划线转义成普通字符效果等价。但转义规则在不同 sql_mode 和客户端下偶尔有差异脚本里硬编码转义容易埋坑所以工具内部默认走LEFT()方案把 LIKE 留给人工排查时使用。2.3 最小查询命令先 COUNT 再 SELECT永远别一行 DROP 直接上我习惯在生成删除计划前先跑一个计数把预期命中数拿到手SELECT COUNT(*) AS hit_cnt FROM information_schema.tables WHERE table_schema report_db AND LEFT(table_name, 4) tmp_;逻辑说明hit_cnt就是待删表的总数。这个数字和你的心理预期对比非常重要。如果平时看到的tmp_表只有 30 张查询返回 300 张那大概率是查询条件写宽了或者有别的程序也在用这个前缀建表此时应该停下来先看SELECT明细而不是继续往下走。确认数量后再把 2.1 的完整查询结果导出成文件逐行扫一遍表名。这个动作在表量几百张时也就几分钟但能拦住绝大多数误删。批量删除工具做得再好也替代不了这一眼人工复核。真正到了执行阶段删除目标已经被锁定在一个明确的清单内后面所有脚本都围绕这份清单展开。3. 可断点重跑的 Shell 删除脚本dry-run、日志与白名单拿到候选表清单后下一步就是真正执行批量删除。这里要做一个关键选型用一条超长 SQL 把所有表名拼在一起删还是写脚本逐表删v1.0 选择逐表删除放弃一次 DROP 多表的“爽快感”换来的是可控、可观测、可重跑。3.1 为什么用 Shell 逐表删而不是一条 SQL 拼到底一条 SQL 批量删表通常长这样先查表名用GROUP_CONCAT拼成DROP TABLE t1,t2,t3...再交给 PREPARE 执行。表少的时候没问题表一多问题就来了。首先是GROUP_CONCAT有长度上限默认受group_concat_max_len 1024限制几百张表名拼接后会被静默截断生成一条语法不完整的 DROP 语句。其次是单条 DDL 涉及的表太多时元数据锁的持有范围变大业务侧如果有任何一条语句碰了这些表DROP 就可能长时间卡在等待锁状态。逐表删除的优势正好补上这两个短板每张表一条 DROP单条 SQL 短锁范围小失败只影响当前表。脚本可以记录每张表的执行结果失败的表单独落文件重跑脚本时自动跳过已删除的表。中途 CtrlC 退出重跑一遍脚本即可不需要从零开始。可以随时在脚本里加白名单把个别“看起来像临时表、其实是正式表”的名字排除掉。3.2 drop_mysql_prefix.sh 完整脚本下面是 v1.0 的核心脚本按原样保存为drop_mysql_prefix.sh即可使用#!/usr/bin/env bash # # drop_mysql_prefix.sh —— 批量删除 MySQL 相同前缀数据表 v1.0 # 需要 bash 4.4MySQL 客户端 mysql 命令在 PATH 中 # # 用法 # DRY_RUN1 DB_NAMEreport_db TABLE_PREFIXtmp_ ./drop_mysql_prefix.sh # DRY_RUN0 DB_NAMEreport_db TABLE_PREFIXtmp_ SKIP_TABLESkeep_this ./drop_mysql_prefix.sh # set -Eeuo pipefail CONFIG_FILE${CONFIG_FILE:-/etc/mysql/manage.cnf} DB_NAME${DB_NAME:?请设置 DB_NAME} TABLE_PREFIX${TABLE_PREFIX:?请设置 TABLE_PREFIX} DRY_RUN${DRY_RUN:-1} SKIP_TABLES${SKIP_TABLES:-} LOG_DIR${LOG_DIR:-./logs} mkdir -p $LOG_DIR STAMP$(date %Y%m%d_%H%M%S) LOG_FILE${LOG_DIR}/drop_${DB_NAME}_${STAMP}.log # 统一走 defaults-extra-file避免命令行明文密码 MYSQL_ARGS( --defaults-extra-file$CONFIG_FILE -N -B --connect-timeout10 --init-commandSET SESSION lock_wait_timeout10 ) SKIP_SQL if [[ -n $SKIP_TABLES ]]; then SKIP_SQLAND table_name NOT IN (${SKIP_TABLES}) fi query_table_list() { mysql ${MYSQL_ARGS[]} -e SELECT table_name FROM information_schema.tables WHERE table_schema ${DB_NAME} AND LEFT(table_name, ${#TABLE_PREFIX}) ${TABLE_PREFIX} ${SKIP_SQL} ORDER BY table_name; } deleted0 failed0 while IFS read -r table_name; do table_name${table_name%$\r} [[ -z $table_name ]] continue drop_sqlDROP TABLE IF EXISTS \${DB_NAME}\.\${table_name}\; echo [$(date %F %T)] ${drop_sql} | tee -a $LOG_FILE if [[ $DRY_RUN -eq 1 ]]; then continue fi if mysql ${MYSQL_ARGS[]} -e ${drop_sql} ${LOG_FILE} 21; then deleted$((deleted 1)) else echo [FAIL] ${table_name} | tee -a $LOG_FILE failed$((failed 1)) fi done (query_table_list) echo summary: deleted${deleted} failed${failed} dry_run${DRY_RUN} | tee -a $LOG_FILE逻辑说明脚本先读取环境变量组装MYSQL_ARGS然后通过信息模式查询取出所有目标表名进入while循环逐张处理。DRY_RUN1时只打印将要执行的 DROP 语句不真正执行DRY_RUN0时逐表执行删除并把执行输出追加到日志文件。查询参数${#TABLE_PREFIX}自动计算前缀长度避免手工数错位数。参数说明CONFIG_FILE指向一个 MySQL 配置文件推荐路径是/etc/mysql/manage.cnf内容至少包含 host、port、user、password、charsetDB_NAME和TABLE_PREFIX是必填项SKIP_TABLES接收一个逗号分隔的表名列表用于排除个别表LOG_DIR控制日志输出目录。脚本里使用的--init-commandSET SESSION lock_wait_timeout10是专门给 DROP 加锁等待上限用的如果 DROP 语句因为元数据锁一直等不到资源10 秒后会主动报错退出而不是无限挂死。3.3 脚本参数与执行输出实际使用前先在目标库上跑一次 dry-run观察输出是否符合预期DRY_RUN1 DB_NAMEreport_db TABLE_PREFIXtmp_ ./drop_mysql_prefix.sh输出会是类似下面的一行行 DROP 语句同时写入日志文件[2025-01-05 14:20:11] DROP TABLE IF EXISTS report_db.tmp_orders_20240101; [2025-01-05 14:20:11] DROP TABLE IF EXISTS report_db.tmp_orders_20240102;确认清单无误后再正式执行DRY_RUN0 DB_NAMEreport_db TABLE_PREFIXtmp_ ./drop_mysql_prefix.sh脚本参数的核心字段汇总如下参数必填默认值说明CONFIG_FILE否/etc/mysql/manage.cnfMySQL 连接配置避免命令行密码DB_NAME是无目标数据库名TABLE_PREFIX是无要删除的表名前缀DRY_RUN否11 为演练模式0 为实际执行SKIP_TABLES否空逗号分隔的表名白名单LOG_DIR否./logs日志目录每次执行生成独立文件执行结束后日志文件末尾的 summary 行会给出本次删除总数和失败数。如果failed大于 0直接在日志里搜索[FAIL]就能看到具体是哪几张表没删掉以及失败原因。3.4 纯 SQL 方案的适用边界GROUP_CONCAT PREPARE纯 SQL 方案不是不能用在表数量少、连接工具受限时反而更方便。它的标准写法是SET db report_db; SET prefix tmp_; SET sql ( SELECT CONCAT( DROP TABLE , GROUP_CONCAT(CONCAT(, table_schema, ., table_name, )) ) FROM information_schema.tables WHERE table_schema db AND LEFT(table_name, LENGTH(prefix)) prefix ); PREPARE stmt FROM sql; EXECUTE stmt; DEALLOCATE PREPARE stmt;逻辑说明先用子查询把符合条件的表名拼成DROP TABLEdb.t1,db.t2...再用 PREPARE 动态执行。整体只需要一次数据库连接适合在 Navicat 或命令行客户端里临时清理表量不大的环境。参数说明group_concat_max_len默认只有 1024 字节表名一长或者表数量一多就会截断。执行前建议先SET SESSION group_concat_max_len 1048576;并且执行后立刻用SHOW WARNINGS检查是否有截断告警。单条 DROP 涉及的表越多元数据锁范围越大所以这个方案我更建议在低于 50 张表、业务低峰期时使用超过这个量级就直接上 Shell 脚本。4. 删除计划的生成与执行分离跨环境同步清理时先落盘实际清理场景里MySQL 数据库往往不止一套先有预发环境再同步到生产环境两边表结构一致、数据量接近。直接在两套环境各跑一遍脚本虽然可行但没法保证两边删的是同一批表。v1.0 更推荐的方式是生成阶段和执行阶段分开先把 DROP 语句落盘成文件人工 review 之后再喂给 mysql 客户端执行。4.1 生成 DROP 清单把信息模式查询写成可审核文件生成阶段做的事就是把 2.1 节里的 SELECT 结果直接转换成一行行可执行的 DROP 语句mysql --defaults-extra-file/etc/mysql/manage.cnf -N -B -e SELECT CONCAT( DROP TABLE IF EXISTS \, table_schema, \.\, table_name, \; ) FROM information_schema.tables WHERE table_schema report_db AND LEFT(table_name, 4) tmp_ ORDER BY table_name; /backup/drop_list_$(date %Y%m%d).sql逻辑说明CONCAT把库名、表名包装成完整的DROP TABLE IF EXISTS语句IF EXISTS用于容忍表和清单之间的轻微不一致-N -B让 mysql 客户端以制表符分隔、不带列头的方式输出避免把表头混进 SQL 文件。参数说明table_schema和table_name两边都加了反引号这是为了处理表名和库名恰好是 MySQL 保留字的情况比如order、group。生成的文件建议直接放到/backup或专门的变更目录文件名带日期方便留存审计。生成后用wc -l看一下行数再cat抽查首尾各 20 行确认没有混入异常表名。4.2 按清单执行并捕获错误mysql drop_list.sql 的日志用法清单文件确认无误后执行阶段非常简单mysql --defaults-extra-file/etc/mysql/manage.cnf --force \ /backup/drop_list_20250105.sql \ /backup/drop_exec_20250105.log 21逻辑说明把 SQL 文件重定向给 mysql 客户端--force让客户端在单条语句失败后继续执行后面的语句避免因为一张表锁死导致后续几十张表全部停掉。执行日志统一收进drop_exec_20250105.log。参数说明执行结束后重点看日志里有没有ERROR字样grep -n ERROR /backup/drop_exec_20250105.log || echo no error found--force的代价是某几张表删除失败也会被隐藏在后续成功里所以执行后的错误扫描不能省。如果日志中出现ERROR 1146说明表已经不存在属于正常情况出现ERROR 3732或锁等待超时就需要回到第 5 章的排查思路处理。4.3 前后计数对比验证从 N 到 0 才算清理完成删除结束不等于清理完成必须用跟生成清单时完全一致的条件再查一次计数SELECT COUNT(*) AS remaining FROM information_schema.tables WHERE table_schema report_db AND LEFT(table_name, 4) tmp_;逻辑说明如果remaining返回 0说明目标前缀的表已经全部清空如果仍然大于 0说明存在失败表或者有新的程序正在持续创建同前缀表。此时把remaining的表名单和日志里的[FAIL]记录做对比能快速定位问题。跨环境同步清理时我一般会在预发和生产各生成一份清单比对两份文件的行数和表名哈希一致后再分别执行。这样能保证两边删除范围严格一致后续做数据库同步或性能对账时两边基线才对齐。5. 批量删表避坑排查5 个会让脚本翻车的细节批量删除数据表属于高危操作踩坑往往不是脚本没写对而是对 MySQL 的匹配规则、连接行为和锁机制理解不够。下面 5 个问题都是实际清理过程中最容易遇到的。5.1 前缀匹配被 _ 通配符带偏删到不想删的表现象用LIKE tmp_%查询时表清单里多出tmpxxx、tmp2024这类名前缀并不是“tmp_ 下划线”的表。如果直接用这条 SQL 生成删除脚本这些表也会被删掉。原因MySQL 的 LIKE 中下划线_是单字符通配符匹配任意一个字符。tmp_%实际表达的是“tmp 开头 任意第四字符 任意内容”而不是“以 tmp_ 这 4 个字符作为前缀”。解决v1.0 统一用LEFT(table_name, LENGTH(tmp_)) tmp_做前缀判断把下划线当成普通字符处理。如果排查历史 SQL 时遇到底层用了 LIKE 的旧脚本先把查询改成LIKE tmp\_%或直接换 LEFT 写法再向下游生成删除语句。5.2 GROUP_CONCAT 超长被截断一条大 SQL 删到一半语法报错现象用 3.4 节的纯 SQL 方案删几百张表时报You have an error in your SQL syntax而且报错之前部分表已经删掉了。原因group_concat_max_len默认值是 1024 字节拼接的表名超过这个长度后GROUP_CONCAT会静默截断生成的 DROP 语句不完整落到数据库里就是语法错误。更麻烦的是截断不报错只有真正 EXECUTE 时才暴露。解决执行前把会话级参数调大SET SESSION group_concat_max_len 1048576;并且在 PREPARE 之前用SELECT LENGTH(sql)确认拼接后 SQL 的完整长度。更稳妥的做法是直接放弃拼接方案改用第 3 章的逐表删除脚本完全绕开这个限制。5.3 客户端没开多语句一次执行只跑了第一条 DROP现象在图形化客户端或 JDBC 连接上执行一段包含多条 DROP 的 SQL 脚本发现只删了第一张表后面的表纹丝不动也没有报错。原因MySQL 服务端允许一条语句里带多个分号但客户端/驱动需要显式开启多语句支持。JDBC 连接串里默认allowMultiQueriesfalse图形客户端某些模式下也只发送第一条分号前的语句。解决用命令行 mysql 客户端执行 SQL 文件天然支持多语句这也是 4.2 节选择mysql drop_list.sql的原因。如果必须走 JDBC在连接参数里加上allowMultiQueriestrue。逐表删除脚本不受这个限制因为每次连接只执行一条 DROP。5.4 外键引用把 DROP 卡死先查引用关系再决定删除顺序现象删除某张表时报ERROR 3732: Cannot drop table xxx referenced by a foreign key constraint on table yyy或者 DROP 语句一直停在Waiting for table metadata lock。原因如果其他表通过外键引用了待删表DROP 会被外键约束拒绝即使没有外键只要业务会话还在访问待删表DROP 就要等元数据锁释放。批量清理时这两类情况经常同时出现。解决删除前先查外键引用关系把被引用的表从清单里摘出来或者连同引用方一起处理SELECT rc.TABLE_NAME, kcu.REFERENCED_TABLE_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS rc LEFT JOIN information_schema.KEY_COLUMN_USAGE kcu ON rc.CONSTRAINT_SCHEMA kcu.CONSTRAINT_SCHEMA AND rc.CONSTRAINT_NAME kcu.CONSTRAINT_NAME AND rc.TABLE_NAME kcu.TABLE_NAME WHERE rc.CONSTRAINT_SCHEMA report_db AND (rc.TABLE_NAME LIKE tmp\_% OR kcu.REFERENCED_TABLE_NAME LIKE tmp\_%);逻辑说明这条查询会返回所有前缀表身上的外键关系以及它们引用了哪些其他表。看到结果后要么先删子表再删父表要么把这些表从批量删除清单中排除单独人工处理。脚本里的--init-commandSET SESSION lock_wait_timeout10就是用来防止第二类问题的最多等 10 秒拿不到锁就报错退出至少比整个脚本挂着强。5.5 只读库或从库上执行权限通过了照样删不动现象脚本连上数据库后查询正常但每条 DROP 都报The MySQL server is running with the --read-only option一张表都没删掉。原因目标实例开启了read_only或super_read_only常见于从库、灾备库、分析只读副本。普通账号即使拥有 DROP 权限也只读实例也会拒绝所有写操作。解决执行前先确认当前实例角色mysql --defaults-extra-file/etc/mysql/manage.cnf -e \ SELECT read_only AS read_only, super_read_only AS super_read_only, server_uuid AS uuid;read_only1时不要硬删确认这个实例是否允许接收写操作后再处理。还要注意另一种反向风险在主库上执行删除如果同结构表在从库也存在DROP 会通过复制链路同步到从库从库只读属性拦不住复制线程的写操作。批量清理前先确认主从拓扑别把从库当成试验田。6. 进阶玩法先改名再删除给恢复留一颗后悔药批量删除最怕的不是删错而是删完才发现某张“临时表”其实还有报表在凌晨读取。与其事后找备份恢复不如把删除动作拆成两步先改名观察确认无业务影响后再真正删除。6.1 两阶段删除RENAME 到archive前缀观察后再 DROP第一阶段只做重命名把所有tmp_前缀的表改成_archive_tmp_前缀mysql --defaults-extra-file/etc/mysql/manage.cnf -N -B -e SELECT CONCAT( RENAME TABLE \, table_schema, \.\, table_name, \ TO \, table_schema, \.\archive_, table_name, \; ) FROM information_schema.tables WHERE table_schema report_db AND LEFT(table_name, 4) tmp_ /backup/rename_list_$(date %Y%m%d).sql mysql --defaults-extra-file/etc/mysql/manage.cnf /backup/rename_list_20250105.sql逻辑说明RENAME TABLE是 DDL执行后表结构、数据、索引都还在只是表名变了。业务如果缓存了旧的表名会在这一阶段立刻暴露问题此时恢复成本极低执行一条反向 RENAME 就能回到原名。观察一个业务周期确认没有告警和报错日志后再对archive_前缀跑第 3 章的删除脚本就是安全可控的收尾。参数说明加archive_前缀会让表名变长MySQL 的表名长度上限是 64 个字符原名接近上限的表在 RENAME 时会报错生成清单前先用SELECT MAX(LENGTH(table_name))检查一下最长表名。6.2 验证手段information_schema 计数与 binlog 中的 DROP 记录两阶段删除完成后验证工作分两步。第一步是计数验证SELECT (SELECT COUNT(*) FROM information_schema.tables WHERE table_schemareport_db AND LEFT(table_name, LENGTH(archive_)) archive_) AS archived_cnt, (SELECT COUNT(*) FROM information_schema.tables WHERE table_schemareport_db AND LEFT(table_name, LENGTH(tmp_)) tmp_) AS remaining_cnt;如果archived_cnt等于最初删除清单的行数且remaining_cnt为 0说明改名阶段覆盖完整。第二步是 binlog 审计。开启 binlog 的实例上所有 DDL 都会被记录可以确认最终的 DROP 发生时间和涉及表mysqlbinlog --no-defaults --base64-outputDECODE-ROWS -vv /var/lib/mysql/binlog.000012 \ | grep -n DROP TABLEbinlog.000012换成实际的 binlog 文件名。输出里会看到带 GTID 的 DROP 记录时间点和表名一目了然。这两项验证做完一次批量删除才算真正闭环。说句实在话我第一次批量清理同前缀表时就是直接删的结果第二周日终报表来查数才发现少了几张中间表凌晨从备份里翻数据折腾到天亮。从那以后我的默认动作永远是先改名、再删除改名之后观察一个完整业务周期。删除这种操作给自己留一颗后悔药比任何技巧都值钱。希望这个思路也能帮到你。本文还有配套的精品资源点击获取