标准答案
- 连接数表示数据库会话和进程资源，包含 idle、active、idle in transaction 等不同状态；连接多不代表同时有同样多的 SQL 在消耗 CPU。
- active 查询表示会话正在处理请求，但仍可能处于锁、I/O 或其他等待，必须结合 wait_event 判断它是在执行还是排队。
- 并发增加到资源拐点前可能提高吞吐，超过 CPU、I/O、锁或缓存能力后，通常只会增加上下文切换、排队和 P95/P99 延迟。
- 有效吞吐是成功完成且满足业务时限的工作量，还受事务提交、下游服务、WAL、复制和应用消费能力约束，不能只用数据库 QPS 定义。
- 容量规划要按所有应用实例、后台任务、迁移和故障扩容后的最大规模计算连接预算，再用连接池、限流和队列控制有效并发。
题目解析
max_connections 只是允许建立多少会话的上限，不是数据库应该承受的最佳并发。每个后端进程和会话都有内存、调度和管理成本，超过工作负载的最优点后，更多连接会让所有请求变慢。
同样的连接数在不同工作负载下含义不同：短查询可能受锁和网络影响，复杂聚合可能受 CPU 和内存影响，大批量写入还会受 WAL 和磁盘影响。因此容量测试必须使用接近真实的查询比例和数据分布。
排队位置也要明确。应用在池里等连接、数据库在等锁、查询在等 I/O，都会增加接口耗时，但修复动作分别是池配置、事务治理和资源或 SQL 优化。
常见误区
- 误区：把 max_connections 调大就能提高吞吐。改正：先测出资源拐点，用连接池和限流控制有效并发，避免把排队推入数据库。
- 误区：只看连接总数判断数据库是否繁忙。改正：区分 active、idle、idle in transaction，并结合 wait_event、CPU、I/O 和锁等待。
- 误区：用单一 QPS 作为容量结论。改正：同时看成功率、P95/P99、事务耗时、WAL、复制延迟和应用端排队，确认吞吐没有以尾延迟为代价。