substring_index(email, '@', -1)可直接提取邮箱域名，因@通常仅出现一次且域名在其右侧；负数count语义清晰、容错更强，但需用if或regexp兜底空值及异常格式。
为什么直接用 SUBSTRING_INDEX(email, '@', -1) 就够了
绝大多数邮箱的结构是 local@domain.com，@ 符号只出现一次，且域名部分就在它后面。所以用 SUBSTRING_INDEX(email, '@', -1) 直接取最后一个 @ 之后的内容，就是完整域名——不需要正则、不用嵌套函数，也基本不会出错。
常见错误是写成 SUBSTRING_INDEX(email, '@', 1)，结果拿到的是用户名（local），方向反了；或者漏掉负号，误用 1 当作起始位置参数（SUBSTRING_INDEX 的第三个参数不是偏移量，是“取第几个分隔符前/后”的计数）。
-
SUBSTRING_INDEX(str, delim, count)中count为负数时，表示从右往左数第|count|个分隔符，并返回其右侧所有内容 - 邮箱中 @ 最多只该出现一次，所以
-1和2在正常数据下结果一致，但-1更语义清晰、容错更强（比如某条数据意外含两个 @，-1仍取最右边的域名部分） - 如果字段可能为空或不含 @，
SUBSTRING_INDEX会原样返回原值——这不是 bug，是设计行为，需额外用IF或CASE处理
如何安全处理不含 @ 或空值的邮箱字段
生产环境里总会有脏数据：空字符串、NULL、纯用户名没 @、甚至写成 user@@domain.com。这时候直接 SUBSTRING_INDEX 会返回错误结果（比如空串或整个字段），必须兜底。
推荐用 IF 包一层，判断是否含 @：
SELECT email, IF(email LIKE '%@%', SUBSTRING_INDEX(email, '@', -1), NULL) AS domain FROM users;
更严谨的写法是排除只有 @ 或结尾是 @ 的情况（比如 user@）：
- 用
CHAR_LENGTH(SUBSTRING_INDEX(email, '@', -1)) > 0确保截出来不为空 - 或直接用
REGEXP '^[^@]+@[^@]+\.[^@]+$'做粗筛（性能略低，但校验更准） - 注意：MySQL 8.0+ 支持
REGEXP_LIKE，5.7 只能用REGEXP，语法略有差异
SUBSTRING_INDEX 在 JOIN 或 WHERE 中的性能影响
在 WHERE 条件里写 SUBSTRING_INDEX(email, '@', -1) = 'gmail.com' 会导致全表扫描——因为函数作用于字段，无法走索引。
如果高频按域名查询，别依赖运行时截取。正确做法是：
- 新增一个
domain字段，用触发器或应用层同步写入（INSERT/UPDATE 时自动解析并存） - 给这个字段加索引：
CREATE INDEX idx_domain ON users(domain); - 查询直接写
WHERE domain = 'gmail.com'，毫秒级响应 - 若无法改表结构，至少把截取逻辑移到应用层（PHP/Python 拿到 email 后再处理），避免数据库重复计算
遇到带子域名或国际化域名怎么办
SUBSTRING_INDEX(email, '@', -1) 返回的是完整域名部分，比如 user@sub.example.co.uk → sub.example.co.uk，这本身没错。但如果你只需要主域名（example.co.uk），函数就无能为力了——它不识别 DNS 层级，也没内置 TLD 列表。
这时候必须明确需求边界：
- 只要一级域名（如 gmail.com、qq.com）：得靠外部库（如 PHP 的
parse_url+ 自定义 TLD 规则）或 MySQL UDF（不推荐，维护成本高） - 只要去掉子域名（取最后两段）：可用嵌套
SUBSTRING_INDEX(SUBSTRING_INDEX(email, '@', -1), '.', -2)，但对.co.uk类双后缀失效 - 实际业务中，90% 场景只需完整域名做去重或统计，
SUBSTRING_INDEX完全胜任；真要精确切分，别硬扛在 SQL 里
真正容易被忽略的点是：不同 MySQL 版本对 NULL 输入的 SUBSTRING_INDEX 行为一致，但和某些 ORM（如 Laravel 的 Query Builder）拼接时，NULL 可能被转成字符串 'NULL'，导致截出 'NULL' 而非 NULL——得查生成的 SQL 实际传了什么。
