Navicat不支持右键多选表批量删除，仅删除焦点表；可靠方式为SQL动态生成DROP语句或导出编辑重建；删前须检查外键、视图/存储过程引用及应用硬编码依赖。
Navicat里不能右键多选表后批量删表
Navicat 的对象列表（左侧数据库树）不支持 Ctrl+Click 或 Shift+Click 多选多个表，再点击“删除”就批量干掉——你点删除，只会删掉当前焦点所在的那一个表。哪怕你看着高亮了五六个，实际生效的只有最后一个被鼠标点中的表。
这个 UI 行为从 Navicat 15 到最新 17.x 版本都一致，不是 bug，是设计逻辑：删除动作绑定的是单个对象上下文，而非选区集合。
真正能批量删表的两种可靠方式
想一次性清理一批无用表（比如 tmp_*、backup_*、测试表），必须绕过图形界面，走 SQL 或脚本生成路径：
-
SQL 方式（推荐，可控、可预览）：在查询窗口执行动态生成语句。MySQL 示例：
SELECT CONCAT('DROP TABLE `', table_name, '`;') FROM information_schema.tables WHERE table_schema = 'your_db_name' AND table_name REGEXP '^tmp_|^backup_|^test_';运行后复制结果，粘贴执行——每行都是独立的DROP TABLE，删前还能人工核对表名 -
导出 + 批量编辑 + 重建（适合需保留部分表）：右键数据库 → “转储 SQL 文件” → “结构和数据” → 用文本编辑器搜索
CREATE TABLE `xxx`，删掉不需要的建表块，再把改好的 SQL 导入新库；本质是“重建目标库”，但规避了在线删表的锁风险
删表前必须检查的三类硬性依赖
误删表比误删数据更致命——表一没，所有依赖它的视图、存储过程、外键、应用 ORM 映射全崩。动手前务必确认：
-
information_schema.KEY_COLUMN_USAGE中查该表是否被其他表设为外键引用（REFERENCED_TABLE_NAME = 'your_table'） - 搜
SHOW CREATE VIEW和SHOW CREATE PROCEDURE输出，看是否有视图或过程显式引用该表名 - 检查应用代码里是否硬编码了该表名（尤其 Java 的
@Table(name = "xxx")、Python 的 SQLAlchemy__tablename__ = "xxx"）
哪怕表名带 _bak，也不代表它没被下游调用——有团队真把备份表当只读源表用。
为什么不用 TRUNCATE + DROP 组合？
有人想先 TRUNCATE TABLE 清空再 DROP TABLE，纯属多此一举。直接 DROP TABLE 就清空+删结构两步到位，且 MySQL 下它比 TRUNCATE 更快（不走事务日志重放）。唯一例外是：表被其他会话正在读写，DROP 可能卡住，此时可先 TRUNCATE（释放空间）再 DROP（但仍是两步）。
重点不是快慢，而是——删表操作不可逆，没有回收站，也没有 UNDO。所有批量删表动作，必须基于完整备份 + 明确清单 + 低峰期执行。别信“我就删几个临时表”，线上环境里，临时表往往最不临时。
