执行探查器跟踪时，查询持续时间究竟测量什么？
我有一个执行数据访问 (SELECT) 的存储过程，平均需要大约 30 秒才能将结果返回给应用程序。但是当我对其运行跟踪时，平均持续时间约为 8 秒，最大持续时间为 12 秒，平均 CPU 为 5.5 秒。
是什么导致返回结果集需要更长的时间？我没有积累大量的 NETWORKIO 等待。结果集只有大约 270 行简单的文本数据，总共大约 50 列。
我有一个大约有 40-50 个表的数据库。除了 5 个之外，所有其他人都是 1:M 关系的巨大层次结构的一部分，这些关系都指向一个单独的父级（称为“项目”）。每个表都使用父主键的外键连接到它的直接父表，主键是一个标识字段。一些分支深达 6 或 7 层。许多表有数百万行。几乎所有查询都需要返回与单个项目有关的特定表的所有记录。查询通常只返回有问题的单个实体的字段。因此，一个典型的查询（实际上除了随机临时查询之外的所有查询）看起来像这样：
SELECT a.* FROM a
JOIN b ON a.id=b.id
JOIN c ON b.id=c.id
JOIN d ON c.id=d.id
JOIN Project p ON d.ProjectID=p.ProjectID
WHERE p.ProjectID = 12345
可以想象，在层次结构中越往下走，查询的性能就越差。我考虑过仅通过在层次结构的所有级别中冗余地保留 ProjectID 字段，并在每个表中的 ProjectID 上创建聚集索引来对一个字段进行非规范化。这将使我能够通过单个索引查找满足所有数据请求。这样做可以显着提高查询性能。但是，我不知道这样做是否会对架构设计的保真度产生负面影响。我希望有人可以为我提供一些见解，以防我遗漏了什么。