企业官网建设流程全解析

项目标题: 关于pg库查询结果在结果集中找不到的原因

前两天有个读者跑来问我，说他在pg库里明明能查到数据，SQL单独跑也有结果返回，但程序代码里一遍历结果集就是空的，折腾了一整天也没想明白，怀疑是不是pg库有什么反人类的配置。我跟他聊了几句，发现这个问题的典型程度超乎想象。不管你是用JDBC直接写原生查询，还是用MyBatis、Hibernate这类ORM框架，只要跟pg库打交道，“查询结果在结果集中找不到”这个现象背后的原因，基本都逃不过那几类。这篇文章我就把这些年排查过的坑集中梳理一遍，从结果集游标、事务可见性、schema路径、数据类型到Navicat建库细节，一条一条拆开讲清楚，希望能帮你少走点弯路。

既然是讲“结果集找不到结果”，我们得先把“结果集”这个词放在具体语境里看。在数据库开发里，结果集通常是指应用程序执行SQL之后拿到的那个数据集合，在Java里叫ResultSet，在MyBatis里对应List ，在Python的psycopg2里是cursor.fetchall()的返回值。你的SQL在Navicat、pgAdmin或者psql里能查到数据，不代表程序里一定能取到，这个“能查到”和“取不到”之间的落差，就是问题所在。

1. 先弄清楚：你是在哪里没找到结果

很多朋友一上来就怀疑是SQL写法问题，但实际排查下来，大部分情况是“数据没走到结果集”而不是“SQL没查出数据”。所以第一步，你先要搞清楚自己到底属于哪一种表现。

1.1 三种典型现象，对应三种排查方向

我把这类问题的表象分成三类，你可以对号入座。

第一类：直接在Navicat或psql里执行查询，能返回N行数据，但代码里遍历结果集一行都拿不到。这种问题大概率出在结果集游标的位置、JDBC驱动的取值方式，或者ORM映射的字段名对不上，跟SQL本身没多大关系。

第二类：数据库里确确实实有数据，但你的SQL执行后返回0行。这种情况就得回头看SQL的过滤条件、表名schema前缀、字段大小写，以及你在Navicat里建库建表时选的owner和schema是不是跟程序用的账号一致。

第三类：同一个查询函数，第一次调用有结果，第二次调用没结果，或者在不同环境里一个能查到、一个查不到。这种间歇性问题，优先怀疑事务隔离级别、连接池复用、未提交事务和查询超时这些动态因素。

1.2 先复现，再定位，别急着改代码

我的习惯是，遇到“结果集为空”先不要动手改代码，而是把现场完整复现一遍。具体就是：用数据库客户端手动执行程序里那条SQL，确认是否能查到；再在程序里打印出真正发送给数据库的完整SQL和参数列表，如果发现跟手动执行的SQL不一样，那问题就已经暴露一半了。很多时候，你手动执行的是SELECT * FROM user WHERE id = 1，程序里因为拼接漏了个参数，实际执行的是SELECT * FROM user WHERE id = NULL，这种差异不对比日志根本看不出来。

还有一个容易被忽略的点：你的SQL带了过滤条件，但字段值是NULL或者空字符串，肉眼看着“有数据”，实际上条件匹配不上。这一点在后面数据类型章节会详细讲。

2. 最容易踩的坑：结果集游标与取值方式

如果说“结果集找不到结果”有十个坑，那JDBC游标位置这一个坑至少占三个。Java的ResultSet设计跟直觉不太一样，它刚刚创建的时候，内部指针并不指向第一行数据，而是停在第一行之前的位置。

2.1 明明有数据却取不到：必须先调用next()

理解不了这一点，你就很容易写出下面这种“看起来没问题”的代码：

Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("SELECT id, name FROM users WHERE id = 1"); String name = rs.getString("name"); // 这里报错或者返回空

这段代码在pg JDBC驱动下，大概率会抛出“ResultSet not positioned properly”异常，而不是安静地返回null。因为游标还没有移动到第一行，你根本没资格取数据。正确写法应该是：

if (rs.next()) { String name = rs.getString("name"); }

如果你用的是while (rs.next())循环遍历，也要注意循环体里不要再调用一次rs.next()。我见过有人写这种代码：

