MySQL删索引必须指定表名，正确语法为DROP INDEX idx_name ON tbl_name；推荐用ALTER TABLE tbl_name DROP INDEX idx_name，删前需确认索引用途及事务状态。
drop index 语法必须带表名，不能只写索引名
MySQL 的 DROP INDEX 语句不支持单独指定数据库和索引名，**必须显式指定所属表**。常见错误是以为像 DROP TABLE 那样可以直接删索引，结果报错 ERROR 1064 (42000) 或提示语法错误。
正确写法是：
DROP INDEXON ;
例如删除 users 表上的 idx_email 索引：
DROP INDEX idx_email ON users;
- 如果表在非当前数据库，需用
db_name.table_name格式，如DROP INDEX idx_status ON myapp.orders; - 索引名区分大小写（取决于操作系统和
lower_case_table_names设置），建议用SHOW INDEX FROM table_name;先确认准确名称 - 不能用反引号包裹整个
ON table_name，只在必要时给表名或索引名加反引号（比如含特殊字符或关键字）
ALTER TABLE DROP INDEX 更通用，推荐日常使用
虽然 DROP INDEX 是标准 SQL，但 MySQL 实际更倾向用 ALTER TABLE ... DROP INDEX，它兼容性更好，且能和其他修改合并执行（比如同时删索引+改字段）。
等效写法：
ALTER TABLE users DROP INDEX idx_email;
- 支持一次删除多个索引：
ALTER TABLE users DROP INDEX idx_email, DROP INDEX idx_created_at; - 对主键、唯一约束、外键对应的索引，该语句会一并处理约束逻辑（比如删主键会自动删 PRIMARY KEY 索引）
- 执行时会锁表（InnoDB 在 5.6+ 支持在线 DDL，但删二级索引仍需短暂的元数据锁）
误删主键或唯一索引可能引发外键或业务异常
删索引不是“无害操作”。尤其以下情况容易出问题：
- 删的是
PRIMARY KEY：表将失去主键，INSERT可能因隐式自增冲突失败；已有外键引用该主键的子表会报错ERROR 150 - 删的是
UNIQUE约束索引：原本靠该索引保证的字段唯一性将失效，后续INSERT可能插入重复值而不报错 - 删的是查询高频使用的索引：慢查询可能立刻回归，监控中 QPS 下降、
Handler_read_next激增都是信号
操作前务必确认：SHOW CREATE TABLE table_name; 查看索引是否绑定约束，以及业务代码是否依赖该索引加速 WHERE / ORDER BY。
无法删除正在被事务持有的索引
如果另一个连接正持有该表的活跃事务（尤其是未提交的 UPDATE / DELETE），DROP INDEX 会卡住，直到事务结束或超时（默认 lock_wait_timeout=50 秒），最终报错 ERROR 1205 (40001): Deadlock found 或 ERROR 1206 (HY000): The total number of locks exceeds the lock table size。
排查方法：
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'RUNNING';
- 优先检查
TRX_STARTED时间较早的事务 - 结合
information_schema.PROCESSLIST看对应线程的INFO列是否有长事务 SQL - 生产环境避免在高峰期执行，可先在从库验证语法，再选低峰窗口操作
真正麻烦的不是语法怎么写，而是删完之后发现某个报表接口突然变慢三倍，或者凌晨三点收到唯一性校验失败的告警——索引删得干净，但业务没准备好。
