如何快速将旧的SQL查询语句转换为高性能视图？-SQL-PHP中文网

视图本身不提升性能，真正起作用的是底层查询优化、索引和执行计划；它仅是select语句的封装，每次查询仍展开执行原sql。

如何快速将旧的sql查询语句转换为高性能视图？

不能直接“转换”就变快——视图本身不提速，真正起作用的是底层查询是否可优化、索引是否到位、执行计划是否合理。

很多人以为把慢 SQL 包进 CREATE VIEW 就自动变快了，结果上线后发现查询更慢。这不是视图的锅，是没看清它只是个“语法糖封装”，背后还是那条原始 SQL 在跑。

为什么直接 CREATE VIEW 不等于性能提升

视图本质是保存一条 SELECT 语句，每次查询它时，数据库都会展开（view merge）并重生成执行计划。如果原 SQL 有这些毛病，包成视图后照样卡：

SELECT * 拉回几十列，但业务只用其中 2–3 个
多表 JOIN 缺少对应字段的索引，比如 ON orders.customer_id = customers.id，但 customers.id 没主键或没索引
WHERE 条件写在视图外（如 SELECT * FROM v1 WHERE status = 'done'），但视图定义里没下推谓词，导致全量计算后再过滤
用了 GETDATE()、ROW_NUMBER()、UNION ALL 等阻止查询转换的操作，让优化器无法合并或下推

真正有效的转换步骤：从 SQL 到 v2 视图

不是复制粘贴，而是重构。以 SQL Server 为例，重点做三件事：

lucene索引优化中文WORD版

本文档主要讲述的是lucene索引优化；这篇文章主要介绍了如何提高Lucene的索引速度。介绍的大部分思路都是很容易尝试的，当然另外一部分可能会加大你程序的复杂度。所以请确认索引速度确实很慢，而且很慢的原因确实是因为Lucene自身而造成的；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看

下载

先用 SET STATISTICS IO ON 和 SET STATISTICS TIME ON 跑原 SQL，记下逻辑读、CPU 时间、执行计划里的红色警告（比如 “Table Scan” 或 “Key Lookup”）
删掉所有 SELECT *，只留业务真正需要的字段；大字段如 TEXT、VARCHAR(MAX)、XML 必须显式排除
检查每个 JOIN 字段是否都有索引：对 INNER JOIN 的两边字段，至少一边要有索引；若经常按 status + created_at 查询，考虑建复合索引 (status, created_at)
把高频过滤条件尽量“沉入”视图定义中（例如业务 90% 查询都加 WHERE is_deleted = 0），而不是留给调用方

示例对比：

-- 原始低效视图（v1）
CREATE VIEW v1 AS
SELECT * FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN products p ON o.product_id = p.id;

-- 重构后（v2），字段精简 + 过滤下推 + 索引提示（如有必要）
CREATE VIEW v2 AS
SELECT 
  o.order_id,
  o.order_date,
  c.name AS customer_name,
  p.sku
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id
INNER JOIN products p ON o.product_id = p.id
WHERE o.is_deleted = 0;

哪些情况该放弃视图，改用其他方案

视图不是万能解药。遇到以下场景，硬套视图反而更糟：

查询里带参数（如 @start_date），SQL Server 视图不支持参数，只能改用内联表值函数 ITVF 或存储过程
要频繁聚合（GROUP BY + SUM）且数据量大，考虑用索引视图（CREATE UNIQUE CLUSTERED INDEX on view），但要求严格：必须有唯一聚集索引、基表不能有 NULL 列等
跨库或跨服务器查询，视图无法跨实例走分布式查询优化，不如用 OPENQUERY 或应用层组装
实时性要求极高（毫秒级），而视图依赖的表更新频繁，此时物化视图（如 PostgreSQL 的 MATERIALIZED VIEW）或缓存层更合适