云数据库GaussDB：3个参数最容易被忽略

库迁上去头两周风平浪静，第三周开始应用隔三差五抛个连接异常，重启一下又好了。运维把监控翻了个遍，CPU 不高，IOPS 不高，磁盘也没满，一脸问号。这种场面在云数据库GaussDB上不算稀奇，问题往往不在机器不够用，而是三个默认参数你从来没碰过——连接数、排序内存、自动清理阈值。它们安静的时候像不存在，等并发上来、或者某张表长到一定体量，才开始收利息。

云数据库GaussDB里第一个被忽略的参数，是连接数

max_connections 这玩意儿，很多人的第一反应是往大了调，反正大点不亏。恰恰相反。GaussDB 的每个会话都要占一份独立的内存，几百个连接挂在那儿，光连接本身就能啃掉实例内存的一大块，留给缓冲池的就薄了，查询开始频繁读盘，同一个 SQL 时快时慢。更常见的坑在应用侧：连接池上限写着 300，数据库只给 100，高峰一到就是排队等超时，日志里一串拿不到连接的报错，看着像网络问题，其实是对不上。反着来也一样难受，数据库给到 800，业务真实峰值才几十，剩下的内存白白占着。先摸清峰值并发到底多少，再留一点余量，具体上限和单连接的内存开销以官方规格文档为准，别人晒的配置照抄没意义。空闲连接该回收就回收，长连接不是不能用，但得有人盯着。

work_mem 调大以后，单条 SQL 快了，整机反而慢了

排序和哈希这块内存，是按单个执行节点申请的，一条 SQL 里挂三个排序节点就乘三，再乘上并发数。测试环境单条跑，调大一倍看着挺爽，压测一上来直接翻车：内存被抢光，排序开始落临时文件，IO 飙起来，耗时比原来还长。判断办法不难，看执行计划里的 Sort Method 是不是变成 external merge，看临时文件写了多少。要调就小步走，一次加一点，拿真实并发去压，别拿单条 SQL 的响应时间当依据。顺带说一句，排序吃内存的查询往往本身写法就有问题，缺索引、排序字段过多，先改 SQL 比调参数划算。

autovacuum 那两个比例阈值，属于沉默型故障

这个坑最阴，因为它不报错。表上删除、更新越攒越多，自动清理按比例触发，表越大那个比例对应的绝对行数就越夸张，结果小表天天清，大表几百年轮不到一回。表一膨胀，统计信息也陈旧，执行计划开始跑偏，本来走索引的改成全表扫，接口就慢了。处理思路有两层：一是对大表单独设阈值，别拿一套全局值套所有表；二是定期查表膨胀和统计信息的更新时间，看见长期没清理的表心里要有数。有人图省事直接把 autovacuum 关掉，那属于把体温计砸了当没发烧。

云数据库GaussDB的控制台上，这三个参数能观察到什么

参数模板里能看到当前值，但光看值没用，得跟实际运行数据对上。连接这块看活跃会话和空闲会话的比例，长期一堆 idle 的连接说明池子没管好；内存这块看慢 SQL 和临时文件；清理这块看表的膨胀率和最近一次 autovacuum 的时间。监控面板只给方向，下钻还得靠系统视图和自己的慢日志。云上很多指标是分钟级聚合的，尖峰容易被抹平，别指望一眼看出来，把观察窗口拉长几天更靠谱。

改参数别三件事一起改

一次动一个，留出观察窗口，这是最基本的纪律。三个参数一起改，指标变好了不知道谁的功劳，变坏了也找不到元凶。另外生效方式得搞清，有的参数改完立刻生效，有的必须重启实例，重启这事儿在云上一来一回也是时间成本。稳妥点的路子是先在一套小规格的测试实例上验证，或者从只读副本、低峰时段开始试，别在业务高峰直接改生产。参数模板跟着实例规格走，换了规格要重新算一遍，别照着上一个实例的模板硬套。

实例规格没搞清就调参，等于闭眼开车

同样的参数值，放在 8G 内存的实例上能跑，放到 32G 上可能一点感觉都没有，反过来调大就可能直接把内存撑爆。工作内存和连接数都是跟着实例规格走的，先确认实例的 CPU 和内存到底多少、存储的 IOPS 上限在哪，再动参数，顺序别反。规格不够的时候，调参数顶多缓解，真要扛并发还是升规格来得直接，参数只是把现有资源用得更细一点。

真要说落地，就三条：先把应用连接池和数据库连接数对齐，别一个 300 一个 100；再把排序内存从默认值小步往上试，用压测数据说话，别凭感觉；最后把大表的自动清理阈值单独拎出来配，定期看膨胀和统计信息。三个动作都不复杂，麻烦的是得有人真的去看监控、真的去翻慢日志。参数这东西，默认值不一定是错的，但默认值肯定不是为你这套业务量身定的。