MySQL游标无法真正流式读取大文本字段，因其会整行加载进内存，易触发OOM或Packet too large错误；需调大max_allowed_packet、及时CLOSE游标、分批处理，并优先采用应用层流式读取等替代方案。
MySQL存储过程里用游标处理大文本数据流，本质上是“伪流式”——它不真正流式传输，而是靠逐行拉取+及时释放来缓解内存压力；真要流式读大文本，得换应用层或用SELECT ... INTO OUTFILE配合外部工具。
为什么不能直接用游标读大文本字段（如TEXT、MEDIUMTEXT）？
MySQL游标本身不区分字段类型，但实际执行时会把整行结果加载进内存。如果某列是几MB的TEXT，而游标又没及时CLOSE，容易触发Out of memory或Packet too large错误（尤其在max_allowed_packet设得偏小的实例上）。另外，游标打开后，MySQL会缓存整个结果集元信息，即使你只FETCH一行，底层仍可能预分配较大缓冲区。
-
max_allowed_packet必须 ≥ 单行最大文本长度 + 其他字段开销，否则OPEN cursor_name直接报错 - 游标未
CLOSE前，连接持有的内存不会自动回收，长时间循环易OOM -
FETCH操作本身不释放已读行内存，靠MySQL内部GC机制，不可控
DECLARE CONTINUE HANDLER FOR NOT FOUND必须放在OPEN之前
句柄声明顺序错会导致游标读到末尾时不触发SET done = 1，后续FETCH继续执行，最终done始终为FALSE，陷入死循环。这不是语法错误，是执行逻辑陷阱。
- 必须在
OPEN cursor_name前完成DECLARE CONTINUE HANDLER FOR NOT FOUND -
done变量建议用INT DEFAULT 0或BOOLEAN DEFAULT FALSE，避免隐式类型转换干扰判断 - 不要在
FETCH后立刻SELECT输出大文本——这会让客户端也缓存全文本，加重网络和内存负担
如何安全地逐行处理含大文本的查询结果？
核心原则：只取必要字段、尽快处理、立即释放。比如你要清洗article_content字段，就别SELECT *，而应明确指定id和article_content，并在FETCH后立刻做UPDATE或INSERT INTO log_table，而不是拼接CONCAT再SELECT。
- 游标查询语句中，用
WHERE尽量缩小结果集（例如按created_at < '2025-01-01'分批） - 变量声明要与字段类型严格匹配：
DECLARE content TEXT，不能用VARCHAR(255)截断 - 每轮循环末尾加
DO SLEEP(0.01)（需mysql.sys权限），缓解CPU和锁竞争（高并发下尤其重要） - 处理完一批（如1000行）后主动
CLOSE并DEALLOCATE游标，再重新DECLARE新游标分页读取
替代方案比硬扛游标更实用
真遇到GB级文本表，游标只是权宜之计。生产环境更推荐：
- 应用层用JDBC/ODBC的
StreamingResultSet（Java）或cursor=True（Pythonpymysql）实现真流式读取 - 用
SELECT id, article_content INTO DUMPFILE '/tmp/batch_1.txt'导出分片，再由shell脚本或Go程序处理 - 改用
INFORMATION_SCHEMA.PROCESSLIST监控长事务，配合pt-archiver做归档式逐行迁移
游标不是万能的管道，它本质是存储过程内的同步控制结构；大文本场景下，最易被忽略的是max_allowed_packet动态调整时机——必须在DELIMITER块外先SET SESSION max_allowed_packet = 64*1024*1024，否则游标一打开就失败。
