Linux磁盘管理实战：从服务器选型到LVM扩容一次做对

Linux 磁盘管理实战：服务器选型与配置，到底该怎么一次做对？

很多刚接触服务器运维的同学，第一次拿到一台物理机或云主机时，会有一个共同的困惑：CPU、内存看得懂，唯独磁盘这块，到了选型环节就犯难。SSD 和 HDD 怎么搭？RAID 卡要不要配？文件系统用 ext4 还是 xfs？LVM 到底有没有必要上？更麻烦的是，这些问题如果在上线前没有想清楚，等业务跑起来再改，就涉及到数据迁移、应用停机、回滚方案，成本会成倍上升。

磁盘管理看似是一堆命令的堆砌，但真正的难点从来不是fdisk怎么用，而是你用什么标准去做选型决策。磁盘选型选错了，后续无论文件系统怎么调优，IO 瓶颈都很难根治；反过来，选型合理但配置流程不规范，同样会在扩容、故障恢复时付出代价。

这篇文章从服务器选型和磁盘配置两个维度展开。前半部分讲选型思路：怎么根据业务类型判断 IOPS 和吞吐量的优先级，怎么组合 SSD 与 HDD，RAID 和 LVM 各自解决什么问题；后半部分是操作流程：从磁盘识别、分区、格式化、挂载，到 LVM 扩容和性能验证，把每一步命令、原理和容易踩的坑讲清楚。无论你是在采购服务器，还是准备给现有机器做存储规划，这篇文章都值得收藏备用。

1. 这篇文章真正要解决的问题

如果你只是偶尔在一台测试机上执行mkfs.ext4然后挂载目录，那你可能感受不到磁盘管理的复杂性。但一旦进入生产环境，问题就变了。

第一个痛点是选型没有评判标准。很多团队买服务器时只看 CPU 核数和内存大小，磁盘只写“SSD 500G”或“HDD 2T”，完全不区分业务是随机读写密集还是顺序读写密集。结果数据库服务跑在 SATA 盘上，日志服务却占着高 IOPS 的 NVMe 盘，资源错配导致性能问题和成本浪费同时出现。

第二个痛点是配置方式不可演进。系统装完直接分区格式化，没有预留 LVM，没有规划挂载点。等到数据盘空间不够，才发现当初没有用 LVM，扩容变得非常被动。或者更糟，根目录和业务数据放在同一个分区，日志把磁盘写满，直接拖垮操作系统。

第三个痛点是对性能验证缺乏手段。磁盘到底快不快，不能靠“感觉”，要用工具量化。很多人配置完磁盘，不去验证顺序读写和随机读写性能，等到数据库压测才发现延迟远高于预期，届时排查链路就长了。

这篇文章要解决的核心问题就是：如何在服务器上线之前，就做出合理的磁盘选型与分区规划；如何在拿到机器之后，用一套标准流程完成配置；如何在配置之后，用量化方法确认磁盘确实达到了预期性能。

如果你正在做以下事情，这篇文章最适合你：

• 为公司采购服务器，需要给运维或云厂商提交磁盘配置清单；
• 收到一台新服务器，准备装 Linux 系统并规划数据盘；
• 现有服务器磁盘空间不足，需要安全扩容；
• 想搞明白 SSD、HDD、RAID、LVM 这些概念在实际项目中怎么组合使用。

2. 基础概念与核心原理：先理解磁盘的“块”世界

Linux 磁盘管理之所以让新手觉得繁琐，是因为它不像 Windows 那样把“C 盘、D 盘”直接呈现给用户。Linux 的存储体系是多层的，理解这一层，后面的命令才有意义。

2.1 从物理磁盘到块设备

一块物理磁盘插入服务器后，内核会把它识别为一个块设备。块设备是 Linux 对存储设备的抽象，数据以固定大小的块为单位读写，你可以把它理解为走廊里的储物柜：每个柜子有编号，系统知道每个柜子放了多少东西，但柜子本身不知道里面装的是照片还是文件。

块设备在/dev目录下以文件形式呈现：

• SATA/SAS 硬盘通常显示为/dev/sda、/dev/sdb；
• NVMe 固态硬盘通常显示为/dev/nvme0n1、/dev/nvme1n1；
• 虚拟化环境中可能是/dev/vda、/dev/vdb。

