PostgreSQL 中 pg_stat_database 视图的 tup_returned 字段的含义完整指南

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“PostgreSQL 中 pg_stat_database 视图的 tu……”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

在这个场景下，此篇详细解释一下 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_returned 就是一个说明“数据库自从启动以来，总共读取了多少行数据”的计数器。它是一个很重要的、用来宏观性能分析和诊断的指标。

到此这篇关于PostgreSQL 中 pg_stat_database 视图的 tup_returned 字段的含义详解的文章就介绍到这了,更多相关PostgreSQL pg_stat_database tup_returned 字段内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多兼容脚本之家！