SQL括号取反通配符正确语法及跨数据库、访问技术适配咨询

这类通配符的规则完全由当前数据连接启用的SQL兼容模式决定，和使用的访问技术类型没有直接绑定关系，这也是官方文档出现内容矛盾的核心原因：

• ANSI-89兼容模式（Jet 3.x 时代的Access默认旧模式）：取反通配符为!，写法如[!a-e]，代表匹配a、b、c、d、e范围之外的任意单个字符。该模式下配套的其他通配符为*（匹配任意长度任意字符）、?（匹配单个任意字符）、#（匹配单个数字）。
• ANSI-92兼容模式（Jet 4.0开始新增的、对齐主流SQL标准的模式）：取反通配符为^，写法如[^a-e]，代表匹配a-e范围之外的任意单个字符。该模式下配套的其他通配符为%（匹配任意长度任意字符）、_（匹配单个任意字符），和主流SQL数据库的通配符规则保持一致。

关于文档错配的问题：W3Schools、MSDN出现“文字说明要求用^、相邻示例用!”的矛盾，本质是页面把两种兼容模式的内容混排了——Access的ACE/Jet引擎从Jet 4.0版本开始就同时内置支持两种兼容模式，但文档编写时没有把示例和对应的兼容模式做明确标注，才造成了表述歧义。
针对ODBC连接Access的实操场景，不要完全依赖文档说明判断规则，可以直接跑一条极简测试SQL确认当前连接的实际规则：SELECT '[^a]' LIKE 'b' AS match_test

• 如果返回值为True，说明当前连接启用的是ANSI-92模式，取反需要写^
• 如果返回值为False，说明当前连接启用的是ANSI-89模式，取反需要写!
  注意：ODBC驱动、OleDB提供程序的兼容模式有时候会自动继承Access数据库文件本身的默认设置，不是靠连接字符串参数完全强制切换的，直接测试是最可靠的判断方式。

不存在可以在所有场景通用的固定写法，原因是“方括号内范围取反的通配符匹配”本身就不是ANSI SQL强制要求的核心语法，不同数据库的实现差异极大：

• Access生态（用DAO、ODBC、OleDB访问Jet/ACE引擎）：规则完全跟随当前连接的兼容模式，和用哪种访问技术无关，同一段SQL换个兼容模式就会直接匹配失效。
• MySQL：本身在LIKE子句里就不支持方括号范围匹配的语法，哪怕照搬ANSI-92的[^a-e]写法也无法识别。如果要实现同样的范围取反效果，需要借助MySQL的内置正则匹配函数，对应的语法结构和标准LIKE语句完全不兼容。
• 其他主流数据库（SQL Server、PostgreSQL、SQLite等）：虽然部分数据库支持[^a-e]形式的取反匹配，但支持边界差异很大——比如SQLite在普通LIKE子句里默认不识别方括号语法，需要开启特殊的编译开关才能生效；PostgreSQL只有在SIMILAR TO语法或者正则操作符中才支持这类方括号规则，普通LIKE子句完全不生效。

如果需要写可以在多数据库间通用的匹配逻辑，不要依赖这类非标准的特殊通配符，替换为完全符合ANSI SQL标准的显式判断逻辑（比如用NOT (target_col BETWEEN 'a' AND 'e')实现范围排除），才能从根本上避免不同环境带来的语法兼容问题。

内容的提问来源于stack exchange，提问作者AlainD