派生表在FROM阶段物化，其作用域独立，无法引用外层ORDER BY或SELECT别名列；正确做法是将过滤下推至派生表内部或用CTE预计算，LATERAL仅支持关联字段引用而非排序列。
派生表作用域与SQL执行顺序冲突
派生表是独立作用域，它在FROM阶段就被解析和物化，而ORDER BY属于查询最后执行的阶段之一。外层的排序列（比如ORDER BY users.created_at DESC）根本还没被计算或绑定，派生表内部自然无法引用——不是语法写错了，是时序上“还不存在”。MySQL、PostgreSQL、SQL Server 全部遵循这个执行逻辑，报错信息如Unknown column 'users.created_at' in 'field list'或window functions are not allowed in WHERE本质都是同一类问题：列未就位。
别名在派生表里不可见，也不能用于WHERE过滤
即使你在外层SELECT中给列起了别名（如SELECT created_at AS sort_time FROM users），这个sort_time也只在SELECT和ORDER BY阶段生效，不会回传到派生表的FROM子句中。更关键的是：派生表里的WHERE不能用这个别名做条件，因为WHERE执行早于SELECT别名生成。
- 错误写法：
SELECT * FROM (SELECT id, created_at FROM users) AS u WHERE u.sort_time > '2024-01-01'（sort_time在派生表里根本没定义） - 正确做法：把过滤下推到派生表内部，用原始列名：
SELECT * FROM (SELECT id, created_at FROM users WHERE created_at > '2024-01-01') AS u - 若需动态值（如参数或关联字段），必须显式传入，例如
WHERE o.order_date > u.reg_date，且u必须是外层已声明的别名、o在子查询中存在并关联
MySQL 8.0.14+ 的 LATERAL 是唯一例外
只有启用LATERAL关键字的侧向派生表，才允许在子查询中引用同一FROM中左侧的表字段。但这不适用于ORDER BY列本身——它只解决“从左到右的列可见性”，不改变执行顺序。
- 合法示例：
SELECT u.name, s.amount FROM users u JOIN LATERAL (SELECT amount FROM sales s WHERE s.user_id = u.id ORDER BY s.date DESC LIMIT 1) s - 注意：
ORDER BY s.date DESC是子查询内部的排序，只为LIMIT 1服务；外层最终顺序仍由最外层ORDER BY控制 - 不支持：
ORDER BY (SELECT ...)直接出现在外层ORDER BY中，除非数据库明确支持标量子查询（如PostgreSQL 12+），但依然受单值、索引、性能三重限制
真正能用的替代路径只有两种
想让排序逻辑“看起来像来自子查询”，实际只能靠结构位移：要么把计算提到SELECT列表，要么把聚合提前固化。没有捷径，也没有跨层引用的取巧办法。
- 提前列别名：
SELECT id, name, (SELECT MAX(login_time) FROM logins l WHERE l.user_id = u.id) AS last_login FROM users u ORDER BY last_login DESC - 用CTE预计算：
WITH user_last AS (SELECT user_id, MAX(login_time) AS last_login FROM logins GROUP BY user_id) SELECT u.*, ul.last_login FROM users u LEFT JOIN user_last ul ON u.id = ul.user_id ORDER BY ul.last_login DESC - 避免在ORDER BY里重复执行子查询——每行触发一次，10万用户就是10万次独立执行，索引也救不了
复杂点在于：你写的每一层嵌套，都在增加优化器放弃重写为JOIN的概率。最容易被忽略的是，派生表一旦物化，就彻底脱离原表索引，哪怕只选两列，也可能因缺少(user_id, login_time)复合索引而全表扫描。
