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”没被过滤掉，那就该回头看看是不是目标没理清，或者函数用重了。
