SQL字符串处理需坚持安全、可读、高效原则，重点防范硬拼接、忽略NULL、盲目用函数三类误区；必须显式处理NULL（如COALESCE）、动态值严格参数化、优先使用索引友好写法。
SQL字符串处理没有统一“标准流程”，但有一套被广泛验证的安全、可读、高效实践原则。关键不是套模板，而是理解每一步的目的和风险点——尤其要避开硬拼接、忽略空值、盲目用函数这三类高频误区。
明确目标再选函数，不为用而用
字符串操作必须先问：是要清洗？拼接？提取？还是判断？不同目标对应不同策略：
- 拼接字段（如姓名+部门）：优先用 CONCAT()（MySQL/PostgreSQL）或 ||（PostgreSQL/Oracle），避免用 +（SQL Server虽支持，但遇NULL会整体变NULL）
- 提取子串（如取邮箱域名）：用 SUBSTRING() + POSITION() 或 STRPOS() 定位，别依赖固定长度切片
- 模糊匹配前缀：用 LIKE 'abc%'，别写成 LEFT(col, 3) = 'abc'（无法走索引）
NULL必须显式处理，不能假装它不存在
SQL中任何含NULL的字符串运算结果几乎都是NULL，这是最常被忽视的“静默失败”：
- CONCAT('a', NULL, 'b') → 'ab'（MySQL/PostgreSQL自动跳过NULL）
- 'a' || NULL || 'b' → NULL（PostgreSQL/Oracle严格模式）
- 统一做法：COALESCE(col, '') 替换NULL为空字符串，再参与运算
- 条件判断时别写 WHERE name != 'admin'，漏掉NULL；应补上 OR name IS NULL 或用 WHERE COALESCE(name, '') != 'admin'
拼接动态值必须参数化，禁用字符串拼接SQL
用户输入直接拼进SQL是SQL注入温床，哪怕只是字符串：
- ❌ 错误："SELECT * FROM user WHERE name = '" + inputName + "'"（PHP/Java等应用层）
- ✅ 正确：用预编译参数占位符，如 "SELECT * FROM user WHERE name = ?"（JDBC）或 "WHERE name = $1"（PostgreSQL）
- 若必须动态列名或表名（极少见）：只能白名单校验 + 严格正则匹配（如
^[a-zA-Z_][a-zA-Z0-9_]*$），绝不用用户原始输入
性能敏感场景，提前剪枝比事后过滤更有效
字符串函数通常无法利用索引，应尽量把可索引条件放在WHERE最前面：
- 低效：WHERE UPPER(name) = 'JOHN'（全表计算UPPER）
- 高效：WHERE name IN ('JOHN', 'john', 'John') 或建函数索引（如 PostgreSQL
CREATE INDEX idx_name_upper ON user (UPPER(name))） - 模糊搜索优化：WHERE name LIKE 'Li%' 可走索引；WHERE name LIKE '%Li%' 不行，考虑全文检索或前置生成拼音字段
基本上就这些。不复杂但容易忽略——重点盯住NULL、参数化、索引友好这三点，字符串处理就能稳住底线。
