SQL Server 2014共享视图性能问题：小查询为何因同视图大查询变慢？

这事儿核心是三个关键原因：

• 执行计划复用踩坑：视图本质就是个存储好的SELECT语句，当大查询先执行时，SQL Server会生成适配大数据量的重型执行计划——比如用哈希连接、全表并行扫描这类操作。等小查询过来时，SQL Server会直接复用这个现成计划，但这个计划完全不适合小数据量场景！比如小查询明明可以走索引seek快速定位，结果被迫跟着大计划走全表扫描，速度自然暴跌。而且SQL Server 2014的计划缓存机制还没后续版本（比如2016+的自适应查询计划）智能，没法自动调整适配小查询。
• 核心资源被抢占：大查询跑起来会占满IO、CPU、缓冲池这些核心资源，小查询再执行时，就得等着大查询释放资源才能推进。再加上视图的SQL会直接展开到外层查询里，等于小查询和大查询的逻辑揉成了一个大计划，资源竞争只会更激烈。
• 锁阻塞拖慢节奏：如果大查询持有共享锁的时间很长（比如扫描超大表），小查询要访问相同数据时，就得等着锁释放，这一等就耗掉大把时间。

TVF刚好精准命中了视图的痛点，针对性解决问题：

• 执行计划独立生成：不管是多语句TVF还是内联TVF，每次调用都会根据当前查询的上下文生成专属执行计划，不会复用大查询的重型计划。小查询调用TVF时，优化器会生成适配小数据量的轻量计划——比如嵌套循环、索引seek，直接走最优路径。
• 资源竞争大幅降低：TVF的执行逻辑相对独立，大查询和小查询的计划分开运行，不会互相争抢资源到白热化。哪怕是内联TVF会被展开，优化器也会先适配外层小查询的需求来优化，不会像视图那样被大查询的计划带偏。
• 避免逻辑合并的坑：视图会直接把自身SQL展开到外层查询里，和外层逻辑合并成一个大查询，优化器很容易做出不利于小查询的选择。而TVF是封装好的逻辑，优化器会先处理TVF内部，再结合外层查询调整，灵活性高得多。

从你提到的执行计划场景来看，大概率是大查询的计划用了全表扫描/并行执行，小查询复用后被迫走了低效路径，而TVF让小查询的计划回归了最优解，所以速度始终更快。

内容的提问来源于stack exchange，提问作者sojim