while (rs.next()) { rs.next(); // 本来想跳过空行，结果跳过了真正有数据的那一行 String name = rs.getString("name"); }

这种写法会让游标一次性前进两行，如果结果集恰好有奇数行，最后一行的数据就丢失了。你会觉得“结果集少了一条数据”，但实际是游标被你自己手动跳过了。

2.2 只取第一行和取不到行：if和while的差别

还有一类经典问题：同一段查询，用if (rs.next())能取到第一行，用while (rs.next())却一行都取不到。这种情况说明逻辑本身可能没有严格按照游标位置来控制，比如你在循环体内做了resultSet.close()，或者把statement也关了。pg JDBC驱动里，关闭Statement后，它生成的ResultSet也会跟着失效，此时再去取数据就会得到空结果，甚至直接抛异常。

另外，pg JDBC的ResultSet默认是TYPE_FORWARD_ONLY的，只能向前滚动，不能通过rs.previous()往回翻。如果你在一个方法里读一遍结果集做判断，然后在同一个方法里又想再读一遍做填充，第二遍就会拿不到东西。解决办法是把数据先复制到List里，或者用可滚动的ResultSet，就像这样：

Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);

2.3 ORM框架里也要注意映射和类型转换

用了MyBatis或者Hibernate之后，很多人以为游标问题不存在了，其实只是换了一种形式。MyBatis中，如果数据库字段是user_name，而实体类是userName，没有开启驼峰映射，那你查出来的对象的userName就是null，看起来像是“没找到结果”。更隐蔽的是pg的布尔类型，pg里存的是t/f，JDBC驱动能正常映射成Boolean，但如果你用了某些老的驱动版本，或者字段类型是varchar但值全是'true'/'false'字符串，MyBatis的BooleanTypeHandler不一定处理得了，结果就是查出来一条记录，但字段全是默认值。

Hibernate同样有类似的点：如果实体类字段跟数据库列名对不上，配置了错误的@Column(name)，查询结果是能返回的，但每个字段都是null。如果你在Service层做空值判断，就会认为“结果集里没有有效数据”，其实数据一条不少，只是映射丢了。

3. 数据明明存在，为什么读不到：事务可见性与隔离级别

接下来聊一个经常让人崩溃的场景：你在Navicat里插入了一条数据，屏幕上都看到记录了，然后切到程序里一查，结果集是空的。于是你怀疑是代码写错了，反复调试半天，结果发现是刚才那条INSERT没有提交。

3.1 PostgreSQ L默认的读已提交级别

PostgreSQL默认的事务隔离级别是READ COMMITTED，在这个级别下，一个事务只能看到已经提交的数据。如果你在Navicat里执行了INSERT，但没有点提交按钮，或者你用的命令行连接里手动BEGIN了事务却没COMMIT，那么这条数据对当前连接是可见的，对其他连接是不可见的。程序刚好用的是另一个连接，自然查不到。

有个更隐蔽的场景：Navicat里执行DML语句后，如果事务一直挂着没提交，你切换到程序这边怎么查都为空，但你在Navicat里看数据又是好的，这种“自己看得到，别人看不到”的现象，几乎可以锁定是未提交事务。

3.2 连接池和事务边界的坑

生产环境里用的都是连接池，事务边界一旦没控制好，问题会被放大。典型例子：一个公共服务把写操作和读操作放在同一个方法里，表面看是同一个事务，但事务管理器配置成了REQUIRES_NEW，导致查询走的是另一个新事务，新事务自然看不到还没提交的修改。反过来，如果事务配置成REQUIRED，但被调用的方法在另一个Service里，事务传播行为没配对，也可能出现提交时机晚于查询时机的情况。

如果你用的是Spring + MyBatis，最常见的翻车现场是：Service方法上没有加@Transactional，但是Mapper方法里直接调用了update操作和select操作，MyBatis默认autocommit是true，update执行完就提交了，select按理说能看到。但一旦你手动给某个Mapper方法加了@Transactional却忘了提交，当前线程内的连接事务一直开着，后续查询如果不走同一个连接，就看不到这条数据。

我之前排查过一个问题：程序里明明调用了insert，日志里也打印出了insert成功的返回值，但紧接着的select查询却返回空结果。后来查了半天，发现是AOP切面给这个方法包了一个事务，事务在方法返回后才提交，而方法内部自己又开了一个新连接去查询。那个新连接在READ COMMITTED级别下，看不到原连接事务里还没提交的数据。

3.3 不同隔离级别下的一致性表现

