1

有哪些方法可以识别覆盖索引中的多余列：从不搜索的列，因此可以提取到包含中，甚至完全删除而不影响索引的适用性？

4

2 回答 2

2

澄清一下覆盖索引
的想法是它还包括可能不被搜索的列（在 WHERE 子句等中使用）但可能被选择（SELECT 列列表的一部分）。

似乎没有任何简单的方法可以断言覆盖索引中存在未使用的列。我只能想到下面一个艰苦的过程：

  • 在一个有代表性的时间段内，记录在服务器上（或所需的表上）运行的所有查询
  • 过滤掉（通过正则表达式）不涉及基础表的查询
  • 对于剩余的查询，获取查询计划；丢弃不涉及相关索引的查询
  • 对于剩余的查询，或者更确切地说，对于查询的每个“模板”（许多查询是相同的，但对于搜索条件值），列出索引中在 select 或 where 子句（或在 JOIN.. .)
  • 该列表中未找到的索引中的列非常好。

现在，可能还有更多[要删除的列]，因为上面的过程不会检查覆盖索引在哪个上下文中使用（它可能用于解析 where，但仍然可以访问基础表以及（例如获取不在覆盖索引中的列......）

上述临床方法相当缺乏吸引力。 分析方法可能更可取：

查找可能在使用服务器的所有应用程序中使用的所有查询“模板”。对于这些模式中的每一个，找到可能正在使用覆盖索引的模式。这些是（又是几个漏洞......）查询：

  • 包括对基础表的引用
  • 不要以任何方式引用基础表中不是索引中的列的列
  • 不要使用比索引列更具选择性的基础表中的搜索条件（按它们的顺序......）

或者......甚至不去应用程序：想想所有的用例，如果查询服务于这些用例将不会受益于索引中的所有列。这样做意味着您对索引的前几列的选择性有一个相对较好的了解。

于 2009-10-09T19:45:36.057 回答
0

如果您对您的用例和数据点进行审计，显然任何未在审计中使用或捕获的内容都可能被删除。如果数据库缺乏如此彻底的审计，您可以通过运行跟踪并保存它来保存一个时间窗口的访问数据库的查询。您可以分析跟踪并查看哪些类型的查询正在访问数据库，并从那里直觉可以删除哪些列。

跟踪分析通常用于查找缺失索引的候选对象，但我猜它也可以用于分析使用趋势。

于 2009-10-09T19:51:23.423 回答