主页 / dba / 问题 / 299904
Accepted
grochu
Asked: 2021-09-22 01:34:33 +0800 CST

是否值得将 NONCLUSTERD FILTERED INDEX 与子句 `<>''` 一起使用？

  • 772

我只是想创造NONCLUSTERED FILTERED INDEX条件：

WHERE varcharColumn <> ''

此列包含大约 3127 个不同的值，包括 value ''。在此表上运行的所有查询都有条件：

WHERE varcharColumn <> ''

90% 的行包含空字符串，并且会被此过滤器排除。

您认为是否值得与上述子句共同创建这样的索引？或者也许更好地创建NONCLUSTERED FILTERED INDEXwith 子句：

WHERE varcharColumn = ''
nonclustered-index filtered-index

2 个回答

  1. Best Answer

    如果您的查询主要包含WHERE varcharColumn <> ''条件，那么这就是您需要用于索引的条件 - 过滤索引只包含对与条件匹配的行的引用，因此=在索引定义中使用意味着只能''找到与它匹配的行不能帮助您的查询。

    如果varcharColumn <> ''仅占表的 10% 左右，则索引将非常小且快速且非常有用。如果比率反转，那么索引可能不会有太大帮助，它只会占用（更多）空间。

    • 4

  2. 或者用子句创建 NONCLUSTERED FILTERED INDEX 可能更好： WHERE varcharColumn = ''

    这只会排除 10% 的数据，此时您几乎可以肯定使用未过滤的索引会更好，该索引也可用于查询其他值。

    90% 的行包含空字符串，

    在 90% 的情况下，即使对于varcharColumn = ''作为谓词的查询，过滤索引也没有多大用处，因为无论如何您都将扫描几乎整个索引（除非其他一些索引更好地为查询服务，在这种情况下，该索引不相关）。

    有条件：WHERE varcharColumn <> ''

    请注意，在大多数情况下，与完整索引相比，这不会显着提高阅读速度¹。如果表包含大量行，它可以节省大量空间²，这可以降低存储成本和索引维护时间，并且可以稍微提高该值为空字符串的行的插入/更新性能。

    [1] 它会在任何操作中减少一两次页面读取，并且这些读取可能来自 RAM，因此几乎是即时的

    [2] 表中每行大约 90% 的 4 字节假设 MS SQL Server 和集群键³ 是整数，如果集群键是 UUID，每行 16 字节，每行 8 字节，RID 值的大小如果表是一个头（没有集群键）

    [3] 通常但不总是主键

    • 1

相关问题