PostgreSQL支持的四种隔离级别，读已提交（Read Committed）、可重复读（Repeatable Read）、可串行化（Serializable）、以及读未提交（Read Uncommitted，在pg里实际行为等同于读已提交）。其中最需要注意的是，如果你把隔离级别调成REPEATABLE READ，事务内的第一次查询会建一个快照，之后这个事务内所有查询都基于这个快照。就算其他连接提交了新数据，当前事务也看不到。这在报表场景里很常见：同一个事务里先查一次总条数，然后逐页查询，结果发现某一页少了数据，因为快照时间点的数据确实没有这一条。

遇到这种情况，先检查连接参数或事务管理里的isolation配置。很多连接池默认会保持一个隔离级别，如果应用之前改过，池里的连接带着旧的隔离级别配置被复用，后续查询结果就会表现得“时有时无”。

4. PostgreSQL专属陷阱：schema、search_path与大小写

如果说前面的问题是所有数据库通用的，那这一节就是pg库最容易坑人的地方。PG的schema机制、search_path搜索路径和标识符大小写折叠规则，对从MySQL转过来的同学来说，真的是“不踩不知道，一踩吓一跳”。

4.1 表不在public schema下，程序当然查不到

PG里每个数据库下面可以有多个schema，默认有一个叫public的schema。如果你在Navicat里新建了一个数据库，但选项里没注意默认的schema，或者建表时选了一个自定义schema，那表面上看表名字还在，但程序连接用的是另一个用户，默认的search_path可能只包含public和用户同名schema，结果就是查不到表。更麻烦的是，如果表确实存在但不在search_path里，执行SELECT时会直接报“relation does not exist”，但很多时候你用了ORM框架，报错被吞掉了，最终表现出来就是“查询结果为空”。

判断方法很简单，在Navicat的查询工具里执行：

SHOW search_path;

如果返回的结果里没有包含你建表的那个schema（比如myschema），那程序执行SELECT时也走不到那张表。你可以手动修改当前会话的search_path：

SET search_path TO myschema, public;

但要注意，这只是改当前会话，程序里每次新建连接都是默认值。最好的做法是在连接串上显式指定，JDBC的话是：

jdbc:postgresql://localhost:5432/mydb?currentSchema=myschema

或者在程序代码里定期执行SET search_path。另外还有一点：PostgreSQL里每个用户都会默认创建一个跟用户名同名的schema，如果建表时owner是A用户，而程序连接的是B用户，B用户默认搜索路径里是B同名schema，不是public也不是A的schema，同样会查不到。

4.2 双引号和大小写被忽略，导致字段名对不上

PG的标识符规则跟MySQL差异很大：不带双引号的表名和字段名，会被自动折叠成小写。也就是说，你在Navicat里写CREATE TABLE UserInfo，实际创建的表名是userinfo；你写SELECT * FROM "UserInfo"，才能查到那张“看起来大写”的表。但很多时候，程序里配置的SQL是从别的地方拷来的，带着双引号，而表是Navicat可视化建表建的，名字又是小写，两边一对不上，结果集自然就找不到字段名。

最典型的翻车现场是更新换代的老系统：表字段叫"userName"（带双引号建的），你在程序里写SELECT user_name，查询结果里字段名是user_name，实体类里却用userName去get，拿不到。这种情况不是数据没查出来，而是字段名映射失败。我建议你直接查一下information_schema：

SELECT table_schema, table_name, column_name FROM information_schema.columns WHERE table_name = 'users';

看看真实的字段名到底是user_name还是userName，然后统一程序里的大小写和映射。

4.3 search_path不同导致同一条SQL在不同环境结果不一样

还有一个很容易踩的坑：同一个SQL，在Navicat里查得到，在程序里查不到，原因可能是两个连接的用户不一样，search_path不一样。Navicat连接时，用的是你在连接配置里填的用户，如果这个用户是超级用户或者owner，他的search_path默认是"$user", public，能访问public和同名schema；但程序配的账号可能只有public权限，或者根本没有访问那个schema的权限。权限不足时PG有时候不报错而是返回空结果，比如你查询某个视图，视图内部引用了一张你没权限的表，PG会直接告诉你查询不到。这种情况要从授权入手，给程序账号加上对应schema的USAGE权限和表的SELECT权限，而不是硬改SQL。

5. SQL写法和数据类型导致的“空结果”

很多时候，你能看到表里有数据，但SQL执行结果确实为空。这种“看得见摸不着”的体验，往往根因在SQL写法与PG数据类型的配合上。

5.1 NULL值、空字符串和布尔字段

PG里NULL和空字符串是两种完全不同的东西。如果你在业务表里把“未填写”存成了NULL，然后程序里查WHERE remark = ''，那结果集一定是空的。反过来，如果存的空字符串，查WHERE remark IS NULL，同样也查不出来。排查时一定要确认字段的真实值，用下面的SQL扫一眼：

