视图上COUNT(*)会触发全底层扫描，因其无物化存储，必须展开定义并执行完整查询逻辑，无法下推条件或复用索引，导致等效全表/全JOIN扫描。
视图背后没有物化，COUNT(*) 会触发全底层扫描
视图本身不存储数据，只是保存 SELECT 语句的定义。当你对视图执行 COUNT(*)，数据库必须先“展开”视图定义，再执行完整查询逻辑——如果视图基于多表 JOIN、子查询或复杂 WHERE 条件，COUNT(*) 就等价于在展开后的结果集上做全量扫描，而这个结果集可能根本没索引可走。
常见错误现象：EXPLAIN 显示 type=ALL 或 rows 接近千万级，哪怕视图只 select 了三列；执行计划里出现 Using temporary 或嵌套 DERIVED 表。
- MySQL 中，即使视图定义用了索引字段，只要 COUNT 作用在视图上，优化器通常无法下推过滤或复用索引统计
- PostgreSQL 的
pg_views不缓存行数，每次 COUNT 都重跑视图逻辑；SQL Server 的标准视图同样无行数缓存 - 如果你的视图包含
GROUP BY、DISTINCT、窗口函数或聚合子查询，COUNT 甚至要先生成中间结果集再计数，I/O 和内存开销翻倍
WHERE 条件加在视图上 ≠ 加在底层表上
写 SELECT COUNT(*) FROM my_view WHERE status = 'active' 看似合理，但多数数据库（尤其是 MySQL 5.7/8.0）不会自动将该 WHERE 下推到底层表——它先计算整个视图结果，再过滤，最后 COUNT。相当于“先查出全部数据，再筛，再数”，完全失去索引优势。
使用场景：后台管理页展示“待审核订单数”，视图封装了订单+用户+商品关联逻辑，但 COUNT 却卡住。
- 验证方法：把视图定义复制出来，手动拼上
WHERE status = 'active'再EXPLAIN，对比执行计划中key和rows是否明显变小 - MySQL 8.0+ 支持部分下推，但仅限简单视图（无 JOIN、无聚合），且需确保底层字段有对应索引
- SQL Server 可通过
SCHEMABINDING+ 索引视图强制下推，但要求严格：所有列显式声明、不能用GETDATE()等非确定函数、底层表主键必须存在
别指望 COUNT(1) 或 COUNT(pk) 能提速
在视图上换函数毫无意义。因为瓶颈从来不在函数本身，而在“必须执行完整视图逻辑才能拿到一行”。COUNT(*)、COUNT(1)、COUNT(id) 在视图场景下执行计划几乎一致——它们都得先 materialize 出整个结果集。
参数差异：COUNT(id) 还可能额外增加 NULL 检查开销（尤其 id 是可空列时），反而略慢。
- 真正有效的替代是绕过视图：直接查底层主表，用已知索引字段 + 精确 WHERE（如
WHERE order_status IN ('pending', 'reviewing')） - 若业务强依赖视图抽象，考虑在关键过滤字段上建冗余索引（例如视图常按
user_type过滤，就在底层 users 表上建INDEX idx_users_type ON users(user_type)） - 避免在视图定义里写
SELECT *或无条件 JOIN 大表——这会让 COUNT 的扫描基数从“目标子集”膨胀成“笛卡尔积”
什么情况下可以接受视图 COUNT？
只有当视图逻辑极轻、且底层数据量小（COUNT(*) 才可能毫秒级返回。现实中更常见的是：你以为在查一个“逻辑表”，实际在驱动一套 OLAP 流程。
容易被忽略的地方：应用层缓存视图 COUNT 结果时，失效策略必须和底层表的 DML 操作联动。比如订单状态变更后，相关视图计数缓存必须立刻失效——否则你优化了 SQL，却在缓存层引入了更隐蔽的脏数据问题。
