17370845950

FROM子句是SELECT语句中必须存在的部分，用于指定数据源，支持单表、多表JOIN、子查询、VALUES等合法来源，不支持字段列表或直接过滤，表顺序影响JOIN执行与性能。

from 子句指定查询的数据源表或子查询

FROM 子句是 SELECT 语句中**必须存在**的部分（除非使用无表查询如 SELECT 1），它明确告诉 MySQL 数据从哪来。没有 FROM，MySQL 就不知道该查哪张表、哪些列、是否要关联——直接报错 ERROR 1064。

• 单表查询：写 FROM t_user，数据全部来自 t_user 表
• 多表连接：写 FROM t_order JOIN t_user ON t_order.uid = t_user.id，数据来自两个表的关联结果
• 子查询作表：写 FROM (SELECT id, name FROM t_user WHERE status = 1) AS active_users，数据来自这个内联视图
• 生成临时数据：用 VALUES ROW(), ROW()（MySQL 8.0.19+）也可作为 FROM 的来源，例如 FROM VALUES ROW(1,'a'), ROW(2,'b')

from 后不能直接跟字段列表或表达式

常见错误是把 FROM 当成“选字段”的地方，比如误写 SELECT name FROM name, age —— 这会触发语法错误，因为 name, age 不是合法的表名或别名。MySQL 要求 FROM 后必须是可识别的数据源：

• 真实表名（t_product）
• 带别名的表（t_product AS p）
• 子查询（必须加括号并显式命名，如 (SELECT ...) AS tmp）
• JOIN 链（t_a JOIN t_b ON ...，整个链算一个逻辑数据源）

字段筛选和计算属于 SELECT 和 WHERE 的职责，FROM 只管“源头在哪”。

from 中表顺序影响 JOIN 执行与性能

在多表 JOIN 中，FROM 后第一个表（驱动表）会被优先全扫描，后续表根据关联条件逐层匹配。这意味着：

• 小结果集的表尽量放前面，减少外层循环次数
• 有高效索引的关联字段，应确保其所在表处于被驱动位置（即非第一个）
• MySQL 8.0+ 优化器通常会自动重排，但复杂嵌套或强制 STRAIGHT_JOIN 时，FROM 顺序就变成硬性约束

SELECT u.name, o.amount
FROM t_user u
STRAIGHT_JOIN t_order o ON o.uid = u.id
WHERE u.reg_time > '2025-01-01';

这里 t_user 是驱动表，哪怕它比 t_order 大十倍，也会被先扫——顺序不可忽视。

from 子句不支持直接过滤，WHERE 才负责条件筛选

有人试图在 FROM 里写条件，比如 FROM t_log WHERE level = 'ERROR'，这是非法语法。MySQL 不允许在 FROM 中嵌入 WHERE；过滤必须交给独立的 WHERE 子句，或通过子查询封装：

• ✅ 正确：FROM t_log WHERE level = 'ERROR' → 错，语法错误
• ✅ 正确：FROM t_log WHERE level = 'ERROR' 改为 FROM t_log WHERE level = 'ERROR' → 仍错，WHERE 必须单独成子句
• ✅ 正确：FROM (SELECT * FROM t_log WHERE level = 'ERROR') AS err_logs
• ✅ 正确：FROM t_log WHERE level = 'ERROR' → 实际应写作：

  SELECT * FROM t_log WHERE level = 'ERROR';

真正容易被忽略的是：子查询作为 FROM 源时，它的 WHERE 属于子查询内部，不影响外层逻辑；而外层 WHERE 是另一轮过滤——两层条件不等价，尤其涉及 NULL 或聚合时行为差异明显。