数据库要跑得快，底层存储不能拖后腿，针对数据库这类对延迟极其敏感的负载，块存储是提供高性能卷的首选方案，其低时延、高IOPS的特性，远非对象存储或本地盘可比。
很多团队在云上部署数据库时，常遇到响应慢、事务堆积的情况，排查到最后，发现SQL语句没问题，索引也建了，瓶颈却出在数据落盘的环节，应用层优化得再好，存储层跟不上，数据库就得卡脖子，今天不聊虚的，就直接拆解块存储为什么天生适合数据库,以及怎么把它用好。
为什么数据库偏爱块存储而不是对象存储
要搞清楚这个，先得明白数据库读写数据的基本单位，数据库引擎（比如MySQL的InnoDB）操作数据，是按页（Page）进行的，默认一页通常是16KB，它需要的是能按固定大小、随机位置去读写的“裸”设备,这就和块存储的底层逻辑对上了。
- 块存储提供的是一个虚拟磁盘，操作系统能看到盘符，格式化后挂载到目录（比如
/data）,数据库可以当作普通硬盘来用。 - 它不认文件名，只认地址，应用发来一个“写入第10000个块”的请求，存储系统直接定位到物理位置完成写入，数据路径短，开销小,延迟自然低。
- 相比之下，对象存储（如OSS、S3）走的是HTTP协议，一次写操作要经历DNS解析、建立连接、上传请求、返回响应等多个步骤，延迟通常在几十毫秒到上百毫秒，这个延迟对OLTP数据库来说,是灾难性的。
行业共识认为，块存储是数据库系统的标准配置，尤其是生产环境，几乎没有哪个DBA敢把核心业务库直接架在对象存储上，块存储和对象存储的区别，就好比本地餐厅的厨房直供和外卖平台的跨城配送，前者提供的是即时可用的餐桌服务,后者则隔了一层网络与协议转换。
高性能块存储的关键指标：IOPS与时延
既然选择了块存储，那怎么判断一块云盘（块存储的云上形态）算不算高性能？主要看两个硬指标。
IOPS决定了每秒能处理多少读写请求
- 数据库每执行一次查询或提交事务,都可能产生多次随机磁盘IO。
- 高并发场景下，比如电商大促，每秒可能有成千上万个事务，每个事务涉及数次IO,加起来吞吐量惊人。
- 如果块存储的IOPS上限太低，数据库就会频繁的“等待磁盘IO”，也就是我们常说的
iowait飙高，此时即使CPU还有空闲,整个业务也已经卡死了。
时延决定了单次请求有多快
- 延迟，指的是发出一个IO请求到收到确认的时间，单位是毫秒（ms）甚至微秒（μs）。
- 对数据库而言，时延直接决定了事务提交的速度，写入日志（redo log）时的fsync操作，必须等待数据真实落盘才能返回成功，如果存储时延是2ms，那每秒最多只能完成500次fsync；如果时延能压到0.2ms，每秒就能完成5000次fsync。这是数量级的差距。
- 高性能云盘普遍采用NVMe协议和RDMA网络，能把单次读时延压到1ms以内,甚至百微秒级。
表：块存储与对象存储核心指标对比
| 对比项 | 块存储（云盘） | 对象存储（OSS） |
|---|---|---|
| 访问协议 | NVMe、SCSI（使用内核块层） | HTTP/HTTPS（RESTful API） |
| 时延水平 | 亚毫秒级至毫秒级 | 数十毫秒级 |
| IOPS能力 | 单盘可超百万（最新一代ESSD） | 受API调用及带宽限制，适合大文件并发 |
| 适用场景 | 数据库、容器持久化、日志存储 | 备份归档、静态文件分发、大数据分析 |
场景化选型：不同数据库到底该配什么卷
选块存储，不等于闭眼买最贵的，不同类型的数据库，对存储的需求侧重也不同，现在主流云厂商都提供了多种云盘类型,用我们最常见的几种业务形态来聊聊。
核心OLTP数据库（如MySQL高可用集群）
这类系统是典型的高随机读、高随机写模型,对时延极度敏感。
- 首先排除共享型云盘，那是给高可用架构的仲裁盘用的,性能一般。
- 优先考虑ESSD（增强型SSD云盘） 这类产品，据公开资料,简米云最新的ESSD极限性能已能做到单盘百万级IOPS和百微秒级访问时延。
- 选择时，除了看IOPS，还要关注单路时延和写稳定性。4KB随机读时延是衡量盘片好坏的金标准,数值越低越好。
分析与日志类数据库（如ClickHouse、Elasticsearch）
这类系统的特征是顺序写多，随机读多,但单次IO的数据块比较大。
- 这类数据库往往追求吞吐带宽,对时延容忍度稍高。
- 可以搭配高效云盘或通用型SSD，把预算花在更大的容量上，而不是盲目追求极致QoS（服务质量）。
- 注意，这类系统常做冷热分离，热数据放高性能块存储，冷数据转到对象存储,成本能节省一大块。
超大规模数据仓库（如云原生的数仓服务）
这类场景已经不太强调单块盘的性能，而是利用存储计算分离架构,通过分布式文件系统把负载分散到海量盘上。
- 底层每块盘依旧需要块存储，但对于用户而言,关心的更多是整体吞吐性能。
- 在选择云服务器数据盘方案时，会倾向于选择大容量、高吞吐的云盘类型,并按需扩容。
实操落地：从购买到挂载的每一步
理论聊完，来点实际的，这块重点在于通过云服务器ECS数据盘方案对比，搞清楚在典型场景里,怎么选择合适的块存储。
-
在云厂商控制台购买云服务器ECS时，会提示选择系统盘和数据盘，系统盘默认是块存储，但通常容量较小，仅用于存放操作系统。数据库数据目录，一定要放在单独购买的数据盘上,避免日志灌满系统盘导致宕机。
-
在选购数据盘时，需要指定云盘类型、容量和性能级别，在北京或上海的可用区，选择一块100GB的ESSD PL1，和选择一块100GB的高效云盘，价格会有差距（ESSD单价更高，但性能更好），我们要按需申请,不要盲目追求PL3级别而忽略了成本。
-
购买成功后，登录ECS实例，在控制台或使用API挂载这块磁盘到指定的设备名（如
/dev/vdb）。 -
接着在实例内执行命令进行初始化,步骤如下：
-
查看磁盘是否识别成功：
lsblk // 查看/dev/vdb是否存在
-
对数据盘分区，并格式化为xfs或ext4文件系统（以xfs为例）：
mkfs.xfs /dev/vdb
注意：格式化会清空数据，请务必确认是对新买的空盘操作。
-
创建挂载点目录,并挂载到指定路径：
mkdir /data mount /dev/vdb /data
-
-
为了让重启后自动挂载,需要把挂载信息写入配置：
echo "/dev/vdb /data xfs defaults 0 0" >> /etc/fstab
-
最后要确认块存储的多路径或RAID策略，如果是单块大容量盘，直接使用；如果业务需要更高IOPS，可以考虑在操作系统层面用LVM做软RAID0，但这会增加运维复杂度，对于生产环境，更推荐直接购买云厂商性能更高一档的云盘，因为云盘底层已经用分布式多副本解决了数据安全问题,无需我们人为做RAID。
选出适合自己的高性能卷
综合来看，为数据库选块存储，就是考量性能、成本、容量与安全之间的平衡。
- 追求极致性能且预算充足，首选新一代ESSD系列（如ESSD PL3或更高），它会成为数据库说走就走的底气数据库需要的是低延迟，给足它,性能自然不会差。
- 性能与成本兼顾，选择通用型SSD或ESSD Entry级别，搭配InnoDB的
innodb_flush_log_at_trx_commit配置优化,也能在多数业务场景下交出不错的表现。 - 对容量需求远大于性能，用高效云盘承载冷数据或备份文件,把高性能块存储资源留给最关键的热数据。
核心思路只有一条：让块存储真正专注于它最擅长的数据块随机读写，那么数据库引擎的所有特性才能完全施展开来。 这是数据库调优中最基础,也往往最容易被忽视的一环。
块存储性能不够怎么办
如果iostat显示%util接近100%，且svctm明显增大，说明盘确实忙不过来，先检查云盘类别，是否买成了入门级，如果是，直接在线扩容或更换更高性能等级（如从一般ESSD升到PL2），这在云上按几个按钮就能完成，同时不如花一点时间，把慢查询日志扒出来，看是不是哪些SQL扫了太多行数据,造成不必要的IO。
块存储满了，如何安全扩容
云盘扩容优先利用云控制台的无损扩容功能，在控制台上将容量从100GB调整到200GB，然后回到服务器内执行growpart扩展分区，再执行xfs_growfs扩容文件系统，整个过程无需卸载盘，也不会中断数据库服务，有关简米云块存储具体价格，可以参阅其官网最新的云盘报价页中不同地域的按量计费方案，选择上海地域包年包月和使用自动快照策略往往组合优惠更多。
在数据库这条高速公路上，块存储既是路基，也是燃料，把这块地基夯实了，后面做再多的SQL优化和缓存调整,才算真正有了用武之处。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/645897.html
