可用相关子查询模拟row_number()：对每行统计order_time小于等于它且id更小的记录数，确保行号唯一；需在where中加入主键id作为第二排序条件避免重复。
用相关子查询模拟 ROW_NUMBER() 实现行号
MySQL 5.7 或更早版本不支持窗口函数，ROW_NUMBER() 无法直接使用，但可以用相关子查询“数出前面有多少行满足条件”来模拟。核心逻辑是：对当前行的每一条记录，统计表中“排序字段小于等于它、且其他筛选条件匹配”的行数。
常见错误是忽略 ORDER BY 字段的唯一性——如果 order_time 有重复值，多个行会算出相同行号。解决办法是在子查询的 WHERE 条件里加入主键或唯一字段作为第二排序依据。
- 假设表为
orders，需按order_time升序编号，主键为id - 子查询写法：
(SELECT COUNT(*) FROM orders o2 WHERE o2.order_time - 性能影响明显：N 行数据会触发 N 次全表扫描（或索引扫描），大数据量时极慢；务必在
order_time, id上建联合索引
用相关子查询计算累计总和（Running Sum）
累计总和本质是“当前行及之前所有行的某字段之和”，相关子查询通过限定“小于等于当前行的排序值”来实现范围聚合。和行号类似，它也依赖稳定排序。
容易踩的坑是把条件写成 o2.amount ——这是按金额大小累计，不是按业务顺序（比如下单时间）累计。必须用排序字段（如 <code>order_time）而非聚合字段本身做比较。
- 正确写法（按时间累计）：
(SELECT SUM(o2.amount) FROM orders o2 WHERE o2.order_time - 若
order_time不唯一，同样要加入id消除歧义：o2.order_time - 注意 NULL 值：如果
amount可为空，SUM()会自动忽略，但若整列都为 NULL，结果为 NULL 而非 0；必要时用COALESCE(SUM(...), 0)
相关子查询 vs 窗口函数：什么情况下必须用前者
当你无法升级数据库、或所用环境明确禁用窗口函数（如某些旧版 Hive SQL 引擎、部分嵌入式 SQLite 配置），相关子查询是唯一可行方案。但它不是“兼容写法”，而是“降级方案”。
性能差异非常实际：10 万行数据下，相关子查询可能耗时数秒甚至分钟，而 SUM() OVER (ORDER BY ...) 通常在毫秒级完成。别为了“写法统一”在支持窗口函数的环境里硬套子查询。
- 确认 MySQL 版本：
SELECT VERSION();—— 8.0+ 才原生支持窗口函数 - PostgreSQL 8.4+、SQL Server 2005+、Oracle 8i+ 均支持，无需子查询模拟
- SQLite 3.25.0+ 支持，但需确认编译时启用了
ENABLE_WINDOW_FUNCTIONS
避免嵌套过深与笛卡尔积风险
相关子查询一旦出现在 SELECT 列表里，每列都是独立执行一次子查询。如果同时写出行号、累计和、累计平均值三个相关子查询，就是三次全表扫描——不是三次“部分扫描”，而是三次完整遍历。
更隐蔽的问题是 JOIN 后再套相关子查询：若主查询已关联多张表，子查询未显式限定表别名或过滤条件，可能意外引入隐式笛卡尔积，导致结果错乱或超时。
- 始终给子查询中的表起别名（如
o2），并确保所有字段带别名前缀 - 子查询里不要引用外部查询未暴露的字段（例如主查询用
JOIN users u ON o.user_id = u.id，子查询却写u.name——这会报错或返回空 - 测试时先用
LIMIT 10验证逻辑，再放开全量；观察执行计划中是否出现DEPENDENT SUBQUERY及其扫描行数
