TG咨询数据库物理机优化的重点，不是把所有硬件指标都调到最高，而是找出真正限制数据库吞吐量和响应时间的环节。对于运行 MariaDB、IBM Db2 或其他关系型数据库的专用服务器，应按照“监控基线—问题诊断—参数调整—回归验证”的顺序执行。这样既能减少无效改动，也便于在出现异常时快速回退。
先建立一份可对比的监控基线
优化前至少连续观察一个完整业务周期。若业务存在明显的早晚高峰，建议覆盖高峰、低谷和批处理时段，通常不少于 24 小时。记录内容不能只看数据库连接数，还应同时采集主机和实例层面的数据。
- 处理器：记录总使用率、单核忙碌程度、用户态与系统态占比，以及上下文切换和运行队列长度。多核服务器出现单核长期满载，可能是锁竞争、线程调度或并行度设置问题。
- 内存：关注可用内存、交换分区活动、数据库缓冲区命中情况和大页使用状态。物理内存尚有余量，并不代表数据库缓存配置合理。
- 存储：记录数据文件、日志文件和临时文件所在设备的读写延迟、队列深度、吞吐量及空间余量。日志写入延迟往往比持续带宽更直接影响事务提交。
- 网络：观察网卡丢包、错误包、带宽占用和连接建立失败。应用与数据库分离部署时，网络延迟应与查询耗时一起分析。
- 数据库：采集慢查询、锁等待、事务提交耗时、临时表使用、缓存命中率和检查点或日志刷新活动。
基线应保留采集时间、业务负载和配置版本。没有优化前后的可比记录，就很难判断一次调整究竟改善了数据库物理机优化效果，还是只是恰好避开了高峰。
按症状定位物理瓶颈
CPU高不一定要立刻增加核心
如果处理器持续高负载，同时慢查询数量增加，应先查看执行计划、排序和聚合操作，再检查锁等待。索引缺失、统计信息过期或一次查询扫描大量数据，都可能让 CPU 长时间占用。只有在查询计划和并发控制基本正常，且多个核心均稳定饱和时，增加物理核心或提高主频才更有意义。
内存问题要区分缓存不足与泄漏
数据库缓冲区过小，会增加数据页读取；缓冲区过大，则可能挤压操作系统、备份程序和文件缓存。调整前应查看进程常驻内存、交换活动和数据库自身分配记录。对于启用透明大页、共享内存或固定内存的系统，还要确认操作系统版本和数据库版本的兼容性，不能直接套用其他服务器参数。
存储要分别看数据、日志和临时空间
将数据文件、事务日志和临时文件放在同一组磁盘上，容易在批量导入、索引维护或高并发写入时互相争用。数据库物理机优化通常应先区分三类 I/O：随机读主要影响数据访问，顺序写常影响日志刷新，临时空间则可能受到排序和哈希操作影响。高并发事务环境更关注低延迟和稳定队列，而报表扫描更关注持续吞吐，两者选盘标准并不相同。
| 现象 | 优先检查 | 常见处理方向 |
|---|---|---|
| 提交延迟升高 | 日志设备写延迟、刷新频率 | 分离日志设备，检查缓存保护和日志参数 |
| 查询偶发变慢 | 锁等待、I/O 队列、执行计划 | 优化索引与事务范围，减少设备争用 |
| 批处理拖慢在线请求 | 临时空间、CPU、内存压力 | 错峰执行，限制并行度并隔离资源 |
调参应采用小步变更
- 先复制当前数据库配置、操作系统参数和服务启动选项，明确每项改动的回退值。
- 一次只调整一类参数，例如先处理缓冲区，再处理并行度或日志刷新策略，避免多个变量同时变化。
- 选择可重复的验证窗口，使用接近真实比例的读写事务、批量任务和连接并发，不要只运行单条查询。
- 对比响应时间、每秒事务数、锁等待、I/O 延迟、错误率和资源使用率；至少观察一个高峰周期。
- 若关键指标恶化，立即恢复原值，并检查是否需要重启、重新加载配置或清理临时文件。
操作系统层面可检查文件系统挂载选项、磁盘调度策略、时钟同步、进程限制和后台扫描任务。对于多路处理器服务器，还应确认数据库进程、网卡中断和存储中断是否出现明显的内存访问不均衡。绑定策略并非越严格越好，只有在确认线程迁移或跨节点访问造成开销时才适合实施。
把验证和安全控制纳入流程
数据库物理机优化不能只看性能，还要检查可靠性。磁盘缓存是否具备断电保护，日志和备份是否仍能正常写入，监控告警是否覆盖磁盘空间、温度、阵列降级和服务重启，都是上线前的必要检查。任何涉及存储布局、内存上限或内核参数的变更，都应安排维护窗口，并准备配置备份和回滚方案。
常见问题
问：是否应该先升级内存？
不一定。只有当交换活动明显、数据库缓存不足且工作集持续增长时，增加内存才可能直接改善效果。
问：磁盘延迟达到多少就算异常？
没有适用于所有业务的单一阈值。应结合日志刷新、查询类型和高峰基线判断；同一设备在低负载与高并发下的表现也可能不同。
问：调参后多久可以确认有效？
至少覆盖一次完整高峰和主要批处理任务。短时间内的单次查询结果，不能代表整体优化效果。
问：为什么资源使用率不高，数据库仍然很慢？
可能存在锁等待、单线程瓶颈、网络延迟、日志刷新或单个设备排队。平均 CPU 和内存使用率无法替代分层监控。
总体而言，数据库物理机优化应以证据为依据：先监控，后诊断；先小范围调整，再通过真实负载验证。只有把硬件、操作系统、数据库实例和业务时段放在同一分析链路中，优化结果才更稳定、可复现。
