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

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

一. 案例

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

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

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

二．小批量验证

为了减少替换带来的影响，先从影响小的下手。先把其中４个分片的从节点替换为了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倍。

梳理的比较的格式如下:

3.2 分析DDL操作

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

知识补充

涉及 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执行时间长，出问题的风险就变大。拿过往的经验举个例子，添加索引，

按照官方的说明，添加索引无需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,难解。

3.3 对主从延迟的影响

类似于 慢查询 的现象，通过监控数据分析，发现SATA SSD 发生主从延迟的概率增加了很多，并且延迟值明显比对照组的要大。

主从延迟不仅会影响的业务的读写分离，还会影响主从切换，影响高可用。

3.4 其它影响

分析最近的一次OOM切换，恰恰发生在SATA SSD的节点上。此外，虽然orchestrator对其进行了主从切换，但中间有3个事务丢失，和业务确认后，DBA需手动补全。

OOM和数据丢失与性能的关系，还需要更多的理论解析和实践说明，但需留意。

四. 概况总结

从直观来看，资源降配看似对应用系统的影响不大，但对运维和高IO的操作来讲，会带来很大的挑战。

建议

（1）针对慢查询，请研发确认是否可以接受、是否可以优化改进SQL语句；

（2）针对DDL的耗时增加，需要评估是否可以接受，是否可以对MySQL版本进行升级，例如升级到8.0；

（3）细化监控、增加完善及时告警；如有异常，可以及时止损。

后记

这种境况，让我联想到“坐船渡河”。

求学时，初中在黄河东岸，老家在黄河西岸，平常来往都是通过浮桥。但汛期时，因为浮桥会影响水速，都要拆掉，这段时间过河，只能坐船。

坐过的船有小木船和大铁船。真正体验过小木船“随浪飘荡，起起伏伏”、“心提到嗓子眼”。

两种船都可以摆渡，都可以把人从这岸送到彼岸。但是，考虑到 安全性、稳定性、舒适性 等，大铁船慢慢完全替代了小木船。