当前位置：首页 > news >正文

关于数据库服务器资源降配的效能分析

news 2026/4/20 0:38:50

过去这一年，服务器成本经历了普遍且剧烈的上涨，其核心硬件--内存（DRAM）和固态硬盘（NAND/SSD）--同样经历了爆炸式增长。例如，30TB容量的企业级SSD在2025年第二季度至2026年第一季度期间，价格累计上涨了约 257%。硬件成本的上涨迫使许多企业重新评估其存储架构。DBA自然也会面对这对压力。

本文没有偏重一般分析报告常用的压测对比，而是基于线上运行效果的差异进行比较分析。

一. 案例

目前公司的订单中心是MySQL分片集群，其有128个分片组成，使用的固态硬盘是NVMe SSD。库存中SATA SSD比较富裕，NVMe SSD相对紧张，因而，需要DBA评估用SATA SSD替代NVMe SSD的可行性和风险。

直接看下两者的关键区别：

对比维度	SATA SSD	NVMe SSD
本质区别	使用为机械硬盘设计的旧协议 (AHCI)	使用为闪存设计的专属新协议 (NVMe)
通信接口	SATA 接口，带宽上限约 600 MB/s	PCIe 接口，直连CPU，速度无上限
速度表现	顺序读写约 550 MB/s	顺序读写可达 3,500 ~ 14,000+ MB/s
响应延迟	较高（约 100 微秒）	极低（约 10-20 微秒）

其读/写性能差异很是很大的。

二．小批量验证

为了减少替换带来的影响，先从影响小的下手。先把其中４个分片的从节点替换为了SATA SSD，从节点有部分读业务，观察运行两周，其CPU、内存、IOＷait、TPS、QPS等指标运行还是平稳的，也在合理的区间；和 NVMe SSD 横向相比，CPU、IOＷait指标有增加，但是还可以，内存、TPS、QPS的变化不明显。

两周后，将这4个从节点升级成了主节点。

即目前 128套集群，有4套运行在 SATA SSD，124套运行在了 NVMe SSD 上。

切换3个月来，业务系统运行还算正常。

三分析与总结

如果只是从小批量试运行的效果来看，是令人满意的。可是不是就可以放心的替换呢？我们还做了以下分析。

3.1 分析慢查询

将这4个SATA SSD的服务器划为一组，再随机抽取5个 NVMe SSD划为对照组，分析慢查询的情况。

慢查询的数据量增长了3.7倍。

梳理的比较的格式如下:

比较	NVMe SSD	SATA SSD
慢查询总数
慢查询执行时间的中位数
>=6S 慢查询的数量
<6S &&&>=4S 慢查询的数量
<4S &&&>=2S 慢查询的数量

3.2 分析DDL操作

这个一定要分析总结，但也容易被忽略。因为DDL操作是MySQL 最耗资源的一种操作，当然也是运维的核心变更之一。系统使用的MySQL版本是5.7，所以选择什么样的DDL语句才能说明问题是关键。

知识补充

Operation	In Place	Rebuilds Table	Permits Concurrent DML	Only Modifies Metadata
Adding a column	Yes	Yes	Yes*	No
Dropping a column	Yes	Yes	Yes	No
Renaming a column	Yes	No	Yes*	Yes
Reordering columns	Yes	Yes	Yes	No
Setting a column default value	Yes	No	Yes	Yes
Changing the column data type	No	Yes	No	No
Extending `VARCHAR` column size	Yes	No	Yes	Yes
Dropping the column default value	Yes	No	Yes	Yes
Changing the auto-increment value	Yes	No	Yes	No*
Making a column `NULL`	Yes	Yes*	Yes	No
Making a column `NOT NULL`	Yes*	Yes*	Yes	No
Modifying the definition of an `ENUM` or `SET` column	Yes	No	Yes	Yes

涉及 Rebuilds Table 的操作都是一个高消耗的操作（消耗的资源比较多，同时执行时间也比较长）。

一定要注意的是修改字段长度不一定不 Rebuilds Table ，其实它有一个零界值的。

The number of length bytes required by a VARCHAR column must remain the same. For VARCHAR columns of 0 to 255 bytes in size, one length byte is required to encode the value. For VARCHAR columns of 256 bytes in size or more, two length bytes are required. As a result, in-place ALTER TABLE only supports increasing VARCHAR column size from 0 to 255 bytes, or from 256 bytes to a greater size. In-place ALTER TABLE does not support increasing the size of a VARCHAR column from less than 256 bytes to a size equal to or greater than 256 bytes. In this case, the number of required length bytes changes from 1 to 2, which is only supported by a table copy (ALGORITHM=COPY). For example, attempting to change VARCHAR column size for a single byte character set from VARCHAR(255) to VARCHAR(256) using in-place ALTER TABLE returns this error:

ALTER TABLE tbl_name ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256);
ERROR 0A000: ALGORITHM=INPLACE is not supported. Reason: Cannot change
column type INPLACE. Try ALGORITHM=COPY.

具体细节参照官网:https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html

言归正传,聚焦最近的DDL操作。

Review替换以来的所有DDL变更，发现在所有的集群中，执行最慢的永远都是这4台SATA SSD的分片，并且执行时间明显的比其它组长很多。

以给150G左右的一张表的添加字段为例，两者相比（NVMe SSD 与 SATA SSD），其执行时间由原来的1.5 小时，增长到了3 小时以上。即DDL的执行时间增长了1.5倍，是原来的2.5倍。

再看添加索引操作。add index虽然无需Rebuilds Table，但是涉及新建index的结构，也是一个耗时操作，从中也能体现两者性能差异。果然如此，耗时最久的依然是SATA SSD的分片，执行时间大大增加了。

不利因素不仅仅是执行时间变本身。此外，DDL执行时间长，出问题的风险就变大。拿过往的经验举个例子，添加索引，

Operation	In Place	Rebuilds Table	Permits Concurrent DML	Only Modifies Metadata
Creating or adding a secondary index	Yes	No	Yes	No
Dropping an index	Yes	No	Yes	Yes
Renaming an index	Yes	No	Yes	Yes
Adding a `FULLTEXT` index	Yes*	No*	No	No
Adding a `SPATIAL` index	Yes	No	No	No
Changing the index type	Yes	No	Yes	Yes

按照官方的说明，添加索引无需Rebuilds Table，允许Permits Concurrent DML。但恰恰是这种操作，引发过两个故障。

故障1，因为add index ,会由大量的io操作，导致DB Server 下降，引发了大量的慢查询和事务堆积。

故障2，这次故障比故障1更严重，读写都不可用了。堆积了大量事务，正在运行的SQL（Threads_running）由平常的10多个快速增长到 600+，堆积无法处理---堆积的事务状态为【Waiting for table flush】。不得不进行kill，Kill Add index 的事务后，系统立马恢复了。

故障2,难解。