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，再在该列建索引

视图不是黑盒，它的性能完全取决于底层表结构、数据分布和查询上下文。最容易被忽略的，是把视图当普通表用——忘了它每次展开都是重算，也忘了连接条件漏写一个等号就能让查询从秒级变成超时。