这里有个关键点：设备名不是永久属性。重启后或者内核识别顺序变化，/dev/sdb可能变成/dev/sdc。因此，生产环境在做配置和脚本时，不能硬编码设备名，而应该使用/dev/disk/by-uuid/或/dev/disk/by-id/这类稳定路径。

2.2 分区、文件系统与挂载点

磁盘设备本身是一块“空地”，要让它能被 Linux 文件系统使用，通常经过三步。

分区是把一块物理磁盘划分成多个逻辑区域。为什么要分区？一是可以做隔离，比如系统区和数据区分开，日志写满不至于拖垮系统；二是可以绑定不同的文件系统策略或挂载选项。

文件系统是管理分区上数据的组织格式。Linux 上常见的ext4、xfs、btrfs各有侧重点。文件系统决定了文件名怎么存储、空间怎么分配、崩溃后怎么恢复。

挂载点是一个目录，把文件系统“接入”到目录树。执行mount /dev/sdb1 /data之后，访问/data就是在访问这块分区。如果不挂载，设备虽然存在，但用户无法通过目录去读写文件。

从物理盘到可用空间的流程可以概括为：

物理磁盘 -> 分区 -> 创建文件系统 -> 挂载到目录 -> 应用读写

2.3 磁盘选型必须理解的两个性能指标

服务器选型时，厂商给的参数表里常见“顺序读写”和“IOPS”两个词。它们的含义差别很大，业务场景的适配度也完全不同。

顺序读写关注的是吞吐量，单位通常是 MB/s，适合大文件连续读写的场景，比如视频处理、日志归档、大数据分析。HDD 的顺序读写其实不差，大容量盘可以跑到 200MB/s 左右。

IOPS 关注的是每秒能处理多少次输入输出操作，单位是次/秒，适合大量小文件随机读写的场景，典型代表是数据库、消息队列、频繁更新状态的 Web 应用。HDD 的随机 IOPS 很低，通常只有 100 到 200；而 SSD 的随机 IOPS 可以达到数万甚至数十万，这个差距是数量级的。

一个非常直观的判断方式是：如果你的业务是 MySQL、Redis、Elasticsearch、Kafka 这类对单次请求延迟敏感的服务，优先看 IOPS；如果你的业务是备份、视频流、日志收集这类大块连续读写，优先看吞吐量。大多数生产环境都是混合负载，所以服务器通常采用 SSD 与 HDD 混插，而不是只用一种盘。

2.4 观点：选型不是选“最快的盘”，而是选“最匹配的层级”

市面上 SSD 也分三六九等。SATA SSD 接口带宽约 550MB/s，NVMe SSD 可以轻松跑到 3000MB/s 以上。但 NVMe 盘的价格也远高于 SATA SSD。一个常见的误区是“反正都要快，全部上 NVMe”。结果就是成本激增，但业务本身是顺序写日志，根本吃不满 NVMe 的性能，等于花高价买了一堆用不上的指标。

更稳妥的做法是分层规划：操作系统和核心数据库用 NVMe 或高性能 SSD，保证延迟；应用日志和临时文件用 SATA SSD；冷数据和备份用大容量 HDD。这样既保证关键业务体验，又把单位存储成本降下来。

2.5 常见概念对比表

这个表格是选型的基础。后面配置流程中的很多决策，都源自这个分层逻辑。

3. 环境准备与前置条件

本文的实操基于 Linux 环境。具体发行版推荐 CentOS 7+、Rocky Linux、Ubuntu 20.04+ 或 Debian 11+，本文命令以通用 Linux 命令为主，版本差异不影响核心操作。

3.1 需要准备好的条件

• 一台已经安装 Linux 的服务器，或者一个有root权限的虚拟机；
• 至少一块额外的数据盘（模拟场景：系统盘已就绪，另加一块盘用于数据）；
• lsblk、fdisk、mkfs、mount等基础命令；
• LVM 工具集（通常安装lvm2包）；
• 性能测试工具fio或dd，推荐fio，因为dd只能粗略测试顺序读写，测不了随机 IOPS。

在 Ubuntu/Debian 上安装 LVM 和 fio：

sudo apt update sudo apt install -y lvm2 fio

在 CentOS/Rocky Linux 上安装：

sudo yum install -y lvm2 fio

3.2 查看当前磁盘格局

配置之前，第一步永远是“摸清现状”。不要凭记忆操作，生产环境尤其如此。

