核心原因:文件系统只懂"字节",不懂"数据"
文件系统(如 ext4、NTFS)的设计目标是可靠地存储和读取字节流,它不理解字节的含义。数据库系统要解决的,正是文件系统"管不了"的那些事。
文件系统的六个致命局限
问题 | 文件系统的表现 | 数据库怎么解决 |
无语义 | 只有文件名和路径,不知道文件里存的是"用户"还是"订单" | 有表结构、字段类型,理解数据含义 |
无查询 | 只能按文件名找,要找"所有年龄>25的用户"得自己读完所有文件逐行扫 | SQL 支持条件、聚合、关联查询 |
无事务 | 写一半崩溃,文件就 corrupt 了,没有回滚机制 | ACID 事务:要么全成功,要么全回滚 |
无并发控制 | 两个进程同时写一个文件,数据互相覆盖 | 锁机制、MVCC,保证并发安全 |
无约束 | 随便写什么都行,重复、空值、外键断裂都管不了 | 主键、外键、唯一约束、非空约束 |
无索引 | 要快速查找只能自己建额外文件做索引,而且得手动维护 | B+Tree 等索引自动维护,查询从 O(n) 降到 O(log n) |
一个直观例子
假设你用纯文件存 100 万条用户记录:
# 文件系统方式
users.txt(每行一条 JSON)
# 要执行:把所有北京的用户年龄+1
# 你需要:
1. 打开文件
2. 逐行读取 100 万行
3. 解析每行 JSON
4. 判断城市是否为北京
5. 修改年龄
6. 写回(或写新文件)
7. 过程中崩溃?前功尽弃,数据不一致-- MySQL 方式
UPDATE users SET age = age + 1 WHERE city = '北京';
-- 事务保证原子性,索引保证只扫北京的行,崩溃可恢复本质总结
层级 | 职责 |
文件系统 | 负责"数据不丢"——把字节可靠地放在磁盘上 |
数据库 | 负责"数据好用"——让数据可查、可改、可信、可并发 |
数据库不是替代文件系统,而是在文件系统之上,把原始字节变成有意义、可管理的结构化数据。没有文件系统,数据库无处存放;没有数据库,文件系统只能当"高级 U 盘"用。
