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，后续请求若没及时重建表结构，就会直接报错。
