在提取相关的ID之后,我在单独的查询中多次使用得到的Ids集合来提取我想要的实际输出记录集(通过连接到其他表,使用聚合函数等).
解决方法
如果缓存ID集的所有使用都包含整个集合到其他表的连接,那么解决方案绝对不应该涉及在数据库之外缓存ID集.如果你可以避免,数据不应该再往返于那里.
在某些情况下(当不涉及游标或极其复杂的sql时)最好(即使是违反直觉的)不执行缓存并简单地将重复sql连接到所有期望的查询.毕竟,每个查询都需要根据其中一个连接表进行遍历,然后性能在很大程度上取决于加入和快速评估所有剩余信息所需的索引的可用性.
在数据库中“缓存”ID集的最直观方法是临时表(如果命名为#something,它对于连接是私有的,因此可以由并行独立客户端使用;或者它可以被命名为## something并且是全局的).如果表将有许多记录,则索引是必需的.为了获得最佳性能,索引应该是聚簇索引(每个表只允许一个),或者仅在构造该集合后创建,其中索引创建稍快.
索引视图比临时表更可取,除非在整个过程中只读取基础数据,或者您可以并且希望忽略此类更新以使整个报告集尽可能保持一致.但是,索引视图始终准确地投影基础数据的能力是以降低这些更新为代价的.
这个问题的另一个答案提到了存储过程.这主要是组织代码的一种方式.但是,如果你这样做,最好避免使用临时表,因为对临时表的这种引用会阻止预编译存储过程;如果可以,请查看视图或索引视图.
无论您选择何种方法,都不要猜测性能特征和查询优化器行为.学习显示查询执行计划(在sql Server Management Studio中),并确保您看到索引访问,而不是嵌套循环组合多个大型数据集;只添加可明显且彻底改变查询性能的索引.精心挑选的索引通常可以将查询的性能改变1000倍,因此学习起来有点复杂,但对成功至关重要.
最后但并非最不重要的是,确保在重新填充数据库时(以及每晚生产中)使用UPDATE STATISTICS,否则您的查询优化器将无法将您创建的索引用于最佳用途.
