TG咨询数据库物理机优化的重点，不是单纯更换更高规格的服务器，而是让存储、内存和并发参数与业务访问模式匹配。以 PostgreSQL 或 MySQL InnoDB 为例，随机读写、事务日志刷盘、排序临时表和高峰连接都会争用有限资源。优化前应先确认瓶颈，再按顺序处理，否则容易出现磁盘升级后等待仍未下降、内存增加后并发反而不稳定等情况。
先确认物理机的真实瓶颈
建议连续观察一个完整业务周期，至少覆盖高峰、低峰和备份时段。Linux 环境可以结合 iostat、vmstat、free、sar 等工具，数据库侧则查看慢查询、锁等待、检查点、临时文件和连接数。
- 记录数据盘和日志盘的读写延迟、吞吐量、队列长度及利用率，区分数据文件、事务日志和备份文件的影响。
- 检查可用内存、交换分区活动、页面回收和文件缓存变化，确认数据库缓存是否与操作系统争抢内存。
- 统计活跃连接、空闲连接、锁等待、长事务和每秒事务量，避免把连接总数误认为实际并发。
- 将这些指标与接口响应时间、批处理耗时和错误日志对齐，再决定调整硬件还是参数。
从存储路径减少等待
数据盘与日志盘要分工
数据库数据文件主要产生随机访问，事务日志则更关注连续写入和稳定的刷盘延迟。条件允许时，可将数据文件、WAL 或 redo log、临时文件放在不同存储设备上，减少批量写入对在线事务的干扰。NVMe SSD 通常比普通 SATA 机械盘提供更低的随机访问延迟，但实际收益仍取决于控制器、文件系统、队列深度和设备耐久度。
不要只依据标称顺序读写速度选盘。对于小块随机读写较多的数据库，应重点观察约 4KB 至 16KB 请求下的延迟和稳定性；日志盘还要关注持续写入时是否出现明显抖动。启用文件系统和磁盘阵列缓存时，必须确认断电保护机制，不能用没有可靠保护的写缓存换取表面性能。
检查分区、挂载与容量
数据盘长期接近满载后，整理空间、扩展文件和备份都会变得困难。生产环境通常应预留足够扩容空间，具体比例要结合增长速度、备份周期和可用磁盘架构确定。还要检查挂载参数、磁盘健康状态、RAID 重建进度以及是否存在单盘故障。数据库物理机优化在存储层的目标，是降低关键 I/O 的等待，而不是追求所有指标都达到最高。
内存配置要兼顾数据库和系统
数据库缓存越大不一定越快。PostgreSQL 的 shared_buffers、MySQL InnoDB 的 innodb_buffer_pool_size 都应给操作系统、连接会话、排序、临时表、备份工具和监控进程留下空间。专用数据库服务器可把较大比例内存交给缓冲池，但不宜脱离实际工作集和进程数量直接套用固定百分比。
调整时先观察命中率、脏页数量、临时文件生成和交换活动。若交换分区持续被使用，应优先查明内存过量分配、连接过多或单条查询排序过大的原因，而不是继续扩大缓存。采用多路处理器架构的服务器还要关注 NUMA：内存跨节点访问可能带来额外延迟，数据库进程绑定策略、内存分配方式和操作系统版本需要结合实测决定。
并发参数应按连接来源治理
不要盲目提高最大连接数
每个数据库连接都可能占用会话内存、锁资源和调度资源。应用侧使用连接池，通常比让每个请求直接新建连接更稳定。连接池大小应依据数据库可承受的活跃事务数、查询平均耗时和应用实例数量计算，并为管理连接、备份和故障处理保留余量。
例如，业务服务有多个实例时，不能只看单实例连接数；应将各实例上限相加，再与数据库最大连接数比较。连接数较高但活跃事务很少时，问题可能在连接泄漏、空闲事务或连接池回收策略，而不是数据库容量不足。
区分读、写与后台任务
在线写事务、复杂报表和清理任务混在同一资源池内，容易造成锁等待和 I/O 争抢。可以通过账户权限、连接池、任务窗口或只读副本进行隔离。对于 PostgreSQL，应关注 checkpoint 频率、WAL 生成速度和刷盘压力；对于 MySQL InnoDB，则要观察 redo log、缓冲池脏页和刷新行为。参数调整后应记录变更前后指标，避免多个变量同时修改而无法判断效果。
一套可执行的优化流程
- 建立基线：记录高峰期延迟、事务量、磁盘延迟、内存使用、活跃连接和锁等待，连续采样一段稳定时间。
- 先处理硬伤：修复故障磁盘、异常 RAID、交换活动、连接泄漏和长期未提交事务。
- 调整存储：分离日志与数据 I/O，确认设备具备适合数据库的耐久度和断电保护。
- 调整内存：逐步改变缓冲池或共享内存配置，每次变更后观察命中率、交换和临时文件。
- 治理并发：设置连接池上限、空闲超时、事务超时和后台任务资源边界。
- 验证回归：使用接近真实读写比例的测试数据，并同时观察锁、日志、磁盘和错误率；不要只用单一查询判断效果。
常见问题
数据库物理机优化是否一定要升级硬件？
不一定。若瓶颈来自慢查询、连接泄漏、日志争用或错误的内存分配，先修正配置通常更合适；确认设备延迟或容量成为主要限制后，再升级存储或内存。
数据盘和日志盘必须分开吗？
不是必须。业务规模较小且 I/O 负载平稳时可以共用，但高写入事务、批量导入或备份会显著增加分离的价值。
如何判断连接数是否过高？
不能只看总连接数，应同时检查活跃事务、会话内存、锁等待、上下文切换和响应时间。大量空闲连接还可能说明连接池回收不及时。
优化后多久复盘一次？
每次参数或硬件变更后，应覆盖至少一个高峰周期，并在备份、批量任务和异常流量出现时再次观察。数据库物理机优化应以持续监控和可回滚变更为基础。
归根结底，数据库物理机优化要围绕瓶颈排序：先保证存储延迟稳定，再合理分配内存，最后用连接池和任务隔离控制并发。只有把硬件指标、数据库等待事件和业务响应时间放在同一条证据链上，调整结果才具有实际价值。
