SQL 字符串处理关键在提前规划、精准截取、避免重复计算，核心是明确目标再选函数，优先保证可索引性，少用嵌套与模糊匹配，善用条件过滤和位置函数，并通过执行计划验证效率。
SQL 字符串处理不靠堆函数，关键在 提前规划 + 精准截取 + 避免重复计算。很多性能问题其实出在没想清楚“这串字符我真正需要什么”，而不是函数写得不够多。
明确目标再动刀：先想清楚要提取 / 判断 / 拼接什么
别一上来就套 TRIM、SUBSTRING、REPLACE。先问自己三个问题：
- 这个字段里“有效信息”到底在哪一段？是固定位置（如前 4 位年份），还是靠分隔符（如 邮箱 里的 @左边）？
- 是否所有数据都符合预期格式？有没有空值、异常长度、非法字符？
- 结果后续还要参与 JOIN 或 WHERE 过滤吗？那得优先保证可索引性（比如用 LEFT(name,1)=’ 张 ’ 比 SUBSTRING(name,1,1)=’ 张 ’ 更易走索引）
少用嵌套，多用 CASE WHEN + 简单函数组合
深层嵌套 SUBSTRING(INSTR(…))不仅难读，执行时还反复解析。换成结构化判断更稳：
- 提取手机号中间 4 位？用 SUBSTRING(phone, 4, 4) 比层层找 ’-‘ 或 ’ ‘ 快得多（前提是格式统一）
- 清洗地址含“省 / 市 / 区”？用CASE WHEN address LIKE ‘% 省 %’ THEN TRIM(REPLACE(address, ‘ 省 ’, ”)) ELSE address END
- 判断是否为邮箱？address LIKE ‘%_@__%.__%’比调用正则（如 MySQL 8.0+ REGEXP）轻量得多，够用就不升级复杂度
批量处理前先加条件过滤，别对全表硬刚字符串
字符串函数几乎都不走索引，WHERE 里直接写 UPPER(name) = ‘LISA’ 会让整列扫描。优化方法：
- 把转换逻辑挪到应用层或 ETL 预处理（比如入库时就存 lower_name 字段）
- 必须 SQL 内处理？先用确定性条件缩小范围：WHERE status = ‘active’ AND name IS NOT NULL，再套字符串操作
- MySQL 可建函数索引（8.0.13+）：CREATE INDEX idx_name_lower ON users ((LOWER(name)))，之后 WHERE LOWER(name)=’lisa’ 就能走索引
能用 CHARINDEX/INSTR 定位，就别用 LIKE 模糊扫
LIKE ‘% 关键词 %’ 是全表扫描黑洞。如果知道关键词大概位置，优先用位置函数锚定：
- 查“订单号末尾三位是 ABC”？RIGHT(order_no, 3) = ‘ABC’ 比 order_no LIKE ‘%ABC’ 快且明确
- 取“-”后的内容？SUBSTRING(code, CHARINDEX(‘-‘, code) + 1, LEN(code))（SQL Server）或SUBSTR(code, INSTR(code, ‘-‘) + 1)（MySQL）比用 SUBSTRING_INDEX 或多次 REPLACE 更直给
- 注意空值和找不到分隔符的情况，加上 AND CHARINDEX(‘-‘, code) > 0 防报错
基本上就这些。字符串处理不是炫技，而是用最短路径拿到确定结果。写完记得看下执行计划——如果出现“Compute Scalar”占比高，或者“Table Scan”没被过滤掉，那就该回头看看是不是目标没理清，或者函数用重了。
