REGEXP_LIKE几乎不走索引，因其逐行调用正则引擎，无法利用B-Tree索引有序性做范围跳转，即使模式为'^john'也极少退化为索引扫描，实测多为全表扫描。
REGEXP_LIKE 为什么几乎不走索引
MySQL 的 REGEXP_LIKE（以及旧版 RLIKE 和 REGEXP）本质上是逐行调用正则引擎，无法利用 B-Tree 索引的有序结构做范围跳转。哪怕写成 REGEXP_LIKE(name, '^john')，优化器也不会自动退化为 LIKE 'john%' 的索引扫描路径——除非你用的是 MySQL 8.0+ 且字段排序规则支持前缀剪枝（如 utf8mb4_0900_as_cs），但这种“可能走索引”极不稳定，实测中多数情况仍全表扫描。
PostgreSQL 的 ~ 和 ~* 同样绕过 pg_trgm GIN 索引；Oracle 虽有函数索引支持 REGEXP_LIKE，但需显式创建，且只对固定模式生效；SQL Server 2025 的 RE2 实现也不下推索引。
全表扫描不是最糟的，重复拷贝才是
正则匹配过程会把整行文本（尤其是 TEXT 或长 VARCHAR）完整复制进正则引擎内存区处理，而不是流式读取或偏移访问。这意味着：
- 每行匹配都要分配新内存、做字符边界判定（utf8mb4 下更重）
- 含
.*或[a-z]{1,100}这类贪婪量词时，引擎可能反复回溯，CPU 占用飙升 - 10 万行 × 平均 200 字符 → 实际处理数据量远超磁盘读取量，IO + CPU 双瓶颈
别信“语法简洁=性能更好”
很多人改用 REGEXP_LIKE 是因为写起来比一堆 SUBSTRING+INSTR 清爽，但这不等于更快。真实瓶颈常在模式本身：
— REGEXP_LIKE(email, '@[a-z]+.[a-z]{2,}$')：看似合理，但域名部分长度不可控，引擎必须穷举所有后缀可能
— REGEXP_LIKE(desc, '(urgent|critical|high)')：等价于三个 OR，但 IN ('urgent','critical','high') 能走索引，而正则不能
— REGEXP_LIKE(phone, '^[1-9][0-9]{10}$')：纯数字校验，用 phone REGEXP '^[0-9]{11}$' AND phone NOT LIKE '0%' 都比它快，因前者可被优化器拆解，后者锁死整条路径
真正需要正则时，怎么减伤
绕不开就别硬扛，把正则塞到最小数据集里跑：
- 前置至少一个高选择性索引条件：
WHERE status = 'active' AND created_at > '2025-06-01' AND REGEXP_LIKE(content, 'error') - 大字段先截断：
REGEXP_LIKE(LEFT(body, 200), 'TODO:.*?;')，再给LEFT(body, 200)建前缀索引 - 高频模式预计算：
ALTER TABLE logs ADD is_error TINYINT GENERATED ALWAYS AS (CASE WHEN content REGEXP '\berror\b' THEN 1 ELSE 0 END) STORED，然后直接查is_error = 1
复杂点在于：正则不是开关，而是光谱——从 ^abc$ 到 .*
.*
.*，性能落差可达百倍，但 SQL 层根本不会提示你哪一段开始变慢。得靠 EXPLAIN FORMAT=TREE 看实际扫描行数，而不是相信模式看起来“很短”。
