查不到明明存在的数据主因是char字段右侧自动补空格导致精确匹配失败，如'5'存为'5 '，使'5 '≠'5'；需用length/dump/hex验证字节、trim临时修复或改varchar2根治。
查不到明明存在的数据，99%不是SQL写错了，而是数据本身“看起来一样，实际不同”——尤其是字段类型为 CHAR 时右侧自动补空格，导致 = 精确匹配失败。
CHAR 字段的隐式空格陷阱
CHAR(n) 类型会把值强制填充到 n 位长度，不足部分在右侧补空格。比如存 '5' 到 CHAR(2) 字段，实际存的是 '5 '（带一个空格）。用 WHERE col = '5' 查不到，因为数据库比对的是 '5 ' ≠ '5'。
- 验证方法：用
LENGTH(col)和DUMP(col)（Oracle）或HEX(col)（MySQL）看真实字节 - 临时修复：查询时用
WHERE TRIM(col) = '5'或WHERE col LIKE '5%'（不推荐长期用） - 根治方案：把字段改为
VARCHAR（或VARCHAR2），再用UPDATE SET col = TRIM(col)清洗存量数据
大小写与引号导致的表/列名不可见
在 Oracle 中，如果建表时用了双引号（如 CREATE TABLE "myTable"），表名就变成大小写敏感的。后续查询必须写成 SELECT * FROM "myTable"，否则 SELECT * FROM mytable 或 SELECT * FROM MYTABLE 都查不到。
- 检查是否存在：
SELECT table_name FROM user_tables，注意返回的表名大小写 - 列名同理：如果
CREATE TABLE t ("Id" INT)，查询必须写SELECT "Id" FROM t - PostgreSQL 同样遵循该规则；MySQL 默认不区分，但开启
lower_case_table_names=0时也会触发类似行为
数据类型隐式转换失败
当 WHERE 条件中字符串和数值混用，比如 WHERE id = '123 '（带空格）对比 INT 字段，MySQL 可能截断后转成 123，但 Oracle 会直接报错或返回空——取决于字段类型和 NLS 设置。
- 典型现象：
SELECT * FROM orders WHERE order_no = 'A001 '查不到，而SELECT * FROM orders WHERE order_no = 'A001'可以 - 安全写法：始终确保比较双方类型一致，字符串字段就用字符串条件，数值字段就用数值条件
- 排查技巧：用
SELECT DUMP(order_no), order_no FROM orders WHERE ROWNUM 看原始字节构成
事务未提交或隔离级别影响
你在自己的会话插入了数据但没 COMMIT，其他会话默认看不到；或者用了 READ UNCOMMITTED 以外的隔离级别，又没刷新连接，就可能“确定有数据却查不到”。
- 开发环境常见：用 Navicat 执行 INSERT 后没点“提交”，换一个查询窗口就查不到
- 确认是否提交：
SELECT COUNT(*) FROM table_name在同一会话执行，结果和另一会话不一致 → 基本就是事务问题 - 临时绕过（仅调试）：
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED（慎用，可能读到脏数据）
最常被忽略的是 CHAR 补空格和大小写引号这两个点——它们不会报错，也不提示，只是安静地返回空结果。动手前先 DUMP 或 HEX 一眼，比反复改 SQL 有效得多。
