MySQL 5.7不支持FIRST_VALUE()，因其窗口函数功能直到8.0才引入，内核级不识别该语法，报错ERROR 1064；可用JOIN+GROUP BY取每组最小时间戳记录，或用用户变量模拟排序后首值，但存在多行返回、NULL处理、性能差及维护难等问题。
为什么MySQL 5.7不能直接用FIRST_VALUE()？
因为窗口函数是MySQL 8.0才引入的特性，5.7压根不识别FIRST_VALUE()、ROW_NUMBER()这些语法，执行会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。不是配置问题，是内核不支持，没法通过改参数绕过。
用JOIN + GROUP BY模拟最简场景
如果只需要按某个字段分组后取每组“第一条”记录（比如按category分组，取created_at最早那条），可以用自连接或子查询找最小时间戳再关联：
SELECT t1.* FROM orders t1 JOIN ( SELECT category, MIN(created_at) AS min_time FROM orders GROUP BY category ) t2 ON t1.category = t2.category AND t1.created_at = t2.min_time;
注意点：
- 如果有多个记录
created_at相同，可能返回多行——这和FIRST_VALUE()行为不一致，后者只返回一行（取决于排序和ROWS帧定义） - 必须有明确的“第一”的判定依据（如时间、ID），不能靠插入顺序
- 没有
ORDER BY上下文时，MIN(id)比MIN(created_at)更稳定，因ID不会重复
用变量模拟带排序的窗口行为
要逼近FIRST_VALUE(col) OVER (PARTITION BY a ORDER BY b)的效果，得手动维护分组内的序号。MySQL 5.7支持用户变量，但要注意执行顺序不可靠，必须用派生表强制排序：
SELECT id, category, amount,
first_amount AS first_value_amount
FROM (
SELECT id, category, amount,
@first := IF(@prev = category, @first, amount) AS first_amount,
@prev := category
FROM orders
JOIN (SELECT @first := NULL, @prev := '') AS _init
ORDER BY category, created_at ASC
) AS ranked;关键细节：
-
ORDER BY必须写在子查询里，且顺序要和你想模拟的窗口ORDER BY完全一致 - 变量赋值顺序依赖执行计划，MySQL 5.7优化器可能重排，所以一定要用
JOIN初始化变量 + 显式ORDER BY锁定顺序 - 如果
category有NULL值，@prev = category会恒为FALSE，需改成IFNULL(@prev, '') = IFNULL(category, '') - 这个方案在大数据量下性能明显劣于原生窗口函数，别在上百万行表上直接套用
什么时候该放弃模拟，考虑升级或换方案？
如果你的业务需要频繁使用FIRST_VALUE()、LAG()、RANGE帧等复杂窗口逻辑，硬在5.7里拼变量或多重子查询，代码可读性、维护性和性能都会快速恶化。特别是涉及多层嵌套、动态排序或实时分析的场景，变量方案极易出错且难以调试。
真正卡住的往往不是语法转换，而是事务隔离级别下变量状态不一致、主从同步时执行顺序差异、以及无法利用8.0的窗口函数索引优化能力——这些隐性成本比改几行SQL重得多。
