SQL字符串处理关键在于性能优化：避免WHERE中对字段用函数导致索引失效，优先在存储时清洗、用前缀匹配、全文索引或函数索引，批量操作用内置拆分函数而非循环。
SQL字符串处理不是拼凑函数，关键是理解数据特征、避免隐式转换、减少运行时计算。写得“对”不如写得“快且稳”，尤其在大表上，一个SUBSTRING嵌套可能拖慢整个查询。
用好索引，别让字符串函数毁掉性能
WHERE条件里对字段用UPPER()、TRIM()、SUBSTRING()等函数，数据库通常无法走索引——因为索引存的是原始值，不是函数结果。比如：
❌ 慢（索引失效）：
SELECT * FROM users WHERE UPPER(name) = 'LISA';
✅ 快（索引可用）：
SELECT * FROM users WHERE name = 'lisa' OR name = 'LISA';
或更稳妥地，在业务层统一存小写，查时直接用WHERE name = 'lisa'。
如果必须大小写不敏感匹配，优先考虑：
• MySQL：用COLLATE utf8mb4_unicode_ci的列（建表时设好）；
• PostgreSQL：用ILIKE 或 LOWER(col) = LOWER(?) 并给LOWER(col)建函数索引；
• SQL Server：用带CI（Case-Insensitive）排序规则的列，或建计算列索引。
批量截取/拆分，别用循环模拟
想把逗号分隔的'a,b,c'拆成多行？别写存储过程循环+临时表。现代SQL有更高效方式：
- PostgreSQL：直接用string_to_array() + UNNEST()
- MySQL 8.0+：用JSON_TABLE()把字符串转JSON再展开
- SQL Server：用STRING_SPLIT()（2016+），返回表结果，可JOIN
- 通用兜底法：用递归CTE生成数字序列，配合SUBSTRING_INDEX（MySQL）或SUBSTRING+CHARINDEX（SQL Server）逐段提取
核心原则：一次生成结果集，别一行一行查。
替换与清洗，提前做比查时做更省
像清理电话号中的'-'、'('、空格，或标准化邮箱大小写，别总在SELECT里用REPLACE()、LOWER()——这些是每行必算的开销。
更优做法：
• ETL阶段或INSERT/UPDATE触发器中清洗并存入规范字段（如phone_clean、email_lower）；
• 对清洗字段建索引，后续查询直用，零函数开销；
• 若只能查时处理，至少把常量替换合并，比如：
REPLACE(REPLACE(REPLACE(phone, '-', ''), '(', ''), ' ', '')
不如用正则（若支持）：
REGEXP_REPLACE(phone, '[\-\(\)\s]', '')（MySQL 8.0+/PostgreSQL）
模糊匹配，少用%开头，多用全文或前缀索引
WHERE name LIKE '%son' 或 '%li%' 几乎必然全表扫描。解决思路分三层：
- 能用前缀就不用通配：如查姓氏WHERE name LIKE 'Li%'，可走B-tree索引
- 高频模糊需求，建倒排或全文索引：MySQL用FULLTEXT，PostgreSQL用tsvector + @@操作符
- 近似匹配（如拼错校验）：用LEVENSHTEIN()（PostgreSQL需扩展）、SOUNDEX()或DIFFERENCE()（SQL Server），但务必加WHERE缩小范围后再算
基本上就这些。字符串处理本身不复杂，容易忽略的是它和索引、执行计划、数据生命周期的咬合点。写之前多问一句：这个函数，是在过滤前还是过滤后执行？值会不会变？有没有更早清洗的机会？
