索引空间大于数据空间是不是很糟糕？

Question

我经常需要对没有正确索引的大表运行查询。所以我要求 DBA 创建这样的索引。他做的第一件事是查看表统计信息并查看索引空间大小。

通常他会告诉我寻找替代解决方案，因为“索引已经大于表”。他觉得索引必须比数据小，因为，他告诉我“你见过书里的索引吗？它比书本身小得多，表索引应该是这样的”。

我不认为他的哲学是正确的，但我不能挑战他，因为他是一名首席 DBA 而我是一名开发人员。我觉得如果一个查询需要一个索引，就应该创建索引，而不是寻找只会使 SP 变得不可读和不可维护的“解决方法”。

我只选择所需的列。问题是我按日期过滤，因此引擎必须进行表扫描以匹配列。该查询每天在晚上运行一次以收集统计信息，但运行需要 15 分钟（我们还有另一个硬性规定：任何过程都不应超过 3 分钟）。

DBA 向我展示了索引统计信息。该表上大约有 10 个索引，其中仅使用了 6 个（统计数据显示其中 4 个的命中率为零）。这是一个有 20 多个开发人员参与的大型系统。无论出于何种原因创建索引，可能不再使用。

我们需要支持 SQL Server 2008，因为这是运行测试数据库的。但客户都在 2014 年和 2016 年。

Answer 1

把索引设计想象成一个滑动开关。您可以将这个红色三角形开关旋钮沿着您想要的线移动到任意位置：

我通常不以大小来衡量它 - 我通常会根据索引数量来衡量它，但大小也可以。

听起来您的 DBA 认为切换到右侧太远了 - 您添加了太多索引，并且删除/更新/插入的执行速度太慢。

与其争论交换机在哪里，不如试着向他询问由于大量索引而导致的性能问题。也许您的用户抱怨删除/更新/插入速度，或者他看到锁定等待，或者由于数据库的大小，他很难备份数据库。

我的起点通常是 5 和 5：每个表大约有 5 个索引，每个索引大约有 5 个或更少的字段。这个数字没有什么神奇之处——它只是因为我每只手有 5 个手指，所以很容易举起手来解释规则。

当您的工作负载严重偏向于删除/更新/插入操作，并且您没有足够的硬件能力来跟上时，您可能需要有许多少于 5 的 LESS 索引。

当您的工作负载大部分是只读的，或者当您大量投资于硬件（例如将整个数据库缓存在内存中，并在其下放置所有固态存储时，您可能能够拥有更多索引。）

Answer 2

我喜欢布伦特的回答，我赞成。不过，我想补充另一个观点。我曾作为用户、开发人员和 DBA 工作过，觉得这些意见无关紧要。我相信由用户（或利益相关者）决定查询的执行方式以及获得结果所需的时间。然后由开发人员和 DBA 共同努力实现它。

如果您公司的 DBA 职位“负责”这个主题，他们可以分析您的查询并就更好的查询设计提出建议，或者回答性能问题。

如果不能通过修改查询和/或数据结构来实现目标，那么我认为可以归结为三种选择。

当然，根据多种业务和技术因素，每种情况都有许多变数，但我相信这三个选项适用于大多数情况（如果不是全部的话）。