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 > '2023-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 或聚合时行为差异明显。
