MySQL HeatWave使用REGEXP_SUBSTR触发3877错误，仅IN/NOT IN过滤可执行

一、现象本质：HeatWave正则引擎的优化器边界缺陷 #

你遇到的3877错误，并非正则语法问题，而是HeatWave正则引擎在全量大规模数据集上的优化器逻辑缺陷。核心原因是：

• 无额外过滤条件时，HeatWave会直接对7000万行全表执行正则提取，此时引擎的正则处理模块可能因高负载、未正确处理超长TEXT字段/空值/无匹配行等边缘场景，触发内部执行错误（错误提示标注为语法问题属于误报）。
• 加入device_id IN/NOT IN这类无关过滤后，查询执行计划被强制改变：HeatWave先执行过滤缩小数据集，再对小批量数据执行正则提取，避开了全量数据下的引擎异常。

这类情况属于HeatWave在大规模复杂正则处理中的边界Bug，官方社区也有过类似反馈。

二、无关过滤能规避错误的原因 #

HeatWave优化器在识别到IN/NOT IN条件时，会优先执行数据过滤，将7000万行的数据集缩小到正则引擎能稳定处理的规模。此时正则提取仅在过滤后的子集上执行，不会触发引擎的内部溢出或执行异常，从而绕过了原本的Bug场景。

三、HeatWave大表安全使用正则的可靠方案 #

1. 强制先过滤再正则（明确执行顺序） #

用子查询硬过滤掉不可能包含目标审计码的行，再执行正则提取，避免全量扫描：

SELECT 
    REVERSE(REGEXP_SUBSTR(REVERSE(log_detail), '[0-9A-Z]{4}(-[0-9A-Z]{4}){3}', 1, 1)) AS audit_code
FROM (
    SELECT log_detail 
    FROM logs_audit 
    WHERE log_detail IS NOT NULL 
      AND LENGTH(log_detail) >= 19 -- 审计码最小长度为19（4-4-4-4格式）
) AS filtered_data;

2. 简化正则表达式 #

HeatWave对复杂正则的支持有限，改用更简洁的正则模式，降低引擎处理压力：
将重复的[A-Z0-9]{4}-简化为[0-9A-Z]{4}(-[0-9A-Z]{4}){3}，减少正则引擎的解析复杂度。

3. 预提取审计码到单独字段（最优方案） #

如果审计码需要高频查询，直接新增字段存储预提取结果，彻底规避正则性能和稳定性问题：

-- 新增字段
ALTER TABLE logs_audit ADD COLUMN audit_code VARCHAR(20);

-- 分批次批量更新（避免锁表）
UPDATE logs_audit 
SET audit_code = REVERSE(REGEXP_SUBSTR(REVERSE(log_detail), '[0-9A-Z]{4}(-[0-9A-Z]{4}){3}', 1, 1))
WHERE audit_code IS NULL 
LIMIT 10000; -- 每次更新1万行，循环执行直到全表完成

这也是HeatWave官方推荐的大表高频查询优化方案。

4. 临时禁用HeatWave加速（应急方案） #

若以上方案无法快速落地，可强制查询在MySQL节点执行，避开HeatWave的正则Bug：

SELECT /*+ NO_HEATWAVE */
    REVERSE(REGEXP_SUBSTR(REVERSE(log_detail), '[0-9A-Z]{4}(-[0-9A-Z]{4}){3}', 1, 1)) AS audit_code
FROM logs_audit;

注意：该方案会失去HeatWave的性能优势，仅适合临时查询。

内容的提问来源于stack exchange，提问作者franco pina