MySQL 8.0 存储过程不适合海量数据特征提取，因其单线程、内存受限、无并行能力，全量加载易OOM；百万行内可轻量使用，但须规避游标全表扫描、JSON_EXTRACT未脱壳、误用JSON_SET等致命坑。
直接说结论：MySQL 8.0 存储过程不适合做“海量数据特征提取”——它不是设计来干这事的。真要跑亿级表的统计、分组、嵌套聚合或 JSON 解析，会卡死、OOM、锁表，还难调试。但如果你的数据量在百万行以内，且特征逻辑简单（比如从 JSON 字段里提几个字段、算个占比、打个标签），那可以用，关键得避开几个致命坑。
为什么不能用存储过程处理真正海量数据
MySQL 存储过程是单线程、内存受限、无并行能力的执行单元。它没有向量化计算、不支持窗口函数的增量计算、无法流式读取大结果集——所有数据都得一次性 load 到内存再处理。哪怕你写 WHILE 循环 + FETCH 游标，底层仍是全表扫描 + 逐行 fetch，I/O 和 CPU 压力都压在单个连接上。
典型症状：ERROR 1205 (40001): Deadlock found when trying to get lock、Out of memory、客户端超时断连、SHOW PROCESSLIST 里长期卡在 Sending data 状态。
JSON 字段特征提取必须用 ->> 而不是 JSON_EXTRACT
90% 的“没提取到值”问题，根源是把 JSON_EXTRACT() 当成字符串函数用了。它返回的是 JSON 类型值（带引号），不是裸字符串或数字：
→ SET v_name = JSON_EXTRACT(in_json, '$.name'); → v_name 存的是 "张三"（含双引号）
→ 后续 v_name = '张三' 永远为 FALSE
→ v_age + 1 可能隐式转成字符串拼接，变成 "251"
正确写法只有两种：
- SET v_name = in_json->>'$.name';
- SET v_age = CAST(in_json->>'$.age' AS UNSIGNED);
别信 JSON_UNQUOTE(JSON_EXTRACT(...)) ——虽然等价，但多一层函数调用，没必要。
游标遍历大表前必须加 LIMIT + OFFSET 或 WHERE 过滤
直接对千万行表声明游标：DECLARE cur CURSOR FOR SELECT id, payload FROM big_table;，MySQL 会先执行完整 SELECT 并缓存全部结果到临时内存区（可能达 GB 级），还没开始 FETCH 就 OOM。
安全做法：
- 先用 WHERE created_at BETWEEN ? AND ? 按时间分区切片
- 或用主键分页：WHERE id > last_id ORDER BY id LIMIT 1000
- 游标内每次只 fetch 100–500 行，配合 LEAVE 提前退出
- 必须配 DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;，否则游标到末尾会报错中断
特征写回要用 JSON_REPLACE，别碰 JSON_SET
想更新某条记录的 JSON 字段里的一个 key（比如给 {"score": 85} 加个 "level": "A"），用 JSON_SET() 是危险的：
- 如果原字段是 NULL，JSON_SET(NULL, '$.level', 'A') 返回仍是 NULL，整个 update 失效
- 如果路径不存在（比如写成 '$.user.level' 但实际是 '$.profile.level'），JSON_SET 会强行新建层级，破坏原有结构
- 并发写入时无原子性保障，两个过程同时 JSON_SET 同一字段，后写的会覆盖前写的
稳妥方案：
- 先 SELECT json_col INTO @j FROM t WHERE id = ?;
- 再 SET @j_new = JSON_REPLACE(@j, '$.level', 'A');
- 最后 UPDATE t SET json_col = @j_new WHERE id = ?;
真正海量场景下，特征提取该交给 Spark、Flink 或 ClickHouse；MySQL 存储过程只适合轻量、确定性高、可预估资源消耗的小批量任务。最易被忽略的一点：哪怕逻辑再简单，只要涉及 JSON 解析 + 循环 + UPDATE，就必须在事务外加 START TRANSACTION 显式控制，并设好 innodb_lock_wait_timeout，否则锁等待会拖垮整个库。
