phpMyAdmin 4.x因底层SQL解析器不识别OVER()等窗口函数关键字，导致语法解析失败而非MySQL执行报错；必须升级至5.0+或改用命令行客户端才能正常使用。
phpMyAdmin 4.x 不支持窗口函数，不是配置问题，是版本硬限制
phpmyadmin 4.x（包括 4.9.x 最终版）底层 sql 解析器和语法高亮引擎完全不识别 over()、partition by、row_number() 等窗口函数关键字。它会把 row_number() over (order by id) 当作非法表达式直接截断或报错，哪怕 mysql 服务端（8.0+）本身完全支持。
错误现象：报错位置诡异，实际是解析器“不认识”而非执行失败
你执行含 LAG() 或 RANK() 的语句时，常见表现不是 MySQL 报错，而是 phpMyAdmin 自身返回：
-
#1064 - You have an error in your SQL syntax，但错误行号指向窗口函数之后的某行（比如FROM或WHERE），因为解析器在遇到OVER时已放弃语法树构建 - SQL 编辑框里窗口函数部分显示为纯白或乱码，无语法高亮——这是解析失败的视觉信号
- 点击「执行」后页面卡住几秒，最终返回空结果或 500 错误，日志里找不到对应 MySQL 错误，说明请求根本没发到服务端
绕过方案：只换入口，不换 MySQL
窗口函数能力在 MySQL 8.0+ 已就绪，问题只出在 phpMyAdmin 4.x 的前端处理层。可行解法只有两个：
- 用命令行客户端直连：
mysql -u root -p your_db，然后粘贴执行，所有窗口函数正常工作 - 升级 phpMyAdmin 到 5.0+（2020 年起支持），但注意：XAMPP for Windows 默认捆绑的是 4.9.x，需手动下载 5.2.1+ 版并替换整个
phpmyadmin/目录，且确保 PHP ≥ 7.2 - 临时替代：把窗口函数逻辑拆成子查询 + 变量模拟（如用
@row := @row + 1模拟ROW_NUMBER()），但仅适用于简单排序场景，无法替代LEAD/LAG或分组累计
容易被忽略的关键点
即使你确认 MySQL 是 8.0.33、SELECT VERSION() 返回正确，只要 phpMyAdmin 是 4.x，窗口函数就注定被前端拦截。它不转发、不尝试、不报真实错误——就像收件人拒收一封地址正确的信，只因信封上印了他没见过的邮票图案。
