必须使用COUNT_BIG()而非COUNT()，因索引视图要求聚合结果精确映射物理行且防溢出；COUNT()返回int易在亿级数据下溢出，而COUNT_BIG()返回bigint确保一致性，否则建索引时直接报错。
COUNT(*) 不能用，必须写成 COUNT_BIG(*)
SQL Server 索引视图要求所有聚合结果能被唯一、精确地映射到物理存储行，而 COUNT(*) 返回的是 int 类型（最大值 2,147,483,647），在亿级数据聚合时极易溢出。一旦溢出，索引视图就无法保证一致性，所以强制要求改用 COUNT_BIG(*)——它返回 bigint，上限约 9 × 10¹⁸，足够覆盖任何实际场景。
这不是“建议”，而是硬性校验：建索引时若视图里出现 COUNT(*)，哪怕其他条件全满足，也会报错 Cannot create index on view 'v_xxx' because it contains COUNT(*)。
为什么 AVG、SUM 等函数可以，但 ISNULL 不一定行？
索引视图只允许确定性函数——即相同输入永远返回相同输出，且不依赖会话状态或运行时环境。 SUM、AVG、MIN、MAX 都是确定性的；但 ISNULL(col, 0) 是否确定，取决于 col 本身是否允许 NULL 且类型是否支持隐式转换。
- 如果
col是INT NOT NULL，那ISNULL(col, 0)实际不会触发替换逻辑，SQL Server 可能判定为冗余表达式，但仍建议避免 - 如果
col是VARCHAR且含 Unicode 数据，ISNULL在不同排序规则下可能表现不一致，导致索引视图创建失败 - 更安全的写法是直接用
COALESCE(col, 0)（同样需确保确定性）或提前在基表层处理 NULL
GROUP BY 列必须有唯一约束，否则索引建不起来
索引视图的唯一聚集索引键（比如 region）必须能唯一标识每一行结果。如果 region 列在基表 dbo.orders 上没有唯一索引或主键约束，SQL Server 就无法保证视图中每个 region 值对应唯一物理存储位置——这违反了聚集索引“键唯一 + 无 NULL”的前提。
常见错误现象：Cannot create index on view 'vw_SalesByRegion' because the key column 'region' is not unique in the view。
- 解决办法不是给视图加
DISTINCT，而是确保基表上region列有UNIQUE NONCLUSTERED或作为主键一部分 - 如果业务上
region本就不唯一（比如多城市同名），就得把 GROUP BY 扩展为GROUP BY region, country，并确保这两个列组合有唯一约束 - 千万别用
ISNULL(region, 'UNKNOWN')当作索引键——计算列不能做唯一聚集索引键，除非显式定义为 PERSISTED 且确定性达标
建完索引视图，查询却没走它，怎么回事？
成功执行 CREATE UNIQUE CLUSTERED INDEX 只代表物化完成，不代表查询自动命中。优化器是否选择该索引视图，取决于当前会话的 SET 选项是否匹配，以及查询是否“结构等价”于视图定义。
- 最常漏掉的是
SET ARITHABORT ON：SSMS 默认关闭，直接 F5 运行查询时，即使视图已建好，优化器也无视它 - 查询里写了
SELECT * FROM dbo.vw_SalesByRegion WHERE region = 'North'能用索引；但若写成SELECT region, total_sales FROM dbo.vw_SalesByRegion WHERE region = 'North'，只要列名和视图定义完全一致，仍可用；一旦别名或顺序不同，就可能失效 - 如果基础表
orders的统计信息过期，优化器估算错误，也可能放弃使用索引视图——这时要手动更新统计：UPDATE STATISTICS dbo.orders
真正麻烦的不是建不建得起来，而是建完之后你得验证它真被用了。打开 SET STATISTICS XML ON，看执行计划里有没有 Index Seek (Clustered) 指向你的视图名，而不是一堆扫描和哈希聚合。
