前言
postgres-howto 系列 (🔗 https://github.com/xiongcccc/postgres-howto) 已经翻译到了第 63 章，今天分享的是一篇有趣的 howto 系列 — how to help others，即如何帮助他人。不管是生活中，还是工作上，我们无时无刻不在与人打交道，不管是帮助他人，亦或是有求于人。以数据库 PostgreSQL 为例，有人向你请教一个问题，你如何作答？这篇文章突出了两个核心原则：
- 寻找你的”巨人肩膀”
- 实践出真知，don’t blindly trust everything
How to help others
我每天都会发布一篇新的 PostgreSQL “howto” 文章。加入我的旅程吧 — 订阅、提供反馈、分享！
帮助他人 (无论是对团队成员的内部帮助还是外部咨询) 有两个关键原则：
- 依赖可靠的资源。
- 测试一切。
原则1：可靠的资源
依赖你所信任的高质量资源。例如，我的观点是，根据质量/可信度等级来排名，大致如下：
- PostgreSQL文档 – 9/10
- PostgreSQL源码 – 10/10 (真理的来源！)
- StackOverflow上的随机答案 – 5/10或更低（但不包括 Erwin Brandstetter, Laurenz Albe, Peter Eisentraut 的回答 — 他们回答得很棒，8/10 或更高)。
- 随机博客文章，同样 5/10 或更低。
- Suzuki 和 Rogov 的 Internals 两本书 – 8/10 或更高
另外 (非常重要！)，始终提供你参考资源的链接；这样做有两个好处：
- 推广好的资源，回馈它们；
- 在某种程度上分担责任 (如果你经验不足，这非常有帮助；每个人都有可能犯错)。
原则2：验证 — 数据库实验
始终对所有事物保持怀疑，不要轻信语言模型，无论它们的性质如何。
如果有人 (包括你或我) 在没有通过实验 (测试) 验证的情况下说了某件事，就需要通过实验进行验证。
所有的决策都应该基于数据，而可靠的数据是通过测试收集的。
大多数与数据库相关的想法都需要通过数据库实验来验证。
两种类型的数据库实验：
多会话实验，成熟的基准测试，例如使用
pgbench、JMeter、sysbench、pgreplay-go等工具进行的基准测试。它们的目的是研究 Postgres 的整体行为及其所有组件，必须在专用资源上进行 (在这里，其他人不应有任何工作)。环境应与生产环境相匹配 (虚拟机和磁盘类型、PostgreSQL 的版本、相关设置等)。
此类实验包括负载测试、压力测试、性能回归测试等。主要工具是用于研究宏观级别查询分析的工具：
pg_stat_statements、等待事件分析 (即历史活跃会话或性能/查询洞察)、auto_explain、pgBadger等等。关于此类实验的更多信息：详见 Day 13: How to benchmark.
单会话实验，使用单个会话 (有时两个) 测试一个或一系列 SQL 查询，以检查查询语法、研究单个查询行为、优化特定查询等。
这些实验可以在共享环境中进行，使用较弱的机器也可以。但是，要研究查询性能，你需要使用相同的PostgreSQL 版本、相同或类似的数据库，以及匹配的规划器设置 (如何做到这一点：参照 Day 56: How to make the non-production Postgres planner behave like in production)。需要注意的是，计时指标可能与生产环境相比显著偏差，在查询优化过程中主要应关注执行计划和数据量 (
EXPLAIN中的实际行数、BUFFERS选项提供的缓冲区操作计数)。此类实验的示例：检查 SQL 查询序列的语法和逻辑行为，查询性能分析
EXPLAIN (ANALYZE, BUFFERS)，测试优化想法，架构更改测试等。快速克隆大型数据库非常有用，而且不需要为存储付额外的钱 (例如 Neon、Amazon Aurora)。如果存储和计算都不需要额外费用，那么测试活动，包括 CI/CD 中的自动化测试，就真正得到了释放 (DBLab Engine @Database_Lab)。
总结
如你所见，原则非常简单：
- 阅读优质的文章；
- 不要盲目相信 — 测试一切。