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为例：
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，此时加索引也无济于事——窗口函数本身就需要全局可见性。
