mysql 8.0+才原生支持窗口函数，但其执行必先完成全量排序，无法真正流式返回；流式消费需客户端禁用缓冲（如pymysql的sscursor）并逐行获取。
MySQL 8.0+ 才真正支持窗口函数，流式处理需靠客户端配合
MySQL 本身没有“流式函数”这个概念——它不提供类似 PostgreSQL 的 LISTEN/NOTIFY 或 Kafka 风格的持续数据流 API。所谓“流式”，在 MySQL 场景中通常指：客户端逐行消费大结果集，避免一次性加载到内存。而窗口函数（如 ROW_NUMBER()、RANK()、LAG()）从 MySQL 8.0 开始原生支持，但使用不当极易触发临时表和磁盘排序。
窗口函数必须搭配 OVER() 子句，且 ORDER BY 是性能关键
窗口函数不能脱离 OVER() 子句独立使用，否则会报错 ERROR 1064 (42000): You have an error in your SQL syntax。更关键的是：OVER(ORDER BY ...) 中的字段必须有对应索引，否则 MySQL 会强制对整个分区做文件排序（Using filesort），尤其在 PARTITION BY + ORDER BY 组合下，性能下降呈指数级。
实操建议：
- 对
OVER(PARTITION BY user_id ORDER BY created_at)，应建立联合索引(user_id, created_at)，而非仅created_at - 避免在
ORDER BY中使用函数，如OVER(ORDER BY DATE(created_at))会导致索引失效 -
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW比默认的RANGE更高效，显式声明可避免隐式转换开销
模拟“流式查询”必须关闭缓冲并设置 fetch_size
MySQL 协议默认启用结果集缓冲（mysql_store_result），即使 SQL 逻辑上是“逐行返回”，客户端仍会等全部数据就绪才开始处理。要实现真正流式消费，需主动切换为 mysql_use_result 模式，并配合客户端驱动的流式 API。
以 Python 的 pymysql 为例：
eSiteGroup站群管理系统是基于eFramework低代码开发平台构建，是一款高度灵活、可扩展的智能化站群管理解决方案，全面支持SQL Server、SQLite、MySQL、Oracle等主流数据库，适配企业级高并发、轻量级本地化、云端分布式等多种部署场景。通过可视化建模与模块化设计，系统可实现多站点的快速搭建、跨平台协同管理及数据智能分析，满足政府、企业、教育机构等组织对多站点统一管控的
import pymysql
conn = pymysql.connect(
host='localhost',
user='root',
password='',
database='test',
# 关键：禁用缓冲
cursorclass=pymysql.cursors.SSCursor # ServerSideCursor
)
cursor = conn.cursor()
cursor.execute("SELECT id, name, amount FROM large_table ORDER BY id")
while True:
row = cursor.fetchone() # 每次只取一行，不加载全量
if row is None:
break
process(row)
cursor.close()
conn.close()常见错误：
- 误用
Cursor（默认缓冲模式），导致 OOM - 未设置
SQL_NO_CACHE（虽已弃用，但旧版本需注意查询缓存干扰流式语义） - 在事务中执行流式查询后未及时
fetchall()或close()，导致连接被锁住
窗口函数与流式不可兼得：ORDER BY 强制全量排序
这是最容易被忽略的硬限制：只要 SQL 中含窗口函数，MySQL 就必须先完成所有窗口计算，才能向客户端输出第一行。这意味着——SELECT ROW_NUMBER() OVER(ORDER BY id) AS rn, * FROM huge_table 不可能“流式返回”，哪怕你用了 SSCursor，也得等全部行排序+编号完毕才开始传输。
优化思路只有两个方向：
- 用应用层分页替代窗口函数：例如用
LIMIT offset, size分批查，再在代码里补序号 - 将窗口计算下沉到物化视图或汇总表，日常查询只读预计算结果
强行在大表上跑带 OVER() 的查询，EXPLAIN 中常出现 Using temporary; Using filesort，此时加索引也无济于事——窗口函数本身就需要全局可见性。