lsblk

这个命令以树状结构显示所有块设备、分区、大小、挂载点。执行后你可能会看到类似这样的输出：

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 99G 0 part └─centos-root 253:0 0 99G 0 lvm / sdb 8:16 0 500G 0 disk

这段输出传递了几个信息：sda是系统盘，已经被 LVM 管理；sdb是一块 500G 的全新磁盘，未分区、未挂载。我们的配置目标就是这块sdb。

需要特别注意：在操作磁盘前，务必确认设备名。如果误把系统盘当成数据盘格式化，后果是灾难性的。确认方法包括：

lsblk -f df -hT

lsblk -f显示文件系统类型和 UUID，df -hT显示当前已挂载文件系统。通过交叉确认，能最大程度避免误操作。

4. 核心流程拆解：从识别到挂载的标准路径

拿到一块新数据盘，无论后续是否使用 LVM，标准路径都是：识别设备 -> 分区（或直接建 PV）-> 创建文件系统 -> 配置挂载 -> 写入开机自动挂载。

下面拆解每一步做什么、为什么、容易错在哪里。

4.1 识别新磁盘

lsblk

如果磁盘是云厂商新挂载的，通常已经能在系统中看到；如果看不到，可能是云控制台没有挂载，也可能需要echo 1 > /sys/class/scsi_disk/0:0:0:0/device/rescan这类操作触发内核重新扫描。物理机新增磁盘通常重启或扫描后即可识别。

4.2 分区还是整块使用？

传统做法是先用fdisk划分分区，再在分区上建文件系统。但如果你计划使用 LVM，那块盘可以直接作为物理卷（PV）使用，不需要先分区。这个细节很重要：LVM 可以直接建立在整块磁盘上，也可以建在分区上。直接整块盘创建 PV 的好处是简化管理，坏处是失去了分区表的灵活性（比如某些场景需要多分区不同文件系统）。

如果不需要 LVM，直接在整块盘上创建文件系统也可以。比如一块纯数据盘，直接建 xfs 或者 ext4，然后挂载。对于单块数据盘且后续没有扩容拆分需求，这种简单方式没有太大问题。但从工程实践角度，只要预期未来可能需要扩容，就建议引入 LVM。

4.3 创建文件系统

分区或 PV 建好之后，必须格式化。文件系统类型的选择直接影响后续使用。下文会单独用一节对比 ext4 和 xfs，这里先给出命令。

ext4 格式化的命令：

mkfs.ext4 /dev/sdb1

xfs 格式化的命令：

mkfs.xfs /dev/sdb1

格式化会清空设备上所有数据，确认无误后再执行。格式化完成后，设备上就有了文件系统元数据。

4.4 挂载与持久化

临时挂载很简单：

mount /dev/sdb1 /data

但重启后挂载会丢失，必须写入/etc/fstab。这是磁盘配置中最关键的一步，也是很多新手出错的地方。错误配置 fstab 会导致开机进入紧急模式。

写入 fstab 的推荐方式不是直接用设备名，而是使用 UUID：

blkid /dev/sdb1

拿到 UUID 后，在/etc/fstab中追加一行。假设 UUID 是abc-123：

UUID=abc-123 /data xfs defaults 0 2

字段含义依次是：设备标识、挂载点、文件系统类型、挂载选项、是否 dump 备份、是否开机自检。最后一个字段在生产服务器上通常设为 2，表示非根文件系统开机检查。

改完 fstab 后不要直接重启验证，先执行：

mount -a

这个命令按照/etc/fstab重新挂载所有未挂载项。如果命令返回正常，说明配置没有语法错误。之后重启才是安全的。

4.5 常见误区

• 误把设备名写入 fstab。设备名可能变化，推荐 UUID 或 LABEL。
• 挂载点目录不存在。执行mount前先mkdir -p /data。
• 挂载点已有文件。挂载后原有内容会被隐藏，直到卸载后才重新可见，容易造成“数据丢失”的错觉。
• 在 fstab 中写错文件系统类型，导致 mount 失败，开机进入 emergency mode。

5. 文件系统选型：ext4、xfs 还是 btrfs？

文件系统选型在服务器配置中经常被忽略，但选错文件系统，后续在扩容、快照、修复方面会有明显差异。

5.1 三个主流文件系统的定位

