动态索引创建 - SQL Server答案

【问题标题】：Dynamic Index Creation - SQL Server动态索引创建 - SQL Server
【发布时间】：2016-08-19 01:20:29
【问题描述】：

好的，所以我为一家销售具有 MS SQL Server 后端的网络产品的公司工作（可以是任何版本，我们刚刚将我们的要求更改为 2008+，因为 05 已不再提供扩展支持）。所有数据库都归购买产品的公司所有，但我们有 VPN 访问权限，并且有技术支持部门来处理任何问题。我的职责之一是充当 SQL 问题的第三线支持。

当关注性能时，通常的检查之一是未使用/缺失索引。我们有通常的标准索引，但取决于哪些模块或公司如何使用系统，那么它将需要不同的索引（其中有一个会计模块和一个文档管理模块）。对于数百个客户，不可能定期远程访问每个客户以执行优化工作。我想知道在我的职位上是否有其他人考虑过可以在需要时删除和创建索引的计划任务？

我有顾虑（显然），此过程所做的任何更改也将存储在包含更改的完整详细信息和时间戳的表中。我需要这个是防弹的，如果它可能会导致问题，就不能将它发送到野外。我正在考虑一个通宵或（可能）每周的任务。

删除索引：

要求服务器至少运行一段时间，以确保所有相关的服务器统计信息都是最新的（例如 2 周或 1 个月）。
仅删除正在使用的表的未使用索引（系统未使用部分的索引不是问题）。
记录下来。
这不会突出显示重复的索引（必须手动），只会突出显示快速获胜（写入时未使用的索引）。

创建索引

仅查找值高于某个阈值的索引。
必须检查是否可以修改任何类似的索引来满足要求。这可能是一个排名（检查所有索引字段是否相同，然后对包含的字段进行评分，看看是否需要额外的字段）。
限制要创建的索引的最大数量（例如每周 5 个），以确保它不会被忘却并一次创建一堆）。这应该有助于只关注最重要的索引。
记录下来。

这需要是动态的，因为我们在不同版本的系统上拥有不同使用模式的客户。

澄清一下：我不希望任何人为此编写代码，这更像是一个与此类任务的可行性和关注点有关的问题。

编辑：我已经为此提供了赏金，以收集一些进一步的意见，并从以前可能尝试过此操作的任何人那里获得反馈。在赏金持续时间结束时，我会将其奖励给投票最多的答案。

【问题讨论】：

为什么要从 SQL Server 2005 升级到 SQL Server 2008，而不是 2014 或 2016？
我可以看到删除未使用的索引，但动态创建索引似乎是个坏主意。您应该使用缺少的索引作为建议，并评估它们是否真的是一个好主意。你必须着眼于更大的图景。我曾多次建议索引，但我可以向现有索引添加另一列并节省一些空间但提高性能。只是说，我会格外小心。
这里有一些相关链接dba.stackexchange.com/a/44002/3690
简而言之：这是一个难题（在 NP 硬意义上）。通过删除索引，您可能会面临在财政年度结束时生成“非常重要的报告”需要几天而不是几分钟的风险，并且系统的其余部分在此期间几乎无法使用。如果创建太多索引，优化器将开始无法选择最佳执行计划。将有太多可能的变体供优化器分析。 @MartinSmith 链接到 dba.se 很棒。
也许你想看看这里：brentozar.com/blitzindex 这个网站有一堆针对 MS-SQL-Servers 的优化内容，链接的 SP 会为你提供建议。

标签： sql sql-server indexing scheduled-tasks

【解决方案1】：

我无法推荐您正在考虑的内容，但您可以通过收集您所考虑的计划的输入并将其提供给客户和支持团队来简化您的生活。

如果问题像您想象的那么简单，那么服务器本身或优化顾问现在肯定已经解决了。你至少做了一个毫无根据的假设，

要求服务器至少运行一段时间，以确保所有相关的服务器统计信息都是最新的。

表统计信息仅与上次在重大更改后更新时一样好。正常运行时间不能保证 截断表 或批量插入。

这不会突出显示重复的索引

但这是您可以在使用系统表的单个查询中执行的操作。（如果调整小工具对这些没有帮助，那将是令人失望的。）您可以类似地查找重叠索引，例如列 {a,b} 和 {a}；第二个不会有用，除非 {b} 是选择性的并且有没有提到 {b} 的查询。

为了寻找新的索引，我很想尝试检测查询使用频率并自动分析查询计划输出。如果您可以识别经常使用的、长时间运行的查询并将它们的物理操作（表扫描、哈希连接等）映射到表和现有索引上，那么您将有很好的输入来添加和删除索引.但是您必须考虑到不经常运行的季度报告，如果没有其他未使用的索引，则需要数天才能完成。

我必须告诉你，当我几年前进行这种分析时，我很失望地得知大多数问题儿童都是糟糕的查询，通常是由糟糕的表格设计引起的。没有索引会帮助 SQL 骡子。希望这不会是你的经历。

您未提及但可能同样重要的一个方面是机器容量。例如，您可能会考虑收集 SQL Server 统计信息的每小时快照，例如磁盘队列深度和分页。几乎不存在无法通过更多 RAM 改进的服务器，有时这确实是最好的答案。

【讨论】：

【解决方案2】：

值得一试的 SQL 性能调优顾问：https://msdn.microsoft.com/en-us/library/ms186232.aspx

另一种方法是获取性能数据，从这里开始：https://www.experts-exchange.com/articles/17780/Monitoring-table-level-activity-in-a-SQL-Server-database-by-using-T-SQL.html 并根据性能表数据生成索引

也检查一下：https://msdn.microsoft.com/en-us/library/dn817826.aspx

【讨论】：