REGEXP查询几乎不走索引，必然全表扫描；应先用索引条件过滤数据，再对小结果集做正则精筛，避免直接在大数据量上使用。
MySQL 中 REGEXP 查询几乎从不走索引，直接全表扫描是常态；想靠它提速，必须绕开“纯正则匹配”这个陷阱——核心思路是：先用索引过滤，再用正则精筛。
为什么 REGEXP 查询慢得离谱
MySQL 的 REGEXP 引擎在执行时无法利用 B-Tree 索引，哪怕模式是 ^abc 或 abc$，只要用了 REGEXP，整列数据就会被逐行提取、逐行匹配。实测 200 万行表上 name REGEXP '^john' 耗时通常是 name LIKE 'john%' 的 8–12 倍。
-
REGEXP不支持前缀索引加速，也不支持覆盖索引 - 即使写成
REGEXP '^[a-z]{3}123'这种看似可优化的模式，MySQL 仍不做任何预判或剪枝 - 多字节字符集（如
utf8mb4）下性能进一步下降，因正则引擎需反复做字符边界判定
能用 LIKE 就别用 REGEXP，尤其这些场景
很多开发者以为 REGEXP '^abc' 比 LIKE 'abc%' 更“精确”，其实完全没必要，且代价更高：
-
REGEXP '^abc'→ 直接换成LIKE 'abc%'，前提是字段有索引，就能走索引范围扫描 -
REGEXP 'abc|def|xyz'→ 改用IN或OR：name IN ('abc', 'def', 'xyz')，能命中索引 -
REGEXP '[0-9]{4}-[0-9]{2}-[0-9]{2}'（匹配日期格式）→ 若字段是DATE或规范存的VARCHAR，直接用BETWEEN或函数提取：DATE(date_str)，再加索引
必须用 REGEXP 时，怎么减少伤害
真绕不开正则（比如要匹配邮箱本地部分含数字+字母混合、且长度在 5–15 之间），就只能“缩小扫描面”：
- 前置强过滤条件：确保
WHERE中至少有一个带索引的等值/范围条件，例如status = 'active' AND created_at > '2025-01-01'，把百万级扫描压到几千行再正则 - 避免在大文本字段（如
TEXT）上直接REGEXP，先用SUBSTRING()或LEFT()截取前 50 字符建前缀索引，再用正则处理子集 - 对高频正则模式，考虑在应用层缓存结果 ID，或用触发器+冗余字段预计算（如新增
is_valid_email布尔列并维护）
FULLTEXT 是比 REGEXP 更现实的替代方案
当你要查的是“含关键词、近义词、模糊拼写”的文本内容（比如商品描述、用户评论），REGEXP 不仅慢，还写不出来。这时候 FULLTEXT 索引 + MATCH ... AGAINST 才是正解：
ALTER TABLE products ADD FULLTEXT INDEX ft_desc (description);SELECT * FROM products WHERE MATCH(description) AGAINST('+wireless +bluetooth' IN BOOLEAN MODE);- 注意：
FULLTEXT对停用词、最小词长（ft_min_word_len默认 4）、分词方式敏感，上线前务必用真实数据验证效果
真正卡住性能的，往往不是正则本身多难写，而是没意识到 REGEXP 一出现，索引就自动失效——所有优化动作，都得围绕“怎么让 MySQL 少扫几行”展开，而不是“怎么写更漂亮的正则”。
