SQL Server视图嵌套聚合或JOIN多表易超时，主因是实时计算、笛卡尔积、索引未生效；应加WHERE过滤、建索引视图、检查执行计划、避免ORDER BY及表达式列。
视图里嵌套聚合，执行就超时
SQL Server 视图本身不存储数据，但一旦定义中含 GROUP BY、AVG、COUNT(*) 等聚合函数，每次查询都会实时计算。如果底层表数据量大（比如千万级订单），又没加过滤条件，SELECT * FROM v_sales_summary 实际等价于全表扫+分组+排序，很容易突破默认 30 秒 Command Timeout。
实操建议：
- 在应用层调用视图时，必须带
WHERE过滤条件，且该字段最好有索引（例如WHERE report_date >= '2026-01-01'） - 避免在视图定义里写
SELECT *，只选真正需要的列；聚合视图尤其要剔除无用的TEXT或XML字段 - 若业务允许，把聚合结果物化：用
CREATE VIEW ... WITH SCHEMABINDING+ 建唯一聚集索引，转成“索引视图”，让 SQL Server 把结果缓存下来
视图 JOIN 多张表后查询变慢甚至卡死
这是典型的笛卡尔积风险。比如视图定义里写了 FROM orders o JOIN customers c ON 1=1（漏写关联条件），或者两张表都只有几十万行，但连接键无索引，优化器被迫走嵌套循环，中间结果集爆炸式增长——10 万 × 10 万 = 100 亿行，内存撑爆、TempDB 写满、最终触发超时。
实操建议：
- 用
SET STATISTICS XML ON跑一次视图查询，看执行计划里有没有“Cartesian Product”字样或异常大的“Estimated Number of Rows” - 检查所有
JOIN条件是否完整，特别注意外连接（LEFT JOIN）右侧表是否有可下推的WHERE条件（如写成LEFT JOIN logs l ON l.order_id = o.id WHERE l.status IS NOT NULL，实际变成了内连接，但语法上容易误判） - 给每个
JOIN字段单独建索引，不要依赖复合索引覆盖全部连接路径；orders.customer_id和customers.id都要有索引
修改连接字符串里的 Command Timeout 不解决问题
单纯把 Command Timeout=300 改成 600，只是让失败延迟发生，并不能让查询变快。更危险的是：它掩盖了真实瓶颈——可能是锁住的事务正在阻塞视图底层表，也可能是统计信息过期导致优化器选错执行计划，而你还在等那 10 分钟。
实操建议：
- 先查阻塞链：
SELECT session_id, blocking_session_id, command, wait_type FROM sys.dm_exec_requests WHERE blocking_session_id 0 - 再看统计信息是否陈旧：
DBCC SHOW_STATISTICS('orders', 'IX_orders_customer_id')中的Rows Sampled是否远小于Rows - 临时绕过视图，把视图定义里的 SQL 拆出来单独跑，确认是视图本身问题，还是调用上下文（如参数嗅探）导致的计划劣化
为什么加了索引，视图查询还是超时
因为 SQL Server 对视图的索引使用很保守。即使你在底层表建了完美索引，只要视图定义里包含 TOP、OFFSET/FETCH、窗口函数（ROW_NUMBER()）、或表达式列（ISNULL(name, '')），优化器大概率放弃索引查找，退回到扫描。
实操建议：
- 用
WITH (NOEXPAND)提示强制走索引视图（仅限带SCHEMABINDING的视图）：SELECT * FROM v_summary WITH (NOEXPAND) WHERE ... - 避免在视图里写
ORDER BY（除非配合TOP），这会阻止并行计划生成 - 对含表达式的列，建计算列并索引它：
ALTER TABLE orders ADD customer_name_clean AS LTRIM(RTRIM(ISNULL(customer_name, ''))) PERSISTED，再在该列建索引
视图不是黑盒，它的性能完全取决于底层表结构、数据分布和查询上下文。最容易被忽略的，是把视图当普通表用——忘了它每次展开都是重算，也忘了连接条件漏写一个等号就能让查询从秒级变成超时。
