在SQL Server中，假设我有一个非常大的表（列A到Z），它具有A上的CLUSTERED PRIMARY KEY和一个列B，C，D上包含E，F，G的唯一非结束索引IX1。 然后我需要用D，C，B中的新的NONCLUSTERED索引IX2覆盖另一个查询，包括J，K，M。
由于IX1已经在B，C和D之间强制实现唯一性，所以创buildIX2 UNIQUE也是有意义的吗？ 有没有严重的优点和缺点？
如果您的索引是唯一的，那么告诉SQL它是唯一的。 优化器可以使用额外的信息，这样做没有任何缺点。
那就是说，你真的需要第二个索引吗？ 是其他一些查询使用的密钥的不同顺序？ 如果不是的话，为什么不直接在第一个索引中添加额外的包含列，从长远来看可能会更便宜。
我不确定具体情况如何发挥，但你应该能够testing出来没有太多的麻烦。
在开发环境中（如果存在的话）尝试在两种情况下运行查询并检查执行计划。 如果第二个索引阻止表扫描，那么很有可能它是值得的。 如果你发现第一个索引真的在做所有的工作，那么它可能不是。
在索引方面，我没有看到任何重要的缺点。 如果您开始添加太多的插入，更新和删除可能会开始变慢，并占用更多的磁盘空间。