ext4 是 Linux 上最通用的文件系统，兼容性极好。从嵌入式设备到大型服务器都能看到它。它的最大优势是“稳”，修复工具成熟，适用于大多数通用场景。

xfs 是高性能的 64 位日志文件系统，擅长处理大文件和高吞吐量。RHEL/CentOS 7 开始把它作为默认文件系统。它在并发写入场景下表现很好，尤其适合数据库数据文件、虚拟化镜像这类大文件。

btrfs 提供了快照、压缩、校验和等高级功能，功能上限高，但在生产环境的稳定性争议较多。如果你的团队没有足够经验，建议谨慎使用。

5.2 从扩容角度对比

ext4 文件系统支持在线扩容，但不支持缩小。也就是说，分区空间不够了，可以在线扩大，但想缩回来，基本只能备份重做。xfs 同样支持在线扩容，且同样不支持缩小。这算是现代主流文件系统的共同特征。

另外一个关键区别是：ext4 在创建文件系统时可以指定-m参数预留块比例，默认预留 5% 给超级用户，避免文件系统满时系统无法写入关键日志。xfs 也有类似机制。大数据量分区建议调低预留比例。

5.3 怎么选？

如果你不知道选什么，可以这样判断：

• 通用业务、兼容性优先：选 ext4；
• 大文件、高吞吐、RHEL 系默认：选 xfs；
• 需要快照、压缩等高级特性且团队有经验：再考虑 btrfs；
• MySQL 等数据库的数据目录：多数场景推荐 xfs，但要注意某些云环境默认可能是 ext4，只要性能验证达标，都不是绝对限制。

需要特别强调的是，任何文件系统选择都必须在业务性能测试后最终确认，不要只看基准数据。不同业务模型对文件系统的敏感度差异很大。

6. RAID 与 LVM：性能与容错的不同层级

很多新手容易把 RAID 和 LVM 混为一谈，以为都是“把多块盘合成一块用”。实际上它们解决的问题完全不同，而且在实际服务器中常常同时存在。

6.1 RAID 解决的是硬件可靠性问题

RAID 在磁盘阵列控制器（或系统 BIOS 层）工作，把多块物理盘组合成一个逻辑卷。

• RAID 0：多块盘合成一个，性能好但没有冗余，任何一块盘故障数据全丢；
• RAID 1：两块盘互为镜像，一块故障不影响数据，但容量减半；
• RAID 5：至少三块盘，允许坏一块，兼顾容量和冗余；
• RAID 10：先镜像再条带，性能和冗余都均衡，但至少需要四块盘。

生产数据库服务器常见 RAID 10，因为它随机读写性能好，冗余度也能接受。但如果你的系统是云服务器，RAID 通常由云平台底层托管，不需要在系统内配置；物理机则要确认 RAID 卡电池状态和策略。

6.2 LVM 解决的是逻辑卷弹性问题

LVM（Logical Volume Manager）在操作系统层工作，提供的是逻辑上的空间管理能力。它的核心组件有四个：

• PV（Physical Volume）：物理卷，可以是一整块盘，也可以是一个分区；
• VG（Volume Group）：卷组，把多个 PV 组合成一个资源池；
• LV（Logical Volume）：逻辑卷，从 VG 中划分出来给文件系统使用；
• PE（Physical Extent）：物理扩展块，是空间分配的最小单位。

LVM 的最大价值是在线扩容。业务跑着，磁盘空间不够了，加一块新盘，扩展到 VG，再扩展 LV 和文件系统，整个过程可以不停机。这在数据库、日志系统等不能随便重启的场景下非常实用。

6.3 一个判断：RAID 管“坏不坏”，LVM 管“够不够”

这句话是理解两者关系的最快路径。RAID 回答的是“某块盘坏了，数据还在不在”；LVM 回答的是“空间不够了，能不能不停机扩容”。两者不冲突，物理机常见组合是“RAID 10 提供底层冗余，LVM 提供上层弹性”。

当然，LVM 不是万能的。如果底层就是单块盘且无 RAID，LVM 并不能防止磁盘物理损坏带来的数据丢失。这一点在规划时要清楚：LVM 解决容量弹性，备份和 RAID 解决可靠性。

6.4 LVM 完整操作流程

假设你有一块 500G 的新盘/dev/sdb，现在要把它做成 LVM 并挂载到/data。

