MySQL中排除含数字字符串应使用WHERE col NOT REGEXP '[0-9]'，因REGEXP默认部分匹配且不区分大小写；误加+或混淆RLIKE语法是常见错误。
MySQL中用REGEXP排除含数字的字符串
MySQL 8.0+ 支持标准正则，直接用 NOT column_name REGEXP '[0-9]' 即可过滤掉任意位置含数字的字符串。注意：MySQL 的 REGEXP 默认是“匹配即真”，所以必须加 NOT；另外它不区分大小写，且自动锚定（无需写 ^ 和 $）。
常见错误是写成 column_name NOT REGEXP '[0-9]+' ——量词 + 在这里多余，[0-9] 本身已能匹配至少一个数字；更隐蔽的坑是误用 RLIKE 当作独立函数（其实它是 REGEXP 的同义词，不能加括号调用）。
- 正确写法：
WHERE name NOT REGEXP '[0-9]' - 想严格匹配纯字母（不含空格、符号）？用
WHERE name REGEXP '^[a-zA-Z]+$' - 兼容旧版 MySQL（LIKE 组合（如
NOT (name LIKE '%0%' OR name LIKE '%1%' ...)），但最多只适合枚举少量数字
PostgreSQL里用~和!~操作符
PostgreSQL 不用函数调用形式，而是用中缀操作符：!~ 表示“不匹配正则”。要排除含数字的字符串，写 WHERE column_name !~ '[0-9]' 就行。注意它默认区分大小写，且不自动锚定——也就是说 'abc123def' !~ '[0-9]' 会返回 false（因为确实匹配到了数字），符合预期。
容易忽略的是转义问题：如果正则里要匹配反斜杠或点号等，得写双反斜杠（'\\.'），但数字类字符无需额外转义。另外，!~* 是不区分大小写的版本，对数字无效，但若后续扩展为匹配字母就可能用上。
- 推荐写法：
WHERE tag !~ '[0-9]' - 想排除含数字或下划线的？用
WHERE tag !~ '[0-9_]' - 性能提示：正则匹配无法走普通 B-tree 索引，若字段很大且查询频繁，考虑增加生成列 + 索引（如
ALTER TABLE t ADD COLUMN has_digit BOOLEAN GENERATED ALWAYS AS (tag ~ '[0-9]') STORED）
SQLite 中没有原生REGEXP，必须启用扩展或换思路
SQLite 默认不带正则函数，直接写 WHERE name NOT REGEXP '[0-9]' 会报错 no such function: REGEXP。除非你手动编译启用了 SQLITE_ENABLE_REGEXP，或在运行时加载了 regexp 扩展（如 Python 的 sqlite3 模块可通过 create_function 注入 Python 正则逻辑）。
更现实的做法是避开正则：用 INSTR() 配合多个 AND 判断，例如 WHERE INSTR(name, '0') = 0 AND INSTR(name, '1') = 0 AND ... AND INSTR(name, '9') = 0。虽然啰嗦，但兼容所有 SQLite 版本，且能利用索引（如果字段有索引且查询条件足够简单）。
- 最小可行方案：
WHERE INSTR(name, '0') = 0 AND INSTR(name, '1') = 0 AND INSTR(name, '2') = 0（依需补全到 9） - Python 中临时注入正则：
conn.create_function("REGEXP", 2, lambda x, y: bool(re.search(x, y)))，之后就能用WHERE name NOT REGEXP '[0-9]' - 注意：SQLite 的
INSTR区分大小写，但数字无此问题；该函数返回 0 表示未找到，正好用于排除
正则写法看似简单，但跨数据库移植时参数和语义差异极大
同一个需求，在 MySQL、PostgreSQL、SQLite 甚至 SQL Server（需用 PATINDEX）里实现方式完全不同。别指望写一次正则到处跑——[0-9] 虽然通用，但锚定行为、是否默认贪婪、空字符串处理、NULL 值响应都可能不同。比如 PostgreSQL 中 NULL !~ '[0-9]' 返回 NULL（即该行被过滤掉），而 MySQL 中 NULL NOT REGEXP '[0-9]' 也是 NULL，结果一样，但逻辑路径不同。
真正容易被忽略的是边界情况：空字符串 ''、全是空白的字符串、含 Unicode 数字（如阿拉伯数字 ١٢٣）——标准 [0-9] 对后者完全无效。如果业务涉及多语言，得换成 p{Nd}（PCRE）或数据库支持的 Unicode 属性类，但这又进一步降低兼容性。
