TG咨询生产数据库运行在物理机上时，优化目标不是单纯提高某一项配置，而是让计算、内存、存储、网络和故障处理保持相对平衡。数据库物理机优化应先从业务负载和历史监控入手，再决定扩容、调整拓扑还是改变维护方式。下面按六个常见场景说明注意事项。
一、交易高峰下的计算资源分配
支付确认、票务下单、仓储扣减等事务型业务，通常同时产生短查询、锁等待和提交操作。物理机的平均利用率并不能代表峰值体验，尤其要关注单核繁忙、上下文切换和数据库进程是否集中在少数核心。
- 先按分钟或更短周期查看业务高峰，记录活跃会话、事务响应时间、锁等待和处理器使用率。
- 区分数据库进程、备份程序、监控代理和杀毒扫描等非数据库负载，避免它们在同一时段争抢核心。
- 为数据库保留合理的系统余量，不要把所有逻辑处理器都分配给数据库进程；批处理任务应安排在低峰执行。
增加核心适合并行查询和连接规模确实较大的场景，但未必能解决慢SQL或锁竞争。数据库物理机优化应先确认瓶颈属于计算不足，再考虑更换处理器或调整并行度。
二、内存容量足够但访问仍然变慢
在双路或多路服务器中，内存带宽和访问位置同样重要。若内存条没有按主板通道对称安装，或者数据库进程频繁跨处理器访问内存，缓存命中率和查询延迟都可能受到影响。
可执行检查方法
- 根据服务器厂商的主板拓扑核对内存条插槽，优先采用各通道容量一致的配置。
- 查看数据库缓冲池命中、系统换页、内存带宽和跨节点访问情况。
- 将数据库实例、日志写入线程和备份任务的资源范围分开测试，再比较延迟变化。
内存扩容适合工作集明显超过现有缓冲区、系统出现换页或缓存频繁淘汰的情况。若内存仍有较大余量，继续加内存的收益可能低于优化查询计划或存储路径。
三、日志与数据文件产生不同的存储压力
数据库日志通常是连续写入并要求较快确认，数据文件则可能包含随机读、批量写和检查点活动。把所有文件放在同一存储池中，容易在批量导入、索引维护或高峰提交时出现存储延迟。
- 先分别测量数据文件、日志文件、临时文件和备份目标的读写延迟，而不是只看存储设备标称吞吐。
- 优先将日志与数据文件分开规划；高频写入日志需要稳定的低延迟路径，数据文件则要结合容量、随机访问和冗余能力选择。
- 确认控制器缓存保护、磁盘健康状态和文件系统挂载参数，任何一项异常都可能放大提交等待。
本地企业级固态介质通常延迟更低、路径更短，适合对提交时间敏感的系统；集中式存储便于共享和统一管理，但要额外验证网络链路、控制器队列及故障切换时间。
四、网络并非只有带宽问题
数据库物理机与应用服务器、备份服务器、存储设备之间的通信，可能受丢包、网卡队列、链路聚合配置和中断分布影响。带宽没有跑满，不代表网络路径稳定。
- 分别检查客户端连接、存储访问和备份传输三类流量，不要用单一吞吐指标代替延迟和丢包判断。
- 核对网卡固件、驱动、双工状态、交换机端口错误计数及链路聚合两端配置。
- 在业务低峰进行短时压测，观察连接建立、事务提交和备份传输是否互相影响。
若应用连接数量较多，应结合连接池、操作系统文件描述符和网卡中断分布一起调整。网络中断集中在少数处理器时，可能出现局部繁忙而整体利用率不高的现象。
五、备份恢复与日常维护互相争抢
全量备份、增量备份、统计信息收集和索引维护，都可能消耗存储带宽、处理器时间及网络资源。数据库物理机优化不能只看白天交易，还要覆盖备份窗口和恢复演练。
安排维护的具体步骤
- 列出全量备份、日志归档、报表、数据清理和补丁维护的开始时间、持续时间及资源类型。
- 错开高写入任务与大规模备份，必要时限制备份线程或设置带宽上限。
- 定期在隔离环境验证恢复链路，记录恢复所需时间、日志完整性和应用重新连接步骤。
只保存备份文件而不验证恢复，无法证明备份恢复真正可用。恢复目标时间和恢复点目标应由业务负责人确认，再反推备份频率、日志保留周期和设备容量。
六、供电、散热与高可用不能被忽略
物理机长期高负载时，风扇转速、进风温度、处理器降频和电源冗余都会影响稳定性。数据库服务还需要考虑主机、存储路径、网卡和电源模块的单点故障。
- 检查机房进风温度、服务器传感器、风扇状态和电源模块告警，建立异常阈值与通知流程。
- 确认双电源分别接入不同供电路径，并验证单路断电不会导致主机停止服务。
- 为主机故障、存储故障和网络故障分别设计切换方案，明确人工介入步骤和回切条件。
- 在维护前确认数据库复制状态、备份可用性和应用连接切换能力，避免只验证硬件而忽略业务层。
高可用架构不能替代容量规划。若主备服务器规格差异过大，故障切换后可能出现响应下降；若复制链路依赖同一交换设备或电源路径，冗余也可能失去实际意义。
上线前如何验收数据库物理机优化
建议用接近真实业务的测试数据验证，而不是只运行单一读写基准。测试至少覆盖高峰事务、批量导入、备份、故障切换和恢复五类路径，并同时记录响应时间、锁等待、存储延迟、网络丢包、温度和错误日志。
每次只改变一个主要变量，例如内存布局、文件存储位置或备份限速，保留调整前后的监控记录。这样才能判断收益来自哪里，也便于出现异常时快速回退。完成验收后，应把配置、巡检周期、告警联系人和回滚步骤写入运维文档。
常见问题
1. 物理机配置越高，数据库就一定越快吗？
不一定。慢SQL、锁竞争、存储延迟和错误的内存拓扑，都可能让高规格硬件无法发挥作用。
2. 应该先升级内存还是存储？
若存在换页、缓冲区不足或工作集明显超出内存，优先评估内存；若提交等待和随机读延迟突出，则应先检查存储路径。
3. 本地存储一定优于集中式存储吗？
不一定。本地存储通常延迟较低，集中式存储则更便于统一管理和共享，最终要结合故障恢复、容量扩展和网络稳定性选择。
4. 优化后多久复查一次？
高峰业务、硬件变更或数据库版本升级后应立即复查；稳定系统也应按月检查容量、延迟、备份恢复和硬件告警。持续监控是数据库物理机优化长期有效的基础。
