create view 不支持运行时参数（如 @book_id），仅允许确定性子查询；需用内联表值函数替代参数化需求，或通过外部查询过滤视图结果。
CREATE VIEW 里不能直接用子查询参数（比如 @book_id）
SQL Server 和大多数主流数据库不支持在 CREATE VIEW 语句中引用变量或存储过程参数。你看到的“动态视图”例子中出现的 @book_id，实际是误把存储过程内部逻辑当成了视图定义——视图本身是静态对象，无法接收运行时参数。
常见错误现象：Must declare the scalar variable "@book_id" 或语法报错提示变量未定义。
- 视图定义必须是确定性 SQL：所有表名、列、WHERE 条件、JOIN 关系都得写死
- 所谓“动态”，只能靠外部查询去过滤视图结果，比如
SELECT * FROM v_result WHERE bookID = @book_id - 如果真需要参数化行为，应改用内联表值函数（
ITVF），不是视图
子查询可以嵌套进 CREATE VIEW，但有硬性限制
视图的 AS SELECT ... 部分允许包含子查询，包括相关子查询、标量子查询、FROM 中的派生表等，但必须满足可执行性和确定性要求。
典型可用结构：
- FROM 子句中的子查询（即派生表）：
SELECT u.name, o.cnt FROM users u JOIN (SELECT userID, COUNT(*) cnt FROM orders GROUP BY userID) o ON u.id = o.userID - SELECT 列表里的标量子查询：
(SELECT COUNT(*) FROM orderBook b WHERE b.userID = u.id) AS order_count - WHERE 中的 IN/EXISTS 子查询（只要不依赖外部变量）
容易踩的坑：
- 子查询里用了
ORDER BY却没配TOP或OFFSET/FETCH→ 直接报错（SQL Server 不允许） - 子查询返回多行单列，但被当标量用（如放在 SELECT 列表里没加聚合或限制）→ 运行时报错
Subquery returned more than 1 value - 嵌套过深导致查询计划难以优化，视图调用时性能骤降
想实现“按书ID查关联用户再查其购书TOP3”，别硬塞进一个视图
这类带参数 + 排序 + 分组限制的链式逻辑，强行压进 CREATE VIEW 会导致两个问题：不可复用、不可维护、且大概率失败。
推荐拆解路径：
- 第一步：建基础视图封装连接与聚合，例如
CREATE VIEW v_user_book_counts AS SELECT userID, bookID, COUNT(*) AS buy_times FROM orderBook JOIN orderInfo ON ... GROUP BY userID, bookID - 第二步：用外部查询加参数和排序，例如
SELECT TOP 3 bookID FROM v_user_book_counts WHERE userID IN (SELECT DISTINCT userID FROM v_user_book_counts WHERE bookID = @book_id) ORDER BY buy_times DESC - 或者一步到位用 CTE：
WITH target_users AS (SELECT DISTINCT userID FROM v_user_book_counts WHERE bookID = @book_id) SELECT TOP 3 bookID, COUNT(*) FROM orderBook WHERE userID IN (SELECT userID FROM target_users) GROUP BY bookID ORDER BY COUNT(*) DESC
注意：视图里永远不要写 TOP 3 或 ROW_NUMBER() 窗口函数来“固定结果”，那会让视图失去通用性，后续无法灵活加条件或 JOIN。
SQL Server 中带 ORDER BY 的视图必须显式加 TOP 或 OFFSET
如果你坚持要在视图里固化排序（极不推荐），SQL Server 要求必须配合 TOP (100) PERCENT 或 OFFSET 0 ROWS，否则语法拒绝通过。
例如合法但危险的写法：
CREATE VIEW v_sorted AS SELECT TOP (100) PERCENT userID, bookID, buy_times FROM v_user_book_counts ORDER BY buy_times DESC;
为什么危险？
-
TOP (100) PERCENT在 SQL Server 2012+ 中已被标记为“不保证排序稳定性”，优化器可能忽略ORDER BY - 一旦该视图被用于 JOIN 或子查询，排序完全失效
- 真正需要排序的地方，永远是最终
SELECT语句，不是视图定义
最易被忽略的一点：视图不是缓存，也不是中间表；它只是保存了一段 SQL 文本。每次查询视图，都是重跑整个底层 SELECT —— 所以嵌套子查询的开销，会在每次调用时真实发生，而不是“创建时算一次”。