SELECT id, remark, remark IS NULL AS is_null, remark = '' AS is_empty FROM users LIMIT 10;

另一个常见坑是PG的布尔类型。PG里布尔值可以是TRUE、FALSE、NULL三种状态，很多人写查询时只考虑两种。如果某条记录的flag字段是NULL，WHERE flag = FALSE是查不到它的。你需要在SQL里显式加上OR flag IS NULL，或者用COALESCE(flag, FALSE) = FALSE。

5.2 char(n)类型尾随空格与等值比较

PG的char(n)类型是一个有长度限制的定长字符串，存储时如果不足长度会在尾部补空格。虽然PG在等值比较时会忽略尾随空格，但在拼接、GROUP BY、DISTINCT等场景下，这些空格可能会造成意想不到的差异。比如一个字段类型是char(10)，存进去的值是abc，实际存储是"abc "。你在查询条件里写WHERE name = 'abc'，PG能匹配到，但如果用GROUP BY name做分组，某些客户端工具或者ETL程序读出来的是“abc ”，跟程序里期望的“abc”对不上，表现出来就像是“结果集里的值不对”。解决办法是字段类型尽量用varchar或text，如果历史表已经用了char(n)，在查询时对字段做TRIM处理。

5.3 数字计算和类型转换的隐藏行为

大前提是，SQL里整数除以整数，结果也是整数。如果你写了SELECT 1/2，PG返回0而不是0.5，这在统计数据时很容易造成误解：总数明明不是0，但算出来的比例是0，看起来像“没有结果”。还有字符串与数字比较时，PG会尝试把字符串转换成数字，一旦字符串内容不是合法数字，就会报错，但如果被转成了0或者null，查询条件就可能失配。

日期时间类型更需要小心。timestamp和timestamptz在存储和比较上行为不同，如果表里存的是timestamptz，程序传入的是不带时区的timestamp，PG会按当前时区做转换，如果你的客户端时区跟服务器不一致，日期边界查询很容易少查一天。比如你要查“7月1日当天”的数据，直接写created_at BETWEEN '2024-07-01 00:00:00' AND '2024-07-01 23:59:59'在某些时区下可能只覆盖了部分时间范围。更稳妥的方式是用范围条件：

WHERE created_at >= '2024-07-01' AND created_at < '2024-07-02'

再配合显式的时区转换，避免边界丢失。

6. Navicat建库细节与连接参数该怎么选

说回热词里提到的“pg库在navicat中怎么建库，怎么选”，这个问题看起来基础，但建库选错了，后面的查询结果就莫名奇妙为空，所以我单独用一节来讲。

6.1 Navicat新建PostgreSQL数据库的完整步骤

首先你要在Navicat左侧的连接列表里先创建一个PostgreSQL连接，填好主机、端口、初始数据库（比如postgres）、用户名和密码。这个初始数据库是必须的，因为PG服务器本身要求你从一个已存在的库登录。连接成功之后，右键连接名，选择“新建数据库”，这里会出现几个关键选项：数据库名、所有者、字符集、模板、表空间。

字符集一般选UTF8，这个基本不会错。模板选template1即可，不要选template0，除非你有特殊需求。所有者一定要选对，因为后续程序连接如果用的是另一个用户，而建表时owner是当前用户，可能会导致跨用户访问时schema或表的权限不对。表空间保持默认就行，不建议在生产环境随便改。

6.2 建库时“数据库名”和“schema”到底怎么选

这里有一个非常容易混淆的点：Navicat里“新建数据库”其实等价于PG里的CREATE DATABASE语句，它创建的是数据库本身。数据库内部还有一个默认的public schema，Navicat通常在左侧展开表列表时，会把public schema下的表直接展示出来。如果你在“查询工具”里执行CREATE SCHEMA myschema，然后在这个schema下建表，Navicat左侧需要你手动切换到对应的schema分组才能看到表。很多人没注意到这一点，建表时默认建在了public下，但程序连接串里指定了currentSchema=myschema，结果代码里查不到表。

反过来说，如果你的程序没有指定currentSchema，而表又建在myschema下，你就要在Navicat连接配置的“高级”选项里，把“数据库”改成你的数据库名，还要确保search_path里包含myschema。建议在新项目初始化时，统一约定一个schema设计：

