视图JOIN后WHERE条件未走索引，主因是谓词未下推至基表扫描；常见于视图含GROUP BY/DISTINCT/UNION/标量函数致ALGORITHM=TEMPTABLE，或JOIN字段无索引、字段顺序错、NULL值过多等。
视图 JOIN 后 WHERE 条件没走索引？先看执行计划里有没有谓词下推
视图本身不存数据，JOIN 效率低的根因，几乎都出在“外层过滤没下推到基表扫描”——比如 SELECT * FROM user_order_view uov JOIN products p ON uov.product_id = p.id WHERE uov.created_at > '2024-01-01'，如果 EXPLAIN 显示 created_at > '2024-01-01' 出现在最外层的 Filter 操作符里，而不是落在 user_order_view 对应基表（如 orders）的扫描节点上，就说明下推失败了。
常见触发条件包括：
- 视图定义含
GROUP BY、DISTINCT、UNION或标量函数（如UPPER(name)），MySQL 会自动降级为TEMPTABLE算法，强制物化整个视图结果再过滤 - 视图用了
SELECT *，而外层查询只取其中几列，但优化器无法确认哪些字段可被提前裁剪 - JOIN 的另一张表（如
products）没有product_id索引，导致优化器放弃对整个链路做下推优化
MySQL 视图 JOIN 性能崩了？检查 ALGORITHM 是 MERGE 还是 TEMPTABLE
SHOW CREATE VIEW user_order_view 是必查动作。如果返回里明确写着 ALGORITHM = TEMPTABLE，那所有后续 JOIN 都是在一个无索引的临时结果集上做的，性能必然断崖下跌。
解决路径很直接：
- 重构视图逻辑：把聚合、去重等操作拆出去，视图只保留基础
JOIN和字段投影，确保ALGORITHM = MERGE（MySQL 默认） - 用子查询替代：比如原视图含
GROUP BY user_id，外层又只查单个user_id，直接写成(SELECT ... FROM orders WHERE user_id = ? GROUP BY user_id)，让优化器有机会提前剪枝 - 禁用
TEMPTABLE强制行为：在视图创建时显式指定ALGORITHM = MERGE，但前提是视图不含任何禁止 MERGE 的语法（如窗口函数、LATERAL）
JOIN 顺序错乱导致中间结果爆炸？别信“小表放左边”的经验
视图参与 JOIN 时，优化器容易误判驱动表——尤其当视图背后是多表关联+聚合的结果，统计信息不准，rows 预估可能偏差百倍。这时 EXPLAIN ANALYZE 里看到某张表的 Actual Rows 比 EstimatedRows 高几十倍，基本就是顺序错了。
实操中更可靠的做法是：
- 把带强过滤条件的表（如
WHERE status = 'paid' AND created_at > '2024-01-01'）放在FROM后第一个位置，哪怕它物理上是大表 - 对视图外层加
STRAIGHT_JOIN（MySQL），但只用于验证：先用EXPLAIN确认小结果集表是哪张，再强制它当驱动表 - 避免在视图的
ON条件里写函数或表达式，比如ON DATE(o.created_at) = CURDATE()，这会让优化器彻底放弃估算，转而选最“安全”的顺序（通常是全表扫）
为什么加了索引还是慢？覆盖字段顺序和 NULL 值才是关键
视图 JOIN 查询慢，90% 的索引问题不在“有没有”，而在“字段顺序对不对”和“NULL 多不多”。例如视图常被 WHERE status = 'active' AND tenant_id = 123 过滤，而你建的是 (tenant_id, status) 索引，那 status = 'active' 就无法走索引前导列。
还有几个易忽略点：
- JOIN 字段允许
NULL，且实际占比超过 5%，优化器大概率跳过该索引——改用默认值（如tenant_id = 0）比留空更利于索引选择 - 视图 SELECT 列里有
amount * tax_rate这类计算字段，基表即使有amount索引也白搭；要么冗余存储计算结果并建索引，要么把计算移到应用层 - PostgreSQL 中视图用了
LATERAL，即使基表有索引，也可能阻止下推；得用EXPLAIN (ANALYZE, BUFFERS)看真实 I/O，不能只信预估
