这个执行计划是重新思考我的主键的动机吗

Question

当我进入当前（雇主）公司时，设计了一个新的数据库模式，该模式将成为许多未来正在/将要创建的工具的基础。 以我有限的 SQL 知识，我认为该表设计得相当好。 我唯一担心的是几乎每个表都有一个多部分主键。 每个表至少有一个它自己的 CustomerId 和键。 虽然这些确实是针对某个记录的定义，但我感觉多个键（我们这里讨论的是四键）效率非常低。

今天，我在一个简单的重复查询中看到了一些难以想象的 CPU 使用率，该查询连接两个表，从第一个表中选择一个字符串字段并区分它们。

select distinct(f.FIELDNAME) as fieldName
from foo f
inner join bar b
   on f.id = b.fId
where b.cId = @id;

检查执行计划（我不是EP英雄）我注意到有三个主要的CPU点。 不同的（如预期的）和两个对不相关的寻求。 我个人认为索引搜索应该非常快，但它们各自占用了 18% 的成本。 这是正常的吗？ 是由于（四重）聚集索引吗？

--更新--
该查询用于创建 Lucene 索引。 这是大约每周进行一次的一次性处理（我知道，这听起来很矛盾）。 据我所知，我无法在这里重复使用任何结果。

Answer 1

这种查询看起来很熟悉。 我在这里猜测，但是，它可能正在填充 web/winform ui 上的组合框，而该组合框受到了很大的打击。

也许您应该在应用程序端缓存结果，这样您就不会经常执行它。 最糟糕的情况是，您可以将其缓存在 sql 服务器端，但这是一个巨大的混乱。

Answer 2

您能否运行以下查询并发布其输出：

SELECT  COUNT(*), COUNT(DISTINCT fieldname)
FROM    foo

SELECT  COUNT(*), COUNT(DISTINCT cId), COUNT(DISTINCT fId)
FROM    bar

这将有助于估计哪些索引最适合您的需求。

同时确保您有以下索引：

foo (FIELDNAME)
bar (cId, fId)

并重写您的查询：

SELECT  DISTINCT(fieldname)
FROM    foo f
WHERE   EXISTS (
        SELECT  1
        FROM    bar b
        WHERE   b.fId = f.id
                AND b.cId = @id
        )

此查询应使用 f.FIELDNAME 上的索引来构建 DISTINCT 列表和 上的索引bar 过滤掉不存在的值。

Answer 3

在大多数数据库中，如果未列出索引中的第一列，则不会使用索引。 您说 customerId 是每个主键的一部分，但您不将其用于查询中的联接。 为了正确回答您的问题，我们确实需要查看 foo 和 bar 的创建表输出，或者至少显示索引。

也就是说，如果您像这样更改它，您的查询可能会更快：

select distinct(f.FIELDNAME) as fieldName
from foo f
inner join bar b
   on f.id = b.fId
   and f.cId = b.cId #Using this part of the key will speed it up
where b.cId = @id;

我的评论假设您的主键按“cId，fId”排序有效，这意味着您的查询不必检查每个 cId，而只需检查那些这是索引的一部分。