LIKE查询带空格字符串查不到，因空格是普通字符需显式写出（如'%John Doe%'），且CHAR字段会补空、数据可能含不可见空格，应TRIM或用正则处理。
LIKE查询带空格的字符串为什么查不到
空格在SQL里是合法字符，但容易被误当成无意义的前后缀被忽略。比如WHERE name LIKE 'John%'查不到'John Doe'，因为%只匹配任意长度字符，但不会“跳过”中间空格去匹配后半段——它本来就要完整匹配模式。真正的问题常出在数据两端有不可见空格（如CHAR类型补空、导入时多出的CHR(32)），或模式本身没把空格写进去。
- 用
TRIM()先清理再查：WHERE TRIM(name) = 'John Doe'，适合精确匹配 - 想模糊查含空格的子串，必须显式写出空格：
WHERE name LIKE '%John Doe%'，不能写成'%John%Doe%' -
CHAR字段要特别小心：它会用空格填满长度，name = 'John'可能匹配到'John '（两个空格），此时LIKE 'John%'能命中，但= 'John'在某些数据库（如PostgreSQL）里不等价
下划线_和百分号%在空格场景下的陷阱
_代表单个任意字符，%代表零或多个任意字符——它们都**不特殊处理空格**，空格就是普通字符。所以'a_b'能匹配'a b'（中间是空格），但'a%b'不能跨多个空格“跳”过去；如果字段值是'a b'（两个空格），'a%b'可以匹配，但'a_b'不行。
- 测试空格是否真实存在：
SELECT name, LENGTH(name), LENGTH(TRIM(name)) FROM users WHERE name LIKE '%John%';，看长度差是否为0 - 避免用
_代替空格：写'John_Doe'意图匹配'John Doe'是错的，应写'John Doe'或'John% Doe' - MySQL中
LIKE默认不区分末尾空格，'abc' = 'abc '为TRUE；但PostgreSQL严格区分，'abc' = 'abc '为FALSE
用正则替代LIKE处理复杂空格模式
当需要匹配“一个或多个空格”“开头/结尾空格”“非空格分隔的单词”时，LIKE表达力不够，该切正则。各数据库支持程度不同，但核心思路一致：把空格当作需显式声明的字符类。
- PostgreSQL用
~操作符：WHERE name ~ '^John\s+Doe$'（\s+匹配一个以上空白符） - MySQL 8.0+ 支持
REGEXP：WHERE name REGEXP '^John[[:space:]]+Doe$'，注意[[:space:]]比\s更兼容 - SQLite不原生支持正则，得靠扩展或应用层处理；别硬套
LIKE模拟，比如用name LIKE 'John % Doe'查两个单词间恰好一个空格，既难读又漏情况
CHAR vs VARCHAR对空格行为的实际影响
这是最容易被忽略的底层差异。定义为CHAR(10)的列存'abc'，实际存储的是'abc '（7个空格补足）。而VARCHAR(10)存'abc'就是纯'abc'。这直接决定LIKE、=、索引查找的行为是否符合直觉。
- 用
SHOW CREATE TABLE确认字段类型，别只看表结构文档 -
CHAR字段做LIKE时，'abc%'能匹配'abc'（补空后变成'abc '，满足前缀）；但WHERE name = 'abc '在MySQL里也能命中，因为比较前会右补空 - 业务上只要不强制定长，一律用
VARCHAR；历史CHAR字段迁移时，用CAST(name AS VARCHAR)或TRIM(name)再查，别依赖隐式补空逻辑
空格不是“看不见就不存在”，而是数据库里最常被类型、函数、比较规则悄悄修改的字符。查之前先SELECT DUMP(name)（Oracle）或ENCODE(name::bytea, 'escape')（PostgreSQL）看看真实字节，比猜快得多。
