DROP TABLE 必须加 IF EXISTS 防表不存在报错，多表用逗号分隔；DROP INDEX 依赖引擎，InnoDB 可直接用，MyISAM 推荐 ALTER TABLE；误删不可回滚，恢复依赖 binlog 或备份。
DROP TABLE 删除表的正确写法和常见报错
直接执行 DROP TABLE 前必须确认表存在，否则会报错 ERROR 1051 (42S02): Unknown table。MySQL 默认不支持 IF EXISTS 以外的容错语法，所以推荐始终加上这个子句。
- 安全删除写法：
DROP TABLE IF EXISTS <code>user_log</code>;
- 如果要一次删多个表，用逗号分隔：
DROP TABLE IF EXISTS <code>tmp_order</code>, <code>tmp_payment</code>;
- 注意：即使加了
IF EXISTS，若表名拼错或权限不足（如没有DROP权限），仍会报错，只是不会因“表不存在”失败 - 删除后，表结构、数据、关联的触发器、分区定义全部消失，不可回滚（事务中也不行）
DROP INDEX 删除索引的语法与引擎限制
DROP INDEX 不能单独使用，必须指定所属表，且对不同存储引擎行为不一致。InnoDB 支持该语法，但 MyISAM 要求用 ALTER TABLE ... DROP INDEX 才可靠。
- 标准写法（InnoDB 推荐）：
DROP INDEX <code>idx_user_email</code> ON <code>users</code>;
- MyISAM 或兼容性更强的写法：
ALTER TABLE <code>users</code> DROP INDEX <code>idx_user_email</code>;
- 主键索引不能用
DROP INDEX删除，必须用ALTER TABLE <code>users</code> DROP PRIMARY KEY;
；若表有自增列，还需先去掉AUTO_INCREMENT - 全文索引（FULLTEXT）需显式声明类型：
ALTER TABLE <code>articles</code> DROP INDEX <code>ft_title_content</code>;
（不能用DROP INDEX）
误删后能否恢复？关键看有没有备份和 binlog
MySQL 的 DROP 操作不进 undo log，事务中也无法回滚。恢复唯一可行路径是依赖外部机制。
- 有开启
binlog且格式为ROW或MIXED：可用mysqlbinlog解析日志，找到DROP前的INSERT/UPDATE/DELETE事件重放，但无法还原表结构 - 只有
STATEMENT格式 binlog：基本无法精确恢复，因为DROP本身不记录行级变更 - 没开 binlog 且无定期 mysqldump / xtrabackup 备份：物理文件被释放后，只能尝试从磁盘底层扫描恢复，成功率极低
- 开发环境可临时启用
sql_log_bin=0阻断当前会话写 binlog，但不影响DROP执行本身
自动化脚本中避免误删的两个硬约束
批量操作时，光靠人工核对表名极易出错。必须在脚本里加入校验逻辑，而不是只依赖 SQL 语法。
- 先查表是否存在再删：
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = '<code>mydb</code>' AND table_name = '<code>old_config</code>';
结果为 1 再执行DROP - 禁止在生产环境脚本中出现裸
DROP TABLE <code>xxx—— 必须带IF EXISTS，且建议加注释说明删除原因，例如：-- 清理已下线模块的临时表，2024-04 停用
- 索引名容易拼错，建议从
information_schema.statistics查询确认：SELECT index_name FROM information_schema.statistics WHERE table_schema='<code>mydb</code>' AND table_name='<code>orders</code>' AND index_name LIKE 'tmp_%';
实际执行 DROP 类操作时，最常被忽略的是权限粒度和上下文隔离——比如用 root 连接执行没问题，但应用账户可能只被授予了 SELECT, INSERT，删表会静默失败；又比如在连接池复用场景下，一个连接执行了 DROP，后续请求若没及时重建表结构，就会直接报错。
