专属物理节点减少了其他租户争用，但数据库仍可能受处理器调度、内存回收、存储延迟和网络拥塞影响。落实数据库部署在专属物理节点的优化方法，应先记录业务高峰时的延迟与资源指标，再判断瓶颈，而不是先提高连接数或缓存上限。
先定位：看持续趋势，不盯单个峰值
分别观察正常时段、高峰时段和批量任务期间的数据。Linux 上可用 vmstat 1 查看运行队列、换页和等待情况，用 iostat -xz 1 检查设备延迟与队列；numastat 可帮助判断内存访问是否跨 NUMA 节点。工具指标要结合数据库慢查询、事务延迟和应用侧超时一起看。
- 先记录基线：查询响应时间、吞吐量、连接数、检查点或日志写入情况。
- 在负载相近时采集系统数据，至少覆盖一个业务高峰；短暂尖峰不一定代表持续瓶颈。
- 一次只调整一个主要参数，并保留回退值，比较调整前后的同类时段。
四类资源瓶颈及调整方向
处理器：并发不等于有效吞吐
若运行队列长时间高于可用处理器数量，且数据库查询延迟同步上升，可能是计算压力或并发过高。检查执行计划、索引和锁等待，再评估并行查询、连接池大小。PostgreSQL 与 MySQL 的并行执行配置不同，不能照搬同一组数值；小查询占多数时，盲目提高并行度反而会增加调度开销。
内存：避免缓存挤压和换页
数据库缓存、操作系统页缓存以及备份、监控等进程会共同占用内存。持续出现换页、进程被系统终止，或缓存命中率下降时，应检查实际工作集和连接数，而非只扩大缓冲区。对专用节点，可把数据库缓存从物理内存的约 60%—70%作为初始评估区间；该范围仅适用于其他服务占用较少的情形，需为系统、连接工作区和维护任务留出余量。
存储：分清吞吐不足与延迟过高
随机读写、顺序写入和同步提交对存储的要求并不相同。重点观察读写延迟、队列深度与数据库等待事件；如果日志落盘延迟突出，单看总吞吐量可能会漏掉问题。用与真实数据块大小、读写比例和队列设置接近的基准测试验证设备，不要在生产数据目录上直接做破坏性测试。检查文件系统空间、后台检查点和备份是否与业务高峰重叠。
网络与 NUMA：本机也可能受拓扑影响
远程应用访问数据库时，检查网卡错误、丢包和带宽占用；同一机架内的低延迟链路，也可能因突发流量出现排队。对于多路处理器平台，确认数据库进程、内存分配与设备中断的 NUMA 位置是否合理。跨节点访问并非必然有问题，但若伴随延迟升高，应结合 numastat 和系统拓扑逐项验证，避免未经测试就绑定进程。
按风险排序实施优化
- 先修正查询、索引、事务范围和连接池，减少不必要的工作量。
- 再依据监测结果调整缓存、并行度或日志与检查点策略；每次只改一类设置。
- 在相同负载下复测延迟、吞吐和资源使用，并检查备份、恢复及故障切换是否仍符合要求。
- 记录参数、软件版本和回退步骤；升级内核、固件或数据库版本前，先在可控环境验证兼容性。
简而言之，数据库部署在专属物理节点的优化方法不是追求某项指标越高越好，而是让资源消耗与业务负载匹配。先定位瓶颈，再小步调整，才能避免把硬件余量变成新的配置风险。
常见问题
专属节点还需要限制数据库连接数吗？
需要。每个连接都可能占用内存和调度资源，宜使用连接池，并按并发实测设置上限。
看到存储利用率高，就一定要换设备吗？
不一定。先看延迟、队列和数据库等待类型，并排除备份或检查点造成的短时负载。
参数调整后多久判断效果？
应覆盖有代表性的业务周期；若负载有明显日内变化，至少比较相同类型的高峰时段。
NUMA 绑定是否必须开启？
不是。只有监测显示跨节点访问与延迟相关时，才值得在测试环境评估绑定策略。