Ryan Booz：Postgres生产环境特别系列：诊断pg_stat_statements中的高基数工作负载（第6部分）
内容提要
本文探讨Postgres中pg_stat_statements在高基数工作负载下的问题。当唯一查询数超过pg_stat_statements.max容量时，指标会丢失，影响查询调优。ORM、动态SQL和AI工具会生成大量独特查询，Postgres 18改进了IN列表归一化。诊断方法包括检查语句数、重置后填充速度、deallocation计数等，建议升级并调整设置。
延伸解读
高基数工作负载的识别信号
当pg_stat_statements中的唯一语句数持续接近max设置（如95%阈值），或重置后短时间内（如30分钟）迅速填满，或deallocation计数频繁增长，或你常找不到已知的查询文本，这些都表明高基数工作负载正在导致指标丢失。若按总执行时间排序的Top查询频繁变动，而实际负载稳定，也需警惕。
ORM与AI工具对查询基数的影响
ORM、动态SQL和AI辅助工具会生成大量看似相似但实际唯一的查询，尤其是包含可变长度IN列表或动态列选择列表的语句。在Postgres 17及以下版本，这些查询无法归一化，容易迅速占满pg_stat_statements容量。Postgres 18改进了IN列表归一化，显著减少唯一语句数，但工具首次发送参数时可能因类型不确定产生额外条目。
应对高基数工作负载的实用建议
若确认存在高基数工作负载，应主动调整pg_stat_statements配置（如max和track设置），考虑升级到Postgres 18以利用IN列表归一化改进。同时与开发团队沟通，识别ORM和AI工具生成的查询模式，记录指标缺失的时间点，以便在调优时更准确地定位问题。
Q&A
什么是高基数工作负载，它如何影响pg_stat_statements？
高基数工作负载指的是唯一规范化查询的数量持续超过pg_stat_statements.max容量。这会导致扩展无法保留所有查询的指标，使得查询调优变得困难，因为可能丢失关键数据。
为什么ORM、动态SQL和AI工具会导致pg_stat_statements产生大量唯一查询？
ORM和AI工具会为不同的客户端、客户或租户生成独特的SQL语句，动态SQL在存储过程中也会产生独特语句。AI工具在探索数据库时会产生大量临时查询。这些都会快速填满pg_stat_statements。
Postgres 18在IN列表归一化方面有什么改进？
Postgres 18将IN列表归一化为单个语句，而在Postgres 17及以下版本中，每个不同的IN列表都会被视为唯一查询。这显著减少了pg_stat_statements中的条目数量。
如何诊断pg_stat_statements是否因高基数工作负载而丢失数据？
诊断方法包括：检查pg_stat_statements.max设置，查看语句数是否接近上限，重置后是否快速填满，检查pg_stat_statements_info中的deallocation计数是否上升，以及是否经常找不到已知的查询文本。
如果发现高基数工作负载，应该采取哪些措施？
建议升级到Postgres 18，调整pg_stat_statements设置（如增加max），与开发团队讨论ORM和AI工具生成的查询模式，并记录pg_stat_statements缺失信息的时间点以识别模式。
为什么即使使用Postgres 18，某些查询仍会生成多个条目？
即使Postgres 18归一化了IN列表，工具在首次发送参数化查询时可能使用通用类型（如numeric），之后才调整为正确类型（如integer），导致同一查询文本出现多个条目。
