我有一个管理记录级权限的视图。为此，我们将其称为“AuthorityView”。它的工作原理是查看基础表，实际的“数据”，“记录权限”表和“用户组”表。
对于此示例，我们选择“员工”记录。有一个核心表“EmployeeData”，它包含所有数据，一个“EmployeeRecordAuthority”，它指定哪些用户组具有对数据的访问权限（读取，读取/写入，更新，删除等）和“用户组”。只是存储用户所属的组。
视图使用相当简单的连接，但处理大量记录（~100k员工记录和~3m记录权限记录）。最终结果是用户可以查看的记录子集。
我遇到的问题是没有条件查询视图的速度非常慢。从“EmployeeAuthorityView”中选择“select *”需要大约6-7分钟，但是，对它应用“top”会使其按预期执行。 “从EmployeeAuthorityView中选择前10000000 *只需几秒钟。
表之间存在所有相关索引，并且已经重建。
什么可能导致查询速度减慢？为什么查询指定的“最高”限制更快，即使数量远远大于表中的记录数量？
提前致谢。
答案 0 :(得分：0)
性能上的差异可能是因为数据库查询优化器使用不同的策略来检索数据。
确切的原因取决于您使用的是哪个DBMS，以及如何编写查询优化器，但问题来自“没有条件的视图”的概念，并且类似于以下内容。
您的EmployeeAuthorityView看起来像是Data，RecordAuthority和UserGroups表的连接。因此，没有任何过滤标准的视图本身定义了一个理论集，它是这些表的产品（外部联接）。该理论集包含100,000 x 3,000,000 x U条记录（U是您的UserGroups表的大小）。一旦你应用了一些选择标准，理论集的大小就会大幅减少，但没有标准就是数万亿条记录（假设你的UserGroups表有超过3行）。
DBMS需要实例化这个理论集的记录数，才能给你一个缓冲区满？查询优化器考虑多种策略，包括（策略A）在将第一个缓冲区全部返回到您的应用程序之前创建所有300亿条记录，（策略B）只需根据需要创建记录，并在应用程序中尽快将缓冲区返回给您的应用程序有这么多。影响该选择的因素包括“以何种顺序将记录返回到您的应用程序”。使用“top”限制会导致顺序定义不同，在这种情况下，它会选择类似策略B的内容。