SqlServer 索引自动优化工具

接手一项优化项目，目标是针对公司现有的超过一万张数据库表进行索引优化，包括完善现有索引、剔除无效索引。面对人手不足（仅两个半人的资源）和程序结构限制（无法进行全面革命，只能进行改良），决定开发自动化工具来处理这一任务。尽管原型已开发完成，但在团队会议上遭到了运维DBA团队的强烈抵制，项目被迫无限期延期。现将优化思路分享如下，欢迎批评指正。

具体解决方案如下：

1. 在热备的数据库服务器上定期抓取缓存的执行计划。由于部分SQL执行计划难以自动化，我们选择抓取执行计划而非SQL。这些执行计划是格式良好的XML文件，我们可以结合微软提供的执行计划XSD文件来。

2. 将执行计划以及执行次数、表的统计信息一并传输至备用服务器的数据表中。执行计划积累多次后开始，通过执行计划中的节点，我们可以反向推出各节点对应的SQL谓词。我们关注三类谓词：Select、Join、Where。这些谓词有助于我们建立良好的索引。

3. 执行计划时，我们针对所有执行计划进行统计处理，以了解哪些表字段被频繁引用，哪些字段是外键等。例如，我们可以得知TableA的Col1列在一天的业务过程中被Join了10万次，被Where引用了2万次等。这些信息为我们建立索引提供了依据。我们根据查询频率和查询的重要性来创建索引，对于重要的查询但执行频率不高的可以给予权重优先建立索引。创建索引时还需考虑表的数据分布来决定Index中字段的顺序。

4. 准备工作完成后，开始建立索引。根据表数据分布、表字段的查询引用次数（Select、Join、Where）以及这些SQL谓词出现的次数等信息，我们考虑如何创建索引。考虑到电脑智商的限制，我们选择根据执行计划得出的组合创建所有可能的Index组合。例如，对于某个查询语句“select t1.A, t1.B, t1.C, t2.J, t2.k from Table1 t1 Join Table1 t2 on t1.A = t2.j Where t1.A = 'param'”，我们创建的索引包括Index（A，B）includ 和 Index（j）include（j,k）。对于Select涉及的字段，如果是小数据类型且修改频率较小的，可以放入Include中；如果是大数据类型或修改频繁的则不考虑。然后剔除相互覆盖的、部分重叠的索引，合并相似的索引等。最终留下的就是我们需要建立的索引。

5. 对比现有索引进行甄别覆盖的过程相对简单，通过Create Index语句即可完成。发布时，写一个脚本在业务较少的时候进行Drop和Create操作即可。由于涉及到公司保密问题，项目源代码无法上传。另外需要注意的是，对于简单查询的SQL执行计划缓存时间较短且容易被清理掉，需要注意这些SQL的执行频率误差。

关于SqlserverR2 XSD的节点映射，查询的sql执行计划都包含在节点“StmtSimple”中，如果没有这个节点一般是其他类型的SQL的执行计划。在数据处理的世界时，我们经常会遇到Join操作，这是数据库查询语言的核心组成部分之一。如何连接相关的节点以及它们与自身类型的关系，通常在Hash和Marger等结构中有所体现。当涉及Join的列是如何结合时，它们主要在SeekKey和Compare节点间形成。由于Join的列通常是成对出现的，因此这一过程相对容易识别。若其中出现以@开头的参数或标记为“Const”的常量，那么它们很可能被用作Where条件来过滤数据。

而在查询结果的输出部分，Select语句的最终输出字段更是显而易见。它们通常位于第一个OutputList节点中，这里集中了查询所需要返回的所有字段信息。在查找这些字段时，需要注意一点，通常每个ColumnReference都会包含库名、表名和列信息，但对于系统表来说，则可能不包含这些信息。在理解和处理这些信息时，我们需要细心甄别，剔除不必要的部分。

此刻，我们的讨论暂时告一段落，让我们借助某种神秘的力量将上述内容渲染出来。想象一下，如果我们调用名为“cambrian”的某个工具或方法的“body”功能，它会以某种方式展示上述内容。这不仅仅是一段文字的简单呈现，更是一场数据的视觉盛宴。在这个世界中，Join操作的每一环节都被清晰地呈现出来，Select的输出字段引人注目，一切都显得那么有序和生动。通过这种方式，数据处理变得不再晦涩难懂，而是充满了乐趣和吸引力。