MySQL原生REGEXP不支持捕获组提取，只能匹配判断；SUBSTRING_INDEX通过两次切分（先去协议再截路径）模拟提取域名，高效但需处理无协议、带用户信息、端口等边界情况。
为什么不能直接用 REGEXP 提取域名
MySQL 原生 REGEXP（包括 REGEXP_LIKE）只支持匹配和过滤，不支持捕获组或子串提取。你写 url REGEXP 'https?://([^/]+)' 只能判断真假，拿不到 example.com 这个部分——这是最常踩的坑。
SUBSTRING_INDEX 是怎么“模拟正则提取”的
核心思路是把 URL 拆成三段：协议头 + 域名 + 路径，再用 SUBSTRING_INDEX 切两次。它虽不是正则，但对结构固定的 URL（如以 http:// 或 https:// 开头）足够可靠且高效。
关键步骤：
- 先用
SUBSTRING_INDEX(url, '://', -1)去掉协议，得到example.com/path/to/page - 再用
SUBSTRING_INDEX(..., '/', 1)截取第一个/之前的部分，即域名 - 合起来就是：
SUBSTRING_INDEX(SUBSTRING_INDEX(url, '://', -1), '/', 1)
注意：如果 URL 不带协议（如 www.example.com/path），第一层切会失效，得加 IF 判断或前置补协议。
处理带端口、用户信息、无协议的 URL
真实数据往往不规范，光靠两次 SUBSTRING_INDEX 会漏掉 user:pass@host:8080 这类情况。这时候需要分层清洗：
- 先用
REPLACE或嵌套SUBSTRING_INDEX去掉@前的内容（如SUBSTRING_INDEX(url, '@', -1)） - 再对结果做
'://'和'/'切分 - 端口（
:8080）保留在域名里是合理的，除非你明确要剥离——那就得配合LOCATE+LEFT手动截断 - 纯域名（无协议无路径）可加兜底：
IF(url LIKE '%//%' OR url LIKE '%/%', ..., url)
性能和边界 case 注意什么
SUBSTRING_INDEX 是字符串函数，比正则快得多，但要注意：
- 空值或 NULL 输入会导致整个表达式返回 NULL，建议外层包
COALESCE(..., '') - URL 含中文、特殊字符（如
https://例子.中国/path）不影响切分逻辑，但需确认字段编码是utf8mb4 - 若用在大表
WHERE条件中提取后过滤，无法走索引——这种场景应提前计算并存入冗余字段 - 别忘了测试
ftp://、file:///、甚至mailto:user@example.com这些非 HTTP 协议，它们的结构差异会暴露逻辑漏洞
真正难的不是写出那两层 SUBSTRING_INDEX，而是想清楚你的 URL 字段到底有多脏，以及要不要为极少数异常格式增加维护成本。
