先说结论：对于OLTP高频事务处理的场景，也就是我们最常使用的关系型数据库，应优先选择 Ext4/XFS；BTRFS在这方面表现不佳。

下面我们详细介绍BTRFS的特性，及在OLTP场景下的测试表现。

BTRFS核心优势

1.数据完整性保障
BTRFS 支持 CRC32C 校验和，可检测和修复静默数据损坏，避免因硬件错误或位翻转导致的数据不一致。写入时复制（CoW） 机制在修改数据时保留原始副本，提升崩溃恢复能力，减少事务中断风险。

2.快照与备份功能
支持可写/只读快照，便于实现数据库的实时备份与快速恢复，适用于需要频繁备份的场景（如开发测试环境）。

3.动态资源管理
动态inode分配 避免传统文件系统因 inode 耗尽导致的问题，适合存储大量小文件（如日志数据库）。

4.压缩与存储优化
内置文件系统级压缩（如 LZO、Zstd），可减少存储占用并提升 I/O 效率，对读密集型数据库（如数据仓库）有显著增益。

我们既然知道了BTRFS在这些场景下的优势，那么在OLTP场景下表现如何呢？我们利用sysbench进行如下基准测试。

I/O基准测试

我们对BTRFS、Ext4、XFS三种文件系统，在相同硬件环境下进行I/O基准测试。
为了快速得到一个模糊的答案，测试设计得较为简单，但也能以小见大。

几次测试相同的变量如下：

变量	值
文件数量	128
文件总大小	100G
运行时间	300s

测试结果如下：

测试1：顺序写

fs类型	write(mb/s)	write IOPS	fsync IOPS	平均耗时(ms)	95%耗时(ms)
ext4	1363.68	83232.33	106537.58	0.01	0.01
xfs	1443.58	88109.27	112780.2	0	0.01
btrfs	892.21	54456.34	69704.34	0.01	0.01

测试2：顺序读

fs类型	read(mb/s)	read IOPS	平均耗时(ms)	95%耗时(ms)
ext4	7108.09	433843.56	0	0
xfs	7007.14	427681.91	0	0
btrfs	6713.93	409786.06	0	0

测试3：随机写

fs类型	write(mb/s)	write IOPS	fsync IOPS	平均耗时(ms)	95%耗时(ms)
ext4	214.81	13110.68	16782.01	0.03	0.08
xfs	212.82	12989.54	16626.88	0.03	0.09
btrfs	56.49	3448.17	4413.99	0.13	0.39

测试4：随机读

fs类型	read(mb/s)	read IOPS	平均耗时(ms)	95%耗时(ms)
ext4	5590.98	341246.44	0	0
xfs	5767.35	352011.24	0	0
btrfs	2721.05	166079.95	0.01	0.01

测试5：混合随机读写3:1

fs类型	read(mb/s)	read IOPS	write(mb/s)	write IOPS	fsync IOPS	平均耗时(ms)	95%耗时(ms)
ext4	484.99	29601.62	161.66	9867.21	50520.13	0.01	0.05
xfs	279.05	17031.62	186.03	11354.41	36334.19	0.02	0.04
btrfs	53.73	3279.52	35.82	2186.34	6996.7	0.08	0.32

从结果中可以初步看到，BTRFS在同等文件大小的情况下：
顺序读的测试表现与Ext4/XFS相差不多，结合自身FS级别的压缩，在实际应用中应该能提升效率；
但是在随机读和写方面性能较差。

OLTP基准测试

我们继续对BTRFS、Ext4、XFS三种文件系统，在相同硬件环境下进行OLTP基准测试。
测试环境是硬RAID5，相同的SSD（生产环境一般是RAID10）。
为了快速得到一个模糊的答案，测试设计得较为简单，但也能以小见大。

几次测试相同的变量如下：

变量	值
单表数据量	10万条
运行时间	300s

测试1：正常读写
表数量10张，线程数为4：

fs类型	qps	tps	平均耗时(ms)	95%耗时(ms)
ext4	48321.47	2416.07	1.65	1.86
xfs	51788.66	2589.43	1.54	1.73
btrfs	34722.76	1736.14	2.3	3.62

表数量100张，线程数为4：

fs类型	qps	tps	平均耗时(ms)	95%耗时(ms)
ext4	42541.2	2127.06	1.88	2.35
xfs	46185.59	2309.28	1.17	2.3
btrfs	22686.21	1134.31	3.52	7.17

表数量100张，线程数为8：

fs类型	qps	tps	平均耗时(ms)	95%耗时(ms)
ext4	77024.47	3851.22	2.08	3.07
xfs	83204.94	4160.25	1.92	2.52
btrfs	43834.08	2191.7	3.65	5.88

测试2：读多
表数量100张，线程数为8：

fs类型	qps	tps	平均耗时(ms)	95%耗时(ms)
ext4	95817.46	5988.59	1.33	1.58
xfs	95150.18	5946.89	1.34	1.64
btrfs	92378.45	5773.65	1.38	1.73

测试3：写多
表数量100张，线程数为8：

fs类型	qps	tps	平均耗时(ms)	95%耗时(ms)
ext4	49582.06	8263.68	0.97	1.67
xfs	51011.44	8501.91	0.94	1.79
btrfs	14439.01	2406.5	3.32	4.65

测试4：更新二级索引
表数量100张，线程数为8：

fs类型	qps	tps	平均耗时(ms)	95%耗时(ms)
ext4	29242.12	29242.12	0.27	0.43
xfs	28508.02	28508.02	0.28	0.52
btrfs	5862.2	5862.2	1.36	2.52

从结果中可以初步看到：
1.在数据库事务处理场景下，btrfs整体性能弱于ext4和xfs。
2.随着系统复杂度提高，btrfs性能下降速度比其他快。
3.随着线程数提高，btrfs性能提高比ext4和xfs弱，且但个事务或查询的耗时更长。
4.对于随机写场景，btrfs性能劣势更大。

BTRFS的缺陷

1.随机写入性能瓶颈
在高并发随机写入场景（如数据库OLTP场景）中，BTRFS的性能显著落后于Ext4/XFS，从上面的基准测试即可看出。
根据网上的其他测试显示，其随机寻道速度仅为Ext3的1/4，且频繁的 CoW 操作可能导致碎片化，进一步降低吞吐量。

2.碎片化问题
BTRFS的CoW机制易导致大文件碎片化，需定期手动整理，否则顺序读取性能（如全表扫描）可能下降30% 以上。

3.资源消耗与复杂性
校验和计算与数据巡检 依赖 CPU 和内存资源，尤其在非 ECC 内存环境下，可能因位错误引发数据一致性问题。功能复杂性（如内置 RAID、去重）增加了运维难度，需专门配置与监控。

4.兼容性与稳定性争议
BTRFS在数据库领域的稳定性仍存争议。部分用户反馈其在高负载下易出现元数据损坏，且修复工具不如 Ext4成熟。

适用场景总结

推荐使用BTRFS的场景：

• 读密集型分析数据库：如ClickHouse等列式存储，受益于压缩与快照功能。
• 开发/测试环境：利用快照快速回滚，缩短迭代周期。
• 中小型非关键业务：对数据完整性要求高但负载较低的场景。

不推荐使用BTRFS的场景：

• 高频事务处理（OLTP）：如MySQL、PostgreSQL的主库，优先选择 Ext4/XFS。
• 高并发随机写入：如Kafka日志存储，避免碎片化导致的性能衰减。
• 资源受限环境：缺乏ECC内存或低配硬件可能放大其缺陷。