数据库虚表这玩意儿，怎么帮你SQL跑得更快一点点

得搞清楚“虚表”是个啥，在日常聊数据库的时候，人们说的“虚表”通常不是指一个官方术语，而是对一类不实际存储数据的数据库对象的统称，最常见的就是“视图”，有时候也会包括“派生表”（子查询形成的临时表）和“公共表表达式”，它们就像是一个个预先写好的查询模板或者一个临时的查询结果集，你用它的时候，感觉像是在操作一张真正的表，但实际上它背后是一条或多条SQL语句，数据还是从那些实实在在的“实表”里现场计算出来的。

一个不存数据、每次都要临时计算的东西，是怎么帮我们加快查询速度的呢？它不是反而应该更慢吗？这里面的门道就在于，它通过“简化”和“优化”我们的操作逻辑，间接地让数据库引擎能更聪明、更高效地工作，它不是像索引那样直接给数据访问修了一条高速公路，而是更像一个优秀的导航员，帮你规划出了最短、最不堵车的路线。

虚表能从以下几个方面帮上忙：

第一，把复杂查询变简单，让思路和写法都清晰。

想象一下,你要写一个非常复杂的报表查询，这个查询需要连接七八张表，有各种各样的过滤条件，还有分组汇总，如果你直接把这么长的一大段SQL甩给数据库，且不说你自个儿写起来容易出错，数据库的优化器在解析这么复杂的语句时，也可能因为选择太多而一时半会儿找不到最优的执行计划。

这时候,视图就派上用场了，你可以把其中最复杂、最核心的那部分连接和计算逻辑，封装成一个视图，先创建一个叫“客户订单摘要”的视图，这个视图内部已经做好了客户表、订单表、订单明细表的连接，并且计算好了每个客户的总订单金额、最近下单时间等。

当你真正要做报表时,你的查询语句就不用再面对那七八张表了，而是直接从“客户订单摘要”这个视图里取数据，可能只需要再加一两个简单的过滤条件就行，SQL语句变得极其简洁易懂，维护起来也方便，对数据库优化器来说，它面对的查询结构也更简单明了，有时候反而能更快地制定出高效的执行方案，这就好比你要组装一个复杂模型，如果先把胳膊、腿这些部件分别预装好，最后总装就会快很多。

第二，充当查询重写的“跳板”，触发数据库的优化能力。

这是一种更高级也更常见的加速方式,当你对一个视图进行查询时，现代智能的数据库优化器（比如Oracle、SQL Server、PostgreSQL等主流数据库的都具备这种能力）并不会真的傻乎乎先去把整个视图的结果集完全计算出来形成一个临时表，然后再在这个临时表上执行你的过滤条件。

相反,优化器会做一件叫做“视图合并”的事情，它会把你写的针对视图的SQL语句，和创建视图时定义的SQL语句“合并”起来，形成一个新的、完整的查询语句，优化器会对这个合并后的完整查询进行优化，选择最优的执行路径。

举个例子,你有一个视图V，定义是 SELECT * FROM 大表A, 大表B WHERE A.id = B.a_id，然后你查询 SELECT * FROM V WHERE A.name = '张三'，笨办法是先做A和B的全连接形成一个巨大的虚拟表V，再从这个巨大虚拟表里找名字是张三的记录，但聪明的优化器会把你的查询重写为 SELECT * FROM 大表A, 大表B WHERE A.id = B.a_id AND A.name = '张三'。

这样一来,优化器就有机会利用表A在name字段上的索引了！它可能会先通过索引快速找到所有叫“张三”的A表记录，再用这些记录的id去关联B表，这个执行路径比先做全表连接再过滤要高效成千上万倍，视图在这里，其实是“诱骗”你写出了一个结构良好的查询，然后给优化器提供了一个施展“查询重写”魔法的机会。

第三，实现数据的安全和裁剪，减少不必要的IO。

这种加速效果是显而易见的,你有一张员工表，里面有工资、身份证号等敏感信息，你可以创建一个视图，只包含允许普通员工查询的字段，比如姓名、部门、职位，当应用程序通过这个视图查询时，数据库从一开始就不会去触碰那些敏感的数据列，无形中减少了需要扫描的数据量，尤其是在表非常宽（列很多）的情况下，这种字段裁剪能节省可观的磁盘I/O，I/O减少了，查询速度自然就上去了。

另一种情况是“分区视图”，比如你有一张存储了多年日志的大表，按时间分了区，你可以为最近一个月的数据创建一个视图，当查询这个视图时，优化器可以智能地识别出它只涉及特定的分区，从而避免扫描整张巨大的历史表，这就是所谓的“分区裁剪”，性能提升是数量级的。

第四，作为公共表表达式的妙用，避免重复计算。

公共表表达式（CTE）是另一种形式的虚表，用WITH关键字定义，它特别适合在一个复杂的查询中，某个子查询需要被多次引用的场景。

你要找出销售额高于平均销售额的所有产品,并同时计算这些产品在每个区域的销售占比，传统的写法可能需要写两遍计算平均销售额的子查询，或者写一个重复的派生表，而使用CTE，你可以先写 WITH 平均销售额 AS (SELECT AVG(amount) AS avg_amt FROM sales)，然后在主查询里多次引用“平均销售额”这个CTE。

这样做的好处是,语义清晰，易于阅读和维护，更重要的是，优秀的数据库优化器通常能够识别这种模式，它知道“平均销售额”这个CTE只需要被计算一次，然后将结果缓存起来供后续步骤重复使用，避免了重复扫描sales表进行聚合计算，提升了效率。

需要注意的地方

虚表也不是万能药,如果你创建的是一个极其复杂的、嵌套多层的视图，然后又在上面进行复杂的查询，有时候可能会“弄巧成拙”，增加了优化器制定执行计划的难度和成本，反而可能影响性能，关键还是要理解其背后的原理，合理地使用它来简化逻辑、配合优化器工作，而不是盲目地堆砌。

数据库虚表这个玩意儿,它自己虽然不存数据，但它通过扮演“查询封装器”、“优化触发器”、“数据安全过滤器”和“可重用计算单元”这些角色，帮助我们写出更清晰、更优化的查询语句，从而引导数据库引擎选择更高效的执行路径，最终实现让SQL“跑得更快一点点”的目标，它的快，是一种间接的、智能的快。