基于索引记录表编写脚本重建Azure同步本地DB索引的可行性咨询

结论 #

这个方案完全可行，就是这类受限场景下的常规操作思路。

为什么行得通 #

• 你手里的索引信息表已经凑齐了重建索引的核心要素：架构名、表名、索引名、列名，足够生成对应的CREATE INDEX语句
• 只要按索引维度把同属一个索引的列拼起来，就能批量生成适配本地库的索引创建脚本

实操时要注意的关键点 #

• 按索引分组：同一个索引会对应多行数据（每个列一行），所以必须按Schema Name+Table Name+Index Name分组，把列按顺序拼接——要是漏了分组，会生成一堆单列索引，完全不对
• 索引属性补全：原表没记录索引的额外属性，比如是不是唯一索引、聚集索引，列是升序还是降序，有没有包含列这些。如果源索引有这些特性，得让对方把这些字段补上，不然只能重建普通的非聚集索引，效果打折扣
• 语法兼容性：得确认本地数据库和Azure SQL的索引语法匹配度（比如SQL Server本地和Azure基本一致，但换MySQL的话语法就得调）
• 执行时机：一定要等ETL同步完所有表数据再跑索引脚本，不然同步过程中频繁更新索引，性能会崩

示例脚本（SQL Server环境） #

-- 按索引分组生成创建语句
SELECT DISTINCT
    'CREATE NONCLUSTERED INDEX [' + [Index Name] + '] ' +
    'ON [' + [Schema Name] + '].[' + [Table Name] + '] ' +
    '(' + STRING_AGG('[' + [Column Name] + ']', ', ') WITHIN GROUP (ORDER BY 
        -- 这里注意：如果源表有记录列顺序的字段，替换成那个字段，不然列顺序可能错
        [Column Name] 
    ) + ')' AS CreateIndexScript
FROM [你的索引信息表名]
GROUP BY [Schema Name], [Table Name], [Index Name]
-- 生成后可以导出执行，或者用动态SQL直接跑

额外提醒 #

• 先在测试环境跑一遍，对比生成的索引和源库的是不是一致，别漏了关键属性
• 主键索引要单独确认：如果源表的主键是通过索引实现的，得看索引信息表有没有包含主键的记录，主键的创建语法是CREATE PRIMARY KEY，和普通索引不一样

内容的提问来源于stack exchange，提问作者PatBentley921