MySQL 8.0+才支持窗口函数，5.7及更早版本会报ERROR 1064；ROW_NUMBER()等必须在最终查询层级使用，不可嵌套于SET或INSERT SELECT表达式中，须用子查询或CTE封装。
确认MySQL版本是否支持窗口函数
MySQL 8.0+ 才支持窗口函数，5.7 及更早版本直接报 ERROR 1064。别跳过这步——很多线上环境仍跑着 5.7，SELECT VERSION() 必须在存储过程开头或调试阶段先执行。如果返回类似 5.7.39，窗口函数语法（如 ROW_NUMBER()、SUM() OVER）一律不可用，强行写会编译失败，不进执行阶段就卡住。
ROW_NUMBER() 等不能“裸用”在赋值或 INSERT SELECT 中
常见错误是想在存储过程中直接用 SET @rn = (SELECT ROW_NUMBER() OVER(...)) 或 INSERT INTO tmp SELECT ..., ROW_NUMBER() OVER(...) FROM t——MySQL 会抛出 FUNCTION cannot be used in this context。根本原因是：窗口函数必须出现在最终返回行集的查询层级，不能嵌套在表达式内部。
- 正确做法是用子查询或 CTE 封装窗口逻辑，再对外层操作
- 要写入临时表，先建好含
rn列的表结构，再INSERT INTO tmp SELECT ..., ROW_NUMBER() OVER(...) FROM ... - 避免在
WHERE、HAVING、SET语句中直接调用窗口函数，语法不许
PARTITION BY 和 ORDER BY 必须显式写进 OVER()，不能靠外层排序
典型误写：SELECT name, ROW_NUMBER() OVER() AS rn FROM users ORDER BY score DESC。这样 ROW_NUMBER() 实际按无序计算，结果每次可能不同。窗口函数的排序逻辑必须落在 OVER(ORDER BY score DESC) 里；如果还要分组编号，得加 PARTITION BY user_id。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
OVER()里至少要有PARTITION BY或ORDER BY其一，否则窗口范围是全表，编号无意义 -
ORDER BY在OVER内决定编号顺序，外层ORDER BY只影响最终输出顺序，不影响编号本身 - 涉及去重或取最新记录时，
ORDER BY created_at DESC, id DESC比单用id更可靠，防 NULL 或时间戳重复
GROUP BY 和窗口函数混用会冲突，必须拆层
如果存储过程中已有 GROUP BY，又在同级 SELECT 里写 SUM(amount) OVER (PARTITION BY category)，MySQL 报 ERROR 1140: In aggregated query without GROUP BY。因为窗口函数和普通聚合不能共存于同一 SELECT 层级。
- 方案一：去掉
GROUP BY，改用窗口函数完成累计，例如SUM(amount) OVER (PARTITION BY category ORDER BY date) - 方案二：用 CTE 先聚合，再对聚合结果应用窗口函数，比如
WITH daily_total AS (SELECT category, DATE(created_at) d, SUM(amount) s FROM orders GROUP BY category, DATE(created_at)) SELECT ..., SUM(s) OVER (PARTITION BY category ORDER BY d) FROM daily_total - 注意：CTE 在 MySQL 8.0+ 存储过程中完全可用，但别在低版本模拟它——5.7 不支持
最容易被忽略的是执行时机：窗口函数在 WHERE 和 GROUP BY 之后运行，但早于外层 ORDER BY 和 LIMIT。这意味着传参过滤（如 WHERE status = p_status）会影响窗口计算范围，但 OVER(PARTITION BY @p_col) 这种动态列名写法无效——@p_col 被当字面量处理，不是字段名。
