此篇详细解释一下 PostgreSQL 中 pg_stat_database 视图里的 tup_returned 字段的含义。
核心定义
tup_returned 字面意思是 “返回的元组数”。
这里的“元组”可以通俗地理解为 数据表中的一行。
因此，tup_returned 统计的是 从数据库中读取到的行数。
详细解释
- 统计的是什么？
- 它统计的是由 所有类型的查询（SELECT, UPDATE, DELETE 等） 所访问到的行数。
- 例如：
- 一个
SELECT * FROM table_name查询，返回了 100 行，那么这 100 就会被累加到tup_returned中。 - 一个
UPDATE table_name SET column = value语句，它需要先找到所有要更新的行（类似于一个 SELECT），假设它匹配了 50 行，那么这 50 行也会被累加到tup_returned中，即使它最终更新了这些行（更新操作本身由tup_updated统计）。 - 同样，
DELETE语句在删除前也需要先找到这些行，所以找到的行数也会计入tup_returned。
- 一个
- 统计范围：
- 这个统计是 数据库级别 的。
pg_stat_database视图中的这个值，是该 PostgreSQL 集群中 单个数据库 的累计值。它包含了该数据库内所有表、所有查询所返回的行数总和。
- 这个统计是 数据库级别 的。
- 与
tup_fetched的区别：- 在
pg_stat_database中，还有一个容易混淆的字段叫tup_fetched。 tup_returned： 主要由 顺序扫描 返回的行数。当数据库没有使用索引，需要全表扫描来查找数据时，读取的每一行都计入此项。tup_fetched： 主要由 索引扫描 返回的行数。当数据库通过索引查找到数据行时，通过索引“获取”到的每一行都计入此项。
- 在
- 简单总结：
tup_returned≈ 顺序扫描读到的行数tup_fetched≈ 索引扫描读到的行数
实践意义与使用场景
tup_returned 是一个非常重要的宏观性能指标：
- 衡量数据库负载： 这个值在持续、快速地增长，说明数据库正在处理大量的数据读取请求。通过观察其增长速度，可以直观了解数据库的繁忙程度。
- 分析读取模式： 结合
tup_returned和tup_fetched，可以判断数据库的查询效率。- 如果
tup_returned的值远高于tup_fetched，说明有大量的查询正在进行全表扫描，这可能意味着 缺少合适的索引。 - 一个健康的、以OLTP（在线事务处理）为主的数据库，通常
tup_fetched会远大于tup_returned，因为大部分查询都应该通过索引来快速定位数据。
- 如果
- 监控长期趋势： 通过定期记录这个值，可以了解数据访问量的变化趋势，为容量规划提供依据。
示例查询
可以通过以下 SQL 语句查看所有数据库的统计信息：
SELECT
datname AS database_name,
tup_returned,
tup_fetched,
tup_inserted,
tup_updated,
tup_deleted
FROM
pg_stat_database;
结果解读：
假设看到某个数据库的 tup_returned 是 10,000,000，而 tup_fetched 是 500,000。这强烈暗示该数据库中存在效率低下的全表扫描查询，应该去检查一下慢查询日志，并为频繁查询的字段添加索引。
总结
| 特性 | 说明 |
|---|---|
| 中文名 | 返回的元组数 |
| 本质 | 从数据库中读取到的行数（累计值） |
| 主要来源 | 顺序扫描（全表扫描） |
| 对比指标 | tup_fetched（主要来自索引扫描） |
| 主要用途 | 评估数据库负载、分析查询效率（判断是否缺少索引） |
简单来说，tup_returned 就是一个说明“数据库自从启动以来，总共读取了多少行数据”的计数器。它是一个非常重要的、用于宏观性能分析和诊断的指标。
