这确实是个挺容易让人困惑的MySQL优化器行为问题，我来帮你拆解下背后的原因：

问题场景还原 #

你遇到的情况可以简化为：

• 左表：6行仅含整数ID的表
• 右表：3行包含部分左表ID + 两个INT字段
• 基于右表的视图：返回ID + 由两个INT字段生成的文本字段（仅覆盖左表部分ID）
• 执行左连接查询：SELECT * FROM 左表 LEFT JOIN 视图 ON table_ID = view_ID;
• 异常现象：本该有3行不匹配的视图文本字段返回NULL，但实际所有行的文本字段都有值；修改视图生成文本列的逻辑后，结果恢复符合左连接定义的预期。

背后的核心原因：MySQL的视图合并优化 #

在MySQL 5.6中，优化器默认会对视图执行**视图合并（View Merging）**操作——简单说就是把视图的查询逻辑直接“嵌入”到外层的左连接查询中，而不是先执行视图得到独立的结果集，再和左表做连接。

这个优化本身是为了提升查询效率，但如果视图中的文本字段生成逻辑满足以下情况，就会出现你看到的异常：

• 字段表达式是常量值（比如直接写死的字符串）
• 表达式不依赖右表的任何字段，或者优化器判定该表达式可以脱离右表行独立计算

举个具体的例子：
如果你的视图最初是这么定义的（常量文本）：

CREATE VIEW my_view AS
SELECT id AS view_id, '固定文本' AS text_col FROM right_table;

优化器合并后的查询会变成：

SELECT left_table.*, right_table.id AS view_id, '固定文本' AS text_col
FROM left_table LEFT JOIN right_table ON left_table.id = right_table.id;

这时候，哪怕右表没有匹配的行，'固定文本'这个常量表达式依然会被执行并输出，而不是返回NULL。

但如果你修改视图的文本生成逻辑，让它依赖右表的字段，比如：

CREATE VIEW my_view AS
SELECT id AS view_id, CONCAT(int_col1, int_col2) AS text_col FROM right_table;

合并后的查询就会变成：

SELECT left_table.*, right_table.id AS view_id, CONCAT(right_table.int_col1, right_table.int_col2) AS text_col
FROM left_table LEFT JOIN right_table ON left_table.id = right_table.id;

这时候，当右表没有匹配行时，int_col1和int_col2都是NULL，CONCAT的结果自然也是NULL，就完全符合左连接的定义了。

总结 #

视图的文本生成逻辑是否依赖右表字段，会影响MySQL优化器的合并行为：

• 若表达式不依赖右表行数据，优化器会把它当作独立于连接的逻辑执行，导致非匹配行也有值
• 若表达式依赖右表字段，当右表无匹配行时，依赖字段为NULL，表达式结果也会是NULL，符合预期

内容的提问来源于stack exchange，提问作者user2834566