sp_rename是sql server中唯一支持直接重命名索引的机制，但不可盲目批量执行：需过滤非约束附带的普通索引，生成可审核语句并人工确认，再事务化执行；mysql则须drop+add模拟，且须校验字段顺序与约束依赖。
sp_rename 是 SQL Server 中唯一支持直接重命名索引的机制，但不能用存储过程“一键批量执行所有重命名”而不加甄别——因为索引名在表内必须唯一、不能与约束同名、且 sp_rename 对某些系统生成的索引（如主键/唯一约束附带的隐式索引）会触发连锁变更，稍有不慎就导致元数据错乱或应用报错。
为什么不能直接遍历 sys.indexes + EXEC sp_rename 一把梭？
常见翻车点包括：
- 对 PRIMARY KEY 或 UNIQUE 约束关联的索引调用 sp_rename，会连带重命名约束本身，而约束名可能被其他脚本硬编码引用；
- 同一表中存在多个索引时，若新名重复（比如都叫 IX_auto_1），sp_rename 直接报错：The specified index name 'IX_auto_1' is already used in the table.；
- 动态 SQL 中未处理特殊字符（如中括号、点号、空格），导致 @objname 格式非法，报错：Incorrect syntax near '.'；
- 忽略了索引所属 schema，传入 table.index 但实际是 [schema].[table].[index]，sp_rename 找不到对象。
安全批量重命名前必须做的三件事
先确认目标索引范围：只操作用户创建的、非约束附带的、非 XML/空间索引的普通索引：
- 过滤条件必须包含：type IN ('NONCLUSTERED', 'CLUSTERED') 且 is_primary_key = 0 AND is_unique_constraint = 0；
- 排除系统表：OBJECTPROPERTY(o.object_id, 'IsMSShipped') = 0；
- 排除已禁用索引：is_disabled = 0。
再生成可审核的重命名语句列表，不要直接 EXEC：
- 使用 SELECT 'EXEC sp_rename ''' + s.name + '.' + t.name + '.' + i.name + ''', ''IX_' + t.name + '_' + CAST(ROW_NUMBER() OVER (PARTITION BY t.object_id ORDER BY i.index_id) AS VARCHAR(5)) + ''', ''INDEX'''；
- 每条语句单独一行，复制到新查询窗口人工过一遍，检查命名冲突、schema 是否一致、是否漏掉关键索引。
最后才考虑自动执行，且必须套事务 + TRY/CATCH：
- 每次只处理一个索引，失败立即 ROLLBACK；
- 记录日志表（如 #rename_log）存原名、新名、执行状态、错误信息；
- 避免在生产库上跑游标循环，优先导出语句 → 审核 → 分批粘贴执行。
MySQL 用户注意：没有 sp_rename，只能 DROP + ADD
MySQL 不支持索引重命名语法，所谓“批量改名”本质是拼接两步操作：
- ALTER TABLE `table_name` DROP INDEX `old_name`, ADD INDEX `new_name` (`col1`, `col2`);；
- 必须从 information_schema.statistics 查字段顺序（seq_in_index）和是否为前缀索引（sub_part）；
- 组合索引要按 GROUP_CONCAT(column_name ORDER BY seq_in_index) 拼字段名，否则新建索引结构错乱；
- 如果表上有外键或全文索引，DROP INDEX 可能失败，需先查 information_schema.KEY_COLUMN_USAGE 和 information_schema.STATISTICS 做兼容性判断。
真正卡住人的从来不是“怎么写 SQL”，而是重命名后谁还在用旧名——视图、存储过程、ORM 映射、监控脚本里硬写的索引提示（WITH (INDEX(...))）全都会失效。动手前花十分钟 grep 代码库，比写一百行动态 SQL 更重要。
