为什么MySQL视图在EXPLAIN中显示为DERIVED以及如何调整ALGORITHM为MERGE

在MySQL的查询优化场景中，视图的执行计划表现直接影响查询效率，当使用EXPLAIN分析包含视图的查询时，经常会看到DERIVED标识，这背后和视图的算法设置密切相关。

一、EXPLAIN中DERIVED的含义

DERIVED是MySQL执行计划中的一种类型，代表该查询部分是派生表，也就是视图的定义会被先执行，结果存入临时表，外层查询再基于这个临时表做后续操作。这种处理方式会带来额外的临时表创建、数据写入和读取开销，当视图关联的数据量较大时，性能损耗会比较明显。

出现DERIVED的核心原因是视图的算法被设置为TEMPTABLE，或者视图的定义不满足MERGE算法的适用条件，MySQL只能选择TEMPTABLE算法来处理视图。

二、视图的两种算法：MERGE和TEMPTABLE

1. MERGE算法

MERGE算法会将视图的SELECT定义直接合并到外层查询的SQL中，相当于把视图的定义展开，和外层查询的逻辑整合为一个完整的查询语句，再统一生成执行计划，整个过程不会创建临时表，性能通常更好。

2. TEMPTABLE算法

TEMPTABLE算法会先将视图的查询结果存入临时表，外层查询再操作这个临时表，这就是EXPLAIN中出现DERIVED的原因。临时表默认是内存临时表，当数据量超过tmp_table_size设置时，会转为磁盘临时表，性能进一步下降。

三、如何调整视图ALGORITHM为MERGE

1. 创建视图时指定MERGE算法

创建视图时可以通过ALGORITHM参数显式指定使用MERGE算法，语法如下：

-- 创建使用MERGE算法的视图
CREATE ALGORITHM=MERGE VIEW user_order_view
AS
SELECT u.id, u.name, o.order_id, o.order_amount
FROM user u
JOIN order_info o ON u.id = o.user_id
WHERE u.status = 1;

2. 修改已有视图的算法为MERGE

如果视图已经创建，可以通过ALTER VIEW语句修改算法，注意修改时需要带上完整的视图定义：

-- 修改已有视图的算法为MERGE
ALTER ALGORITHM=MERGE VIEW user_order_view
AS
SELECT u.id, u.name, o.order_id, o.order_amount
FROM user u
JOIN order_info o ON u.id = o.user_id
WHERE u.status = 1;

3. 验证算法是否生效

修改完成后，可以通过EXPLAIN查看包含该视图的查询执行计划，如果不再出现DERIVED标识，说明MERGE算法已经生效：

-- 查看执行计划验证算法
EXPLAIN SELECT * FROM user_order_view WHERE order_amount > 100;

四、MERGE算法的适用限制

并不是所有视图都可以使用MERGE算法，以下场景的视图无法使用MERGE，会被自动转为TEMPTABLE算法：

• 视图定义中包含聚合函数，比如SUM、COUNT、MAX等
• 视图定义中包含DISTINCT、GROUP BY、HAVING子句
• 视图定义中包含UNION或者UNION ALL
• 视图定义中包含子查询
• 视图定义中引用了系统变量或者用户变量

五、注意事项

首先，显式指定ALGORITHM=MERGE时，如果视图定义不满足MERGE的条件，MySQL会直接报错，不会自动转为TEMPTABLE，这时候需要检查视图定义是否符合要求。

其次，MERGE算法合并后的查询可能会比原视图单独执行的逻辑更复杂，优化器需要重新评估整个合并后的查询，极端情况下如果合并后的查询优化器无法生成高效执行计划，性能可能反而不如TEMPTABLE，这种情况需要结合实际执行计划判断。

最后，修改视图算法后，建议通过实际数据测试查询性能，不要仅依赖执行计划的DERIVED标识判断，实际性能表现才是最终的衡量标准。

MySQL视图EXPLAIN执行计划DERIVEDMERGE算法查询优化修改时间：2026-07-20 09:21:23