数据库服务器配置文件，算得上运维和开发日常接触最多的一类文件。刚入行打开my.cnf的时候，几百行参数密密麻麻，单个词都认识，拼在一起完全搞不懂含义，更不敢随便修改。踩过不少坑之后，慢慢摸清楚里面的门道。这里挑几个核心参数聊聊，不用面面俱到，至少下次打开配置文件，能分清哪些数值可以调整，哪些尽量别动。
先说内存部分，直接决定数据库性能好坏。在MySQL里面，innodb_buffer_pool_size是绕不开的参数。InnoDB会把数据页和索引页放到这块内存缓存里，收到查询请求优先去缓冲池查找，命中就直接返回结果，找不到才读取磁盘。内存访问和磁盘IO的速度差距，打个比方就像走路对比坐高铁。所以这个参数的大小，直接影响多少查询可以直接从内存读取。默认128MB放在现在硬件环境基本等于没有配置，专用数据库服务器一般设置成物理内存的50%到70%，32G服务器分配16G到22G是比较合理的区间。不要一次性给到90%，操作系统本身也需要内存运行，预留一部分空间给文件系统缓存和其他进程。
PostgreSQL对应的参数是shared_buffers，但推荐比例比MySQL保守很多，通常设置成总内存的25%左右。不是PG不想占用更多内存，而是它和操作系统有一套协同机制，如果shared_buffers设置过高，会和操作系统页缓存争抢物理内存，两者互相冲突，性能反而下降。所以PG调优思路和MySQL不一样，MySQL倾向自身承担大部分缓存工作，PG更多依靠操作系统缓存分担压力。
内存参数还有一个容易被忽略的，PostgreSQL的work_mem。这个参数控制排序、哈希操作在生成临时文件前能够使用的内存大小。看着不起眼，但有个很容易踩的坑：它是单个操作分配内存，不是单连接，更不是全局共享。一条复杂查询可能包含多个排序节点，每个节点都会单独占用一份work_mem。如果设置成256MB，十几个并发连接同时执行复杂查询，内存很快就会被吃掉好几G。调整work_mem一定要克制，初始设置16MB到32MB基本够用，如果有重型分析查询，可以在会话层面临时调高，不需要全局统一拉满。
内存说完，连接数也是经常被错误调整的地方。max_connections字面意思很容易让人觉得数值越大越好。实际上每一条连接都要占用内存维护会话状态，PostgreSQL中一条空闲连接大概占用5到10MB，几百条空闲连接挂着，好几G内存就白白消耗。更关键的是连接数超过临界值之后，锁竞争与上下文切换带来的开销，会抵消新增连接带来的收益，整体吞吐量反而下滑。正确做法是在应用和数据库中间部署连接池，比如PostgreSQL用PgBouncer，MySQL用ProxySQL，让几百个业务工作线程共享几十个真实数据库连接。数据库层面的max_connections不用设置过大，200到300对于绝大多数场景足够，另外预留3到5个连接，留给管理员紧急排查故障。
接下来这个参数常常被人忽略，但是对性能影响不小：innodb_io_capacity。它用来告诉InnoDB当前存储设备每秒可以完成多少次IO操作，InnoDB依靠这个数值调整后台脏页刷新、变更缓冲区合并的节奏。默认值10000，放在现代SSD上可能偏低，但也不是越大越好。数值设置太高，InnoDB会激进地刷出脏页，缓冲池还没发挥缓存作用数据就写入磁盘；设置过低，后台任务跟不上写入速度，脏页堆积到阈值就会触发剧烈刷盘风暴。比较稳妥的方式，按照磁盘实际IOPS配置，机械盘几百到一两千，SATA SSD几千，NVMe可以设置两万以上。拿不准的话，可以先跑一轮基准测试获取真实数值。
查询优化器这块，MySQL和PostgreSQL都有可以手动干预的参数。MySQL的optimizer_search_depth，用来控制优化器评估多表连接计划时的搜索深度。表数量多的时候，连接顺序组合会爆炸性增长，十二三张表关联，如果让优化器穷举全部组合，单条SQL的解析编译可能耗时数小时。search_depth设置成3或者4，编译时间一般可以压缩到一分钟以内，代价是有可能错过最优执行计划，但生产环境出现这种情况概率并不高。PostgreSQL里enable_seqscan、enable_bitmapscan这类开关逻辑类似，相当于告诉优化器禁止使用某类扫描方式，只适合临时排查问题，长期关闭一般不是好方案。
最后聊聊日志和刷盘策略，这部分本质是在数据安全性和性能之间做取舍。innodb_flush_log_at_trx_commit这个参数，值设为1时每次事务提交都会把redo log写入磁盘，安全性最高，但写入速度最慢；设置为2，系统每秒统一刷写一次日志，宕机时可能丢失最后一秒的数据，写入性能会提升。具体选择要看业务能够承受多大的数据丢失风险。支付、账务系统稳妥选择1，日志采集、统计报表业务可以调整到2。没有万能配置，只能根据业务权衡。