mysql 8.0+ 过滤含特殊符号数据应使用 where col not regexp '[^a-za-z0-9]'，并补 and col is not null；sql server 用 patindex('%[^a-za-z0-9]%', col) = 0 and col is not null；postgresql 用 col !~ '[^a-za-z0-9]' and col != ''。
MySQL 8.0+ 用 REGEXP 判断是否含非字母数字字符
想过滤掉含特殊符号的记录，核心是「匹配到任意一个非字母数字字符就排除」。直接写 WHERE col REGEXP '[^a-zA-Z0-9]' 就能找出所有含特殊字符的行；反过来，WHERE col NOT REGEXP '[^a-zA-Z0-9]' 才是真正过滤掉它们的写法。
常见错误有三个：
– 漏掉 NOT，结果反而查出脏数据
– 写成 [^a-z]，大写字母和数字全被当成“特殊字符”误杀
– 忘加 AND col IS NOT NULL，NULL 值在 REGEXP 下返回 NULL，整行被 WHERE 当作 false 过滤掉
如果字段可能含前后空格或制表符（CHAR(9)）、换行（CHAR(10)）、回车（CHAR(13)），得先 TRIM() 或嵌套 REPLACE()，否则 ' abc ' 会因空格不通过正则校验。
SQL Server 用 PATINDEX 替代正则判断位置
PATINDEX 不是正则引擎，但能模拟简单字符类匹配，适合老版本或不能开正则权限的环境。判断字段是否含特殊字符，用 PATINDEX('%[^a-zA-Z0-9]%', col) > 0；过滤掉它们，就写成：
WHERE PATINDEX('%[^a-zA-Z0-9]%', col) = 0 AND col IS NOT NULL
注意点：
– % 是通配符，不是正则语法，所以 [^a-zA-Z0-9] 在这里合法
– 排序规则影响大小写敏感性，Latin1_General_CI_AS 下 [^a-z] 也能匹配大写字母，但不可靠，仍建议写全范围
– 中文、emoji、全角字符全落在 [^a-zA-Z0-9] 范围内，会被一并过滤，这点和预期一致
PostgreSQL 用 ~ 和 !~ 操作符更轻量
PostgreSQL 原生支持 POSIX 正则，~ 表示匹配子串，!~ 表示不匹配子串。过滤含特殊字符的记录，直接写：
WHERE col !~ '[^a-zA-Z0-9]'
但要注意：
– 空字符串 '' 对 !~ '[^a-z]' 返回 true，但它显然不满足“纯字母数字”，所以生产环境必须补上 AND col != ''
– 若需严格限定“整个字段只能是字母数字”，应锚定首尾：col ~ '^[a-zA-Z0-9]+$'，避免 'abc123def' 这类混合值漏过
– \d 在 PostgreSQL 中等价于 [0-9]，不匹配 Unicode 数字，行为比想象中更干净
不支持正则的老数据库用 REPLACE 嵌套或 TRANSLATE
Oracle 10g、SQL Server 2016 及更早版本不支持正则时，只能靠字符替换硬刚。思路是：把所有合法字符（a-z、A-Z、0-9）替换成空，再看结果是否为空字符串。
PostgreSQL / Oracle 示例：WHERE TRANSLATE(col, 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789', '') = ''
SQL Server（2017+）可用 TRANSLATE 配合 REPLACE：WHERE REPLACE(TRANSLATE(col, '!@#$%^&*()', '__________'), '_', '') = col —— 这种写法本质是“若替换前后不变，说明原字段不含这些符号”
缺点很明显：
– 字符列表越长，语句越难维护
– TRANSLATE(NULL, ...) 返回 NULL，需额外处理空值
– 无法覆盖动态变化的“特殊字符”定义，比如某业务要求保留中文，那就得重写整个逻辑
最易被忽略的是隐藏控制字符：即使肉眼看着是干净的字符串，也可能混着 CHAR(9)、CHAR(10)、CHAR(13)。这类字符不会被 [^a-zA-Z0-9] 捕获（因为它们 ASCII 值不在该范围内），但会导致后续应用解析失败。真要兜底，得在正则前先做三重 REPLACE 清洗。