第一步，创建物理卷：

pvcreate /dev/sdb

第二步，创建卷组并加入物理卷：

vgcreate data_vg /dev/sdb

第三步，从卷组创建逻辑卷：

lvcreate -L 300G -n data_lv data_vg

这里只划分 300G，而不是 500G 全部划完，是故意留出扩容余量。

第四步，查看逻辑卷路径：

lvs

输出中的路径通常是/dev/data_vg/data_lv。在 LV 上创建文件系统：

mkfs.xfs /dev/data_vg/data_lv

第五步，挂载：

mkdir -p /data mount /dev/data_vg/data_lv /data

第六步，写入 fstab。注意 LVM 逻辑卷的设备名在重启后相对稳定，但更稳妥的方式是使用 UUID：

blkid /dev/data_vg/data_lv

参照上一节格式写入/etc/fstab：

UUID=<输出中的UUID> /data xfs defaults 0 2

6.5 LVM 在线扩容实战

这是 LVM 最有价值的操作之一。比如/data已经用了 280G，马上要满，你把 VG 中剩余的 200G 扩展到 LV，再把文件系统扩起来。

lvextend -L +200G /dev/data_vg/data_lv

如果是 xfs 文件系统，在线扩展使用：

xfs_growfs /data

如果是 ext4 文件系统，使用：

resize2fs /dev/data_vg/data_lv

执行完成后用以下命令验证：

df -h /data

这个操作不需要停机，也不需要卸载文件系统，是生产环境的标准扩容方式。但有一个前提：扩容前必须确认 VG 中有可用空间。如果 VG 空间不足，需要先加新盘并扩展 VG：

pvcreate /dev/sdc vgextend data_vg /dev/sdc

再执行lvextend。整个链路是：加盘 -> 扩展 VG -> 扩展 LV -> 扩展文件系统，每一步都有对应的验证命令。

7. 运行结果与效果验证：磁盘性能到底达标没有

配置完成后，访问/data如果能正常读写文件，只能说明“功能可用”，不能证明“性能达标”。性能验证是磁盘管理流程中不可跳过的一环。

7.1 查看文件系统信息

配置完成后，先确认系统识别到新空间：

df -hT /data

预期输出类似：

文件系统 类型 容量 已用 可用 已用% 挂载点 /dev/mapper/data_vg-data_lv xfs 300G 33M 300G 1% /data

7.2 使用 fio 测试随机读写

随机读写性能是数据库、消息队列这类业务最关心的指标。使用 fio 进行 4KB 随机读测试和随机写测试。

随机读测试命令：

fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --size=2G --numjobs=4 --runtime=60 --group_reporting --direct=1

随机写测试命令：

fio --name=randwrite --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --size=2G --numjobs=4 --runtime=60 --group_reporting --direct=1

参数含义说明：

• --direct=1：绕过文件系统缓存，直接测磁盘真实性能；
• --iodepth=32：IO 队列深度，模拟高并发；
• --bs=4k：块大小，模拟数据库典型随机 IO；
• --numjobs=4：4 个并发进程；
• --runtime=60：测试时长 60 秒。

测试结束后会输出平均 IOPS 和平均延迟。SSD 上 4KB 随机读 IOPS 达到数万，延迟在微秒到亚毫秒级，属于正常；如果延迟到几十毫秒，说明磁盘或配置存在瓶颈。

7.3 使用 dd 粗测顺序读写

不追求精准、只做快速验证时，可以用dd：

dd if=/dev/zero of=/data/testfile bs=1M count=2048 oflag=direct conv=fdatasync

这条命令写入一个 2G 的文件，oflag=direct绕过缓存，结果会给出写入速度。注意dd只能做粗略参考，不能代替 fio 的随机性能测试。

7.4 测试完清理

性能测试会生成临时文件，测试完成后需要清理，避免占用数据盘空间：

rm -f /data/testfile

8. 常见问题与排查思路

磁盘管理的故障往往不是“命令不会敲”，而是“敲完不知道怎么判断”。下面整理几个高频问题。

9. 磁盘管理的最佳实践与工程建议

9.1 规划先行：卖家当之前先想好三年

