过去这一年，服务器成本经历了普遍且剧烈的上涨，其核心硬件--内存（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,难解。
3.3 对主从延迟的影响
类似于 慢查询 的现象，通过监控数据分析，发现SATA SSD 发生主从延迟的概率增加了很多，并且延迟值明显比对照组的要大。
主从延迟不仅会影响的业务的读写分离，还会影响主从切换，影响高可用。
3.4 其它影响
分析最近的一次OOM切换，恰恰发生在SATA SSD的节点上。此外，虽然orchestrator对其进行了主从切换，但中间有3个事务丢失，和业务确认后，DBA需手动补全。
OOM和数据丢失与性能的关系，还需要更多的理论解析和实践说明，但需留意。
四. 概况总结
从直观来看，资源降配看似对应用系统的影响不大，但对运维和高IO的操作来讲，会带来很大的挑战。
建议
（1）针对慢查询，请研发确认是否可以接受、是否可以优化改进SQL语句；
（2）针对DDL的耗时增加，需要评估是否可以接受，是否可以对MySQL版本进行升级，例如升级到8.0；
（3）细化监控、增加完善及时告警；如有异常，可以及时止损。
后记
这种境况，让我联想到"坐船渡河"。
求学时，初中在黄河东岸，老家在黄河西岸，平常来往都是通过浮桥。但汛期时，因为浮桥会影响水速，都要拆掉，这段时间过河，只能坐船。
坐过的船有小木船和大铁船。真正体验过小木船"随浪飘荡，起起伏伏"、"心提到嗓子眼"。
两种船都可以摆渡，都可以把人从这岸送到彼岸。但是，考虑到 安全性、稳定性、舒适性 等，大铁船慢慢完全替代了小木船。