技术帮助 · 发布时间：
高性能数据库部署在独占物理机的调优要点，不是把硬件参数一味调到最大，而是先找出读写瓶颈，再用可回退的改动验证效果。独占机器减少了其他租户争抢资源的影响，但存储延迟、内存不足和配置不匹配仍会拖慢查询。以下以 PostgreSQL、MySQL 的常见部署为例，说明如何从存储和内存开始。
先建立基线，再动配置
先选一段有代表性的业务时段，记录查询延迟分位数、磁盘读写延迟、吞吐量、内存占用和缓存命中情况。平均值容易掩盖少数慢请求，建议同时观察 p95、p99。工具如 iostat 可用于查看设备利用率与等待时间；数据库自身的统计视图则帮助区分查询慢、读盘慢还是写入受阻。
- 确认数据库版本、数据目录、日志目录和当前配置，并保存可恢复的配置副本。
- 在相近负载下连续采集基线，不要把一次短暂峰值当作长期问题。
- 每次只改一类参数，记录变更时间、负载条件和回退方式。
存储：让数据读写路径清楚
数据库写入既包含数据页，也包含事务日志。若设备布局允许，可将事务日志与主要数据文件放在不同存储设备上，降低高写入场景下的相互干扰；若它们最终仍共享同一控制器或设备，分目录本身不会带来独立的物理吞吐能力。备份文件也不宜与在线数据争用同一高速存储空间。
关注延迟，而不只看标称速度
选型时查看设备的持续读写能力、随机访问表现和断电保护说明，并结合数据库实际工作负载验证。低延迟随机读写对事务型请求通常更重要；连续吞吐则对批量导入、备份等任务更有参考价值。测试可先在非生产环境使用 fio 模拟接近实际的读写模式，确认测试文件位置与业务数据存储相符。合成测试结果不能直接等同于线上性能。
检查文件系统和挂载参数时，应遵循所用操作系统及数据库版本的文档，不要照搬他人的参数。对写入延迟敏感的场景，还要核实设备是否正确处理写入刷新请求；不能仅凭缓存开启就认定数据具有可靠的持久性。
内存：按数据库引擎分配
独占机器并不意味着内存可以全部交给数据库。操作系统仍需内存用于文件缓存和后台服务，数据库也会为连接、排序及并发查询临时占用空间。预留量应根据连接数、查询复杂度和峰值负载实测，避免持续交换到磁盘。
- PostgreSQL：shared_buffers 可从物理内存约四分之一作为评估起点，但这不是固定答案。还需结合操作系统缓存、并发查询和工作内存的总占用，观察命中率与内存压力。
- MySQL：使用 InnoDB 时，innodb_buffer_pool_size 通常可占专用数据库服务器内存的较大部分；具体比例要为连接缓冲、临时表、操作系统和监控进程留出空间。连接数高或查询复杂时，更不能只按空闲内存调大缓冲池。
两种引擎的缓存机制并不相同，不要直接复制参数值。先检查实例是否频繁发生磁盘读取或交换，再小幅调整缓冲池；每次调整后观察完整业务周期，确认延迟改善且内存没有逼近耗尽。高性能数据库部署在独占物理机的调优要点，核心正是让容量配置与实际访问模式相匹配。
按步骤验证改动
- 用监控确认瓶颈属于随机读、持续写、日志刷新还是内存不足。
- 针对一个瓶颈调整一项设置，例如缓冲池大小或日志存储位置。
- 使用相同或相近的负载重新观察 p95、p99、设备延迟和内存余量。
- 若收益不稳定、出现交换或其他查询退化，立即恢复配置并重新分析。
记录基线、限制并发风险、逐项验证，比一次性套用所谓最佳参数更可靠。高性能数据库部署在独占物理机的调优要点，应落实为可测量、可回退的日常流程。
常见问题
存储与内存应该先调哪一个？
先根据监控定位瓶颈。读写等待明显时优先检查存储路径；出现交换或缓存不足迹象时再评估内存配置。
数据和事务日志必须分盘吗？
不是必须。分开设备有机会减少相互干扰；资源有限或负载较轻时，先测量再决定，单纯分目录不等于分盘。
缓冲池设得越大越好吗？
不是。还要为操作系统、并发连接和临时查询留出空间，应根据内存压力与业务表现逐步调整。
多久需要重新评估配置？
数据规模、并发量或查询类型明显变化时应复查；平时也可定期对照基线，确认原有配置仍适用。