服务器磁盘选型最忌讳“临时拍脑袋”。建议在采购前做一个简单的存储规划表，至少包含这些字段：业务模块、数据性质（热/温/冷）、容量预估（当前与三年后）、性能要求（顺序/随机）、可靠性要求。这个表决定了你买什么盘、买几块、做不做 RAID。没有规划表，采购回来的机器很可能在半年后陷入扩容和迁移的泥潭。

9.2 分区建议：系统盘与数据盘严格分离

这也是本文一直在强调的点。操作系统、应用程序、日志、数据库数据不要混在同一个分区。日志写满磁盘时，如果系统盘和数据盘是分开的，至少系统还能登录、还能排查。建议的分区方案是：

• /：系统与软件，容量 50G 到 100G 即可；
• /boot：引导分区，1G 足够；
• /data：业务数据，容量根据业务规划；
• /var/log：如果日志量大，单独分区更好，避免日志拖垮系统盘。

9.3 挂载选项：noatime 与日志

对高性能要求的业务，挂载时可以考虑noatime，减少访问时间戳的写入开销。文件系统默认记录每个文件的访问时间，访问频繁时会产生多余 IO。挂载选项示例：

UUID=<UUID> /data xfs defaults,noatime 0 2

xfs 的日志默认是 metadata journal，不需要频繁调优。ext4 默认启用data=ordered，兼顾一致性；追求更高性能且能接受一定风险时，才考虑data=writeback。

9.4 监控与告警：磁盘满是最常见的温柔杀手

磁盘满不会立刻让系统崩溃，但会让数据库写入失败、日志丢失、应用挂起。建议对磁盘使用率设置监控告警，阈值通常设在 80% 预警、90% 告警。监控工具可以是 Prometheus + node_exporter，也可以使用云厂商自带监控。更重要的是，要建立定期清理任务，比如日志轮转、临时文件清理。

9.5 安全边界：所有危险操作重复确认

格式化、删除分区、覆盖挂载点，都属于高危险操作。生产环境的操作规范应该是：

• 操作前备份关键数据；
• 操作前执行lsblk和blkid双重确认设备；
• 优先在测试环境验证命令和参数；
• 批量操作的脚本必须加保护判断，比如确认设备名匹配才继续执行；
• 任何销毁性操作前记录现场输出，便于回滚。

9.6 云服务器与物理机的差异

云服务器上磁盘通常以云盘形式挂载，容量在线扩容方便，RAID 由平台托管。这种情况下，你在系统内的任务更聚焦于文件系统扩展和挂载配置。物理机的重点则在 RAID 卡设置、硬件故障单点确认、驱动兼容性。

9.7 命名规范与文档

服务器多了以后，靠记忆管理磁盘是灾难。分区、卷组、逻辑卷的命名应该有明确语义。比如data_vg、mysql_lv、log_lv，比vg0、lv1更容易维护。每台服务器的磁盘布局、UUID、挂载点、预期用途，都应该记录在运维文档中。不出故障时，文档感觉可有可无；出故障时，文档就是救命稻草。

10. 总结与后续学习方向

磁盘管理是一项“越早规划，越省心”的工程。选型时明确业务性能需求，分层组合不同存储介质；配置时严格区分系统盘和数据盘，合理使用 LVM 保留扩容空间；部署后用fio量化验证性能，并在日常监控中关注使用率与延迟。这套流程走通之后，服务器存储这块的基本盘就稳了。

写完这篇文章之前，我一直在想，对普通工程师来说，磁盘管理最重要的能力到底是什么。排在第一位的不是会敲多少命令，而是在一开始就知道哪些组合是合理的，哪些决策会给未来埋坑。命令可以现查，但选型判断和配置习惯需要提前建立。

下一步，建议你做三件实操：

第一，打开你的测试机，用一块干净的云盘或虚拟机磁盘，完整走一遍“识别 -> 建 PV -> 建 VG -> 建 LV -> 格式化 -> 挂载 -> 扩容”的流程。第二，用fio对比 SSD 和 HDD 的随机读写数据，建立自己的性能感知。第三，查一下你的生产服务器df -h，确认系统盘和数据盘是否分离，fstab 是否使用 UUID 挂载。

磁盘性能优化的深水区还有很多方向，比如 IO 调度器选择、NUMA 与中断绑核、NVMe 多队列参数、文件系统碎片整理等。这些内容适合在基础流程跑通之后继续深入。但无论如何，先把基础配置做对，再谈高级优化，这才是一条稳妥的成长路径。