MySQL不支持直接“升级”单列索引为联合索引，必须分两步：先DROP旧索引，再ADD新联合索引；需注意命名不冲突、列顺序符合最左前缀原则，并验证索引生效及性能影响。
ALTER TABLE 不能直接“升级”索引
MySQL 不支持用单条 ALTER TABLE ... MODIFY INDEX 之类语句把一个已有的单列索引“升级”成联合索引。所谓“升级”，本质是删除旧索引 + 新建联合索引两个动作，必须显式分步执行。
常见错误是试图写类似 ALTER TABLE t ADD INDEX idx_a_b (a, b) ON INDEX idx_a —— 这种语法根本不存在，会报错 ERROR 1064。
正确操作：先 DROP 再 ADD，注意顺序和命名
假设你已有单列索引 idx_user_id 在 user_id 列上，现在想扩展为 (user_id, status, created_at) 的联合索引：
- 必须先删掉旧索引：
ALTER TABLE orders DROP INDEX idx_user_id; - 再建新联合索引：
ALTER TABLE orders ADD INDEX idx_user_id_status_created (user_id, status, created_at); - 索引名建议带全字段名（如
idx_user_id_status_created），避免后续混淆；不要复用旧名，否则DROP后ADD可能因命名冲突失败 - 列顺序不能随意调换——
user_id是等值查询高频字段，放最左；status区分度中等，放中间；created_at常用于范围查询，放最右（符合最左前缀原则）
为什么不能保留旧索引同时加联合索引？
可以保留，但通常不推荐，原因很实际：
- 冗余索引会拖慢
INSERT/UPDATE/DELETE性能，每写一行就要维护多个索引树 -
user_id单列索引在联合索引(user_id, status, created_at)下完全被覆盖——所有命中单列索引的查询，联合索引也能处理，且可能更优（比如还能顺便过滤status） - 例外情况：如果存在大量只查
user_id且对延迟极度敏感的旧业务，可短暂双存，但需监控SHOW INDEX FROM orders和慢查日志，确认无冗余后再清理
执行前必须验证的三件事
大表上操作前漏掉任何一项，都可能卡住线上服务：
- 查当前索引状态：
SHOW INDEX FROM orders WHERE Key_name = 'idx_user_id';确认旧索引真实存在且未被误删 - 预估重建耗时：对千万级以上表，
ALTER TABLE ... ADD INDEX是阻塞 DML 的（除非用ALGORITHM=INPLACE且引擎支持，InnoDB 5.6+ 多数情况支持，但需确认） - 用
EXPLAIN测试新索引是否真被用上：EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';看key字段是否显示你的新索引名，Extra是否含Using index（覆盖索引）
最左前缀不是玄学，是 B+ 树搜索路径的硬约束；删索引不是删文件，而是释放页、更新元数据——这些动作在高并发写入场景下容易成为瓶颈点。