• 如果单库多schema隔离业务，连接串显式指定currentSchema；
• 如果只是简单业务，全部放public，不要额外建schema；
• owner账号与应用账号分离时，必须给应用账号授权GRANT USAGE ON SCHEMA my_schema TO app_user，否则查询结果为空甚至报权限错误。

6.3 连接参数里那些容易忽略的坑

Navicat连接PostgreSQL后，右键连接名可以查看连接属性，里面有几个配置会直接影响查询结果。一是“保持连接间隔”，如果连接空闲时间过长，Navicat会自动断开，你执行查询时会重新连接，这时如果原连接上有未提交事务，重连后自然看不到。二是“高级”里的“初始数据库”，如果你把初始数据库选成了postgres，然后在查询工具里执行的是SELECT * FROM public.users，可能查出来的表是postgres库里的public.users，而不是你自己的业务库里的表。数据库名选错，结果集为空那是必然的。

如果你是用JDBC连接，建议在连接串里显式加上几个参数：

jdbc:postgresql://localhost:5432/mydb?currentSchema=public&stringtype=unspecified&ApplicationName=myapp

其中stringtype=unspecified是一个比较有用的参数：它让PG驱动在绑定参数时，允许把字符串类型传给任意类型，避免某些情况下因为参数类型推断错误导致查询条件匹配失败。还有ApplicationName，这个参数能帮你在pg_stat_activity里快速定位到是哪台机器哪个应用发出的查询，排查问题会方便很多。

7. 实战排查：常见问题速查表与标准排查步骤

最后我整理了一张速查表，把你可能遇到的情况、原因、解决办法都列出来，建议直接存起来，下次遇到“pg库查询结果在结果集中找不到”的问题时，按图索骥。

7.1 一条标准排查路径，省下半天时间

出现结果集为空的时候，我建议按下面的顺序走一遍：

第一步，确认当前连接的用户、数据库和schema。执行：

SELECT current_user, current_database(), current_schema();

如果current_schema返回的不是你建表的那个schema，问题大概率就在这里。

第二步，查看search_path。执行SHOW search_path，确认里面包含了目标schema。如果没包含，尝试用SET search_path temp修改后再次查询，如果OK了，就去改连接串配置。

第三步，查看是否有未提交事务锁住了数据。执行：

SELECT pid, state, wait_event_type, query FROM pg_stat_activity WHERE datname = '你的数据库名';

如果有state = 'idle in transaction'的会话，说明有连接一直挂着事务，这会导致其他连接读不到最新数据。

第四步，把程序日志里那条SQL原封不动地复制到Navicat里执行，如果能查到，基本可以排除SQL问题；如果查不到，就检查条件里的参数值是否为NULL、空字符串，或者类型不匹配。

7.2 几个亲测有效的调试小技巧

我自己调试这类问题的时候，会额外加几条辅助输出，帮自己快速定位。

程序里打印SQL时，不要只打印那句SQL文本，要把所有参数值也打出来。比如MyBatis的日志里会输出==> Parameters: 1(String)，这里面的String类型提示很重要，如果类型不匹配很容易查出0行。另外我会在SQL前面加上一行注释，比如/* appName:UserService.getUserById */，这样在pg_stat_activity里一看就知道是哪个代码段在跑，排查效率翻倍。

如果用的是连接池，我还习惯在调试时把最大连接数临时调小，比如设成1，强制所有请求走同一个连接。当年有一次怎么都查不到数据，后来发现是连接池里有几个连接连接的是另一个数据库，因为数据库迁移后旧的连接一直没释放。把连接池调成1之后立刻复现，问题瞬间被暴露出来。

最后分享一点经验

排查这种“pg库查询结果在结果集中找不到”的问题，我最大的体会是：先别急着怀疑PG有什么特殊的毛病，十次里面有八次是连接、事务、schema、大小写这些外围因素在捣乱。数据只有在正确的时间、正确的位置、以正确的名称出现，你才看得到它，任何一环出了偏差，都会表现为“结果集为空”。另一个体会是，多打印关键信息比瞎猜快得多。SQL带上参数打出来、事务状态查出来、search_path显示出来，问题基本就摆在你面前了。

最后再分享一个小技巧：如果你在Navicat里怎么查都有数据，但在程序里就是没有，试着在Navicat里新开一个查询窗口，不用Navicat自动的当前连接，而是用程序那个账号的连接配置手动登录再查一遍。很多时候，“Navicat能看到”和“程序查询账号能看到”是两回事，这一步能帮你快速区分是权限/schema问题还是代码问题。