MySQL中ALTER TABLE ADD INDEX失败通常因锁冲突、权限不足或约束校验，而非数据丢失；需检查长事务、INDEX权限、唯一性重复及字符集影响。
ALTER TABLE ADD INDEX 报错 ERROR 1022 或事务自动回滚
加联合索引失败但数据“看起来没保存”，大概率不是索引本身问题，而是 ddl 执行中途被中断或回滚了。mysql 在 alter table 过程中会尝试获取表级元数据锁（mdl），如果此时有长事务、未提交的 select ... for update 或其他 dml 正在执行，ddl 就会卡住甚至超时失败——而客户端可能只看到报错，误以为“数据丢了”。
- 检查是否有未提交事务：
SELECT * FROM information_schema.INNODB_TRX;，重点关注trx_started时间过长的记录 - 确认是否启用了
autocommit=0：如果在会话里手动关了自动提交，又没显式COMMIT，后续 DDL 可能被隐式回滚（尤其在某些客户端工具里） - 留意错误码：
ERROR 1022 (HY000): Can't write; duplicate key in table表示索引名冲突，不是权限或回滚问题；ERROR 1205 (40001): Deadlock found则说明和其它事务抢锁了
用户没有 INDEX 权限导致 ALTER 失败但无明确提示
MySQL 的 INDEX 权限是独立控制的，哪怕你有 SELECT、INSERT、UPDATE 全部权限，缺了 INDEX 也会让 ALTER TABLE ... ADD INDEX 静默失败（部分版本返回 ERROR 1142: INDEX command denied，但有些客户端只显示“Query interrupted”）。
- 验证权限：
SHOW GRANTS FOR 'your_user'@'host';，确认输出里包含INDEX - 授予权限（需高权限账号执行）：
GRANT INDEX ON your_db.your_table TO 'your_user'@'host'; - 注意：
GRANT ALL PRIVILEGES不包含INDEX，它属于 DDL 权限，必须显式声明
联合索引创建成功但 INSERT/UPDATE 被拒绝
这不是“数据无法保存”的假象，而是约束生效了。比如你在 (a, b) 上建了唯一联合索引，但已有重复组合值，MySQL 会在建索引时校验并报错；或者建完后插入违反唯一性/非空约束的数据，就会直接拒绝写入。
- 建索引前先查重复：
SELECT a, b, COUNT(*) FROM your_table GROUP BY a, b HAVING COUNT(*) > 1; - 检查字段是否允许 NULL：
DESCRIBE your_table;，若a是NULL，多个(NULL, x)在唯一索引下是允许的（MySQL 特性），但业务逻辑可能误判为“重复” - 注意字符集影响：如果列用的是
utf8mb4_unicode_ci，'A'和'a'可能被视作重复，导致唯一索引插入失败
事务回滚后发现新索引“消失”，其实是预期行为
MySQL 5.6+ 对大多数 ALTER TABLE 操作支持在线 DDL，但**索引创建本身不参与事务回滚**——也就是说，如果你在一个事务里执行 ALTER TABLE ... ADD INDEX，然后执行 ROLLBACK，索引仍然会留在表上。所以如果你“回滚后索引没了”，那说明你根本没在事务里建索引，或者建索引语句压根没执行成功（比如被锁阻塞后超时退出）。
- 不要把 DDL 当作可回滚操作来设计逻辑；它本质上是立即生效的元数据变更
- 想安全试错？先在测试库用
CREATE TABLE ... AS SELECT复制一份表结构和数据，再操作 - 生产环境加索引务必避开高峰期，并监控
information_schema.PROCESSLIST中的State字段，如出现Waiting for table metadata lock就得立刻排查源头
真正容易被忽略的点是：索引创建过程本身不会导致已有数据丢失，但失败时的错误信息常被日志截断或客户端吞掉。别急着重试，先看 SHOW ENGINE INNODB STATUS\G 里的 LATEST FOREIGN KEY ERROR 和 LATEST DETECTED DEADLOCK 区块——那里往往藏着锁冲突的真实原因。
