数据库管理-第381期 游戏VS数据库，性能优化的异同（20251029）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE
10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809
IFClub：胖头鱼的鱼缸
除授权转载并标明出处外，均为“非法”抄袭

最近《战地6》终于发售了，虽说还存在一些小问题，但对比《战地2042》刚上线时的拉胯表现，已经好太多了——以至于我工作之余一玩就停不下来。不过游戏过程中也遇到了烦人的性能问题：帧数偏低不说，显存占用直接拉满，CPU使用率也常年飘红。

要知道我的配置不算差：CPU是 AMD Zen3架构的5900X（当年X3D系列没出来时，它可是长期霸占“最强游戏CPU”宝座，甚至压制了英特尔四代产品），显卡也是3080Ti。可即便这样，游戏平均帧数居然超不过70，偶尔还会骤降到30帧左右，不仅体验差，玩久了还会头晕。

这事儿倒让我想起了数据库维护 —— 想获得好体验，游戏也得像数据库一样做优化。通过性能监控，我先锁定了两个核心问题：

1. CPU占用率持续过高
2. 显存占用直接 “爆炸”

简单分析下就知道：CPU占用过高（或性能不足）会拖累GPU，而GPU显存超限又会反过来影响CPU表现，二者必须同时解决。于是我先试了两个方向：

1. 游戏没正确识别CPU核心数（寒霜航空老传统了），导致资源分配混乱。我手动生成了配置文件，帮游戏匹配CPU信息——这一步确实有效，CPU占用降了不少，至少不会频繁卡死了
2. 用Nvidia APP自动优化，再手动调低那些 “吃显存但对画质影响小” 的特效，试图压减显存占用

可第二点做完后，效果却不明显：显存依然爆满，甚至偶尔还会出现显存OOM的情况。上周末在上海出差，起飞前去网吧体验了下新硬件，才真切感受到自己的电脑确实老了——硬件性能已经跟不上游戏需求，似乎到了该换新的地步。

但转念一想，这和数据库维护多像啊：当数据量、并发量达到一定层级，就算做完了必要优化，若仍超过硬件承载能力，确实得升级硬件。可问题是——我真的做完 “必要优化” 了吗？

回头看，第一点优化只是纠正了配置错误，第二点更像是“百度搜方案”或“甩给AI优化”，根本没找到性能劣化的根源。这就好比数据库优化时，在16核机器上把CPU占用从4核调度到16核，简单给表加了个索引，却没解决核心问题，性能自然上不去。

于是我开始复盘过去两周的操作：

• 游戏性能是上周才突然变差的，上线第一周其实还是相对流畅
• 前周末刚给电脑清了灰，还换了一块出现0E错误的SSD

想到这里突然恍然大悟：清灰换SSD后电脑开不了机，我当时重置了主板BIOS——这一下把BIOS里的所有自定义配置都清掉了！而这恰恰是性能雪崩的关键：

• CPU自动超频PBO没开
  我的主板供电能力很强，可CPU一直跑在默认频率，性能根本没释放出来
• 内存XMP没开
  我用的是B-die颗粒的DDR4内存，XMP预设是3600MT/s高频低时序，可重置后一直跑在2133MT/s的默认频率+高时序——内存带宽和延迟直接带来了倍数的差距，内存的配置问题也直接导致了和GPU交互能力不佳，游戏能不卡吗

重新开启CPU PBO和内存XMP后，《战地6》的性能终于回归正常：虽然没到极 致，但平均帧数能稳定在100以上，最低也不会低于80。这件事给我的数据库维护工作带来了三点重要启发：

1. 优化要 “软硬兼顾”，别只盯着数据库层面
   很多时候我们会陷入“思维定式”，遇到数据库性能问题就只查 QL、索引、参数，却忽略了硬件层的隐患。比如我最近碰到一套他人维护的RAC集群，频繁出现莫名其妙的性能问题，数据库层面查了半天也没缓解。直到检查分布式存储才发现：所有SSD都超过了设计寿命，部分已经出现坏块，甚至有1块SSD和1块HDD已经彻底挂了！这套数据库能“活着”，全靠ASM的冗余机制硬撑——更要命的是，它既没开归档，也没备份和容灾，再坏几块盘就彻底没救了。回头想想那些“莫名其妙的问题”，大概率就是这些故障磁盘在搞鬼。
2. 变更要 “留痕评估”，避免 “隐性影响”
   这次游戏性能问题，本质上是我在清灰换SSD后，对“重置BIOS”这个变更操作的评估不足——没意识到会清空核心配置；而且变更前后没做记录，出问题后花了好久才想起“重置BIOS”这个细节。这和数据库日常维护的坑太像了：很多人做变更时（比如改参数、换硬件、迁存储），要么不评估影响，要么不记录操作；下次再遇到问题，既记不清之前的配置，也没法快速定位变更关联的隐患，最后只能在排查上浪费大量时间。
3. 基础配置是“性能基石”，切勿轻视
   CPU PBO、内存XMP，看似是“不起眼的基础配置”，但一旦缺失，哪怕硬件再高端，性能也会打骨折；数据库维护里也有大量类似的 基础配置，却常被忽视：比如数据库服务器没开启存储缓存加速，Oracle的SGA/PGA参数没按硬件规格合理分配，操作系统IO调度器或时钟源没适配数据库场景。我曾遇到过一套Oracle数据库，因部署时没检查、调整时钟源，导致数据库性能很差，业务频繁卡顿；直到核查基础配置时才发现问题，调整后性能立刻恢复。这说明：无论是硬件还是数据库，“基础配置”就像地基——地基不稳，再高端的架构和硬件也发挥不了作用。

本期有瞎扯了一期。
老规矩，不知道写了些啥。