charindex找不到@时返回0，直接用于substring会导致截取错位；正确做法是先用case when判断charindex>0，再计算起始位置和长度，同时对null和空格做预处理。
CHARINDEX 找不到 @ 符号时会返回 0，直接套用会导致 SUBSTRING 越界
SQL Server 中 CHARINDEX('@', email) 在邮箱字段为空、NULL 或不含 @ 时返回 0；而 SUBSTRING(email, start, length) 的 start 参数若为 0，会被当作 1 处理，结果截取错位。更危险的是，当 CHARINDEX 返回 0，再用它算后缀起始位置（比如 CHARINDEX('@', email) + 1），就会变成 1 —— 从开头截，完全不是后缀。
必须先过滤或兜底：
- 用
WHERE email LIKE '%@%'预筛，或在表达式中用CASE WHEN CHARINDEX('@', email) > 0 THEN ... ELSE NULL END - 避免对 NULL 字段直接计算：把
email包进ISNULL(email, '')或COALESCE(email, '') - 别依赖 LEN(email) - CHARINDEX(...) 算长度：如果 @ 在末尾（如
user@），结果会是负数，SUBSTRING报错
正确截取邮箱后缀的三步组合：定位 @、算起始、用 LEN 控制长度
后缀是从 @ 后第一个字符开始，到字符串末尾为止。不能简单用 LEN(email) - CHARINDEX('@', email) 当长度，因为 CHARINDEX 返回的是 @ 的位置（从 1 开始计数），而 SUBSTRING 的第三个参数是「要取多少个字符」，不是「取到第几个」。
正确写法是：
SELECT
CASE
WHEN CHARINDEX('@', ISNULL(email, '')) > 0
THEN SUBSTRING(email, CHARINDEX('@', email) + 1, LEN(email) - CHARINDEX('@', email))
ELSE NULL
END AS domain
FROM users;
关键点：
-
CHARINDEX('@', email) + 1是后缀起始位置（跳过 @） -
LEN(email) - CHARINDEX('@', email)是从 @ 到末尾的字符数（含 @ 自身占 1 位，所以减掉它就剩后面全部） - 这个长度值天然不会为负：只要
CHARINDEX > 0，LEN(email)必然 ≥ 它（否则 @ 不可能出现在字符串里）
用 PARSENAME 替代 CHARINDEX+LEN？不推荐用于邮箱
PARSENAME 是为解析四段式对象名（如 server.db.schema.table）设计的，它按 . 分割、逆序取段，且最多只认 4 段。拿它处理邮箱（如 name@sub.example.com）会出问题：
- 把
@替换成.再用PARSENAME(REPLACE(email, '@', '.'), 2)，看似能取域名，但一旦邮箱含多个.（如user@co.uk），PARSENAME会把co.uk拆成两段，取错 - 遇到
@后无内容（user@）或只有@domain，REPLACE后变成.domain，PARSENAME返回 NULL - 不处理 NULL 和空字符串，比
CHARINDEX版更脆弱
实际使用时最容易漏掉的边界：空格、大小写、国际化域名
真实数据里邮箱常带首尾空格，CHARINDEX 对空格敏感，' user@example.com ' 中 @ 位置不是 6 而是 7；而 LEN 会把空格算进去，导致截出来带尾部空格。
建议前置清洗：
- 统一用
RTRIM(LTRIM(email))去空格再处理 - 后缀本身不区分大小写，但
SUBSTRING结果保留原样；如需标准化，套一层LOWER() - 含 Unicode 字符（如中文邮箱）在 SQL Server 早期版本可能被截断，确保字段是
NVARCHAR类型，且字面量加N''前缀
复杂点不在函数组合，而在你永远不知道数据里藏了多少个没显式声明的空格和不可见字符。
