数据库基础知识教程

我见过太多人把数据库当成Excel的数据识教加强版来用，直到数据量突破十万行才意识到问题。库基数据库不是础知程表格，它是数据识教一套关于数据关系的逻辑系统。你问十个程序员，库基九个会告诉你“别把业务逻辑写进SQL”，础知程但没人告诉你为什么——因为SQL写复杂了，数据识教你根本没法调试。库基

拿最基础的础知程MySQL说。你建一张用户表，数据识教一张订单表，库基用外键关联。础知程听起来很简单对吧？数据识教可一旦你开始做联表查询，性能问题就来了。库基索引不是础知程万能的，它就像书的目录——你翻目录找“苹果”很快，但如果你要找“所有带‘苹’字的词”，目录就帮不上忙了。这时候你才明白，表结构设计决定了你能走多远。

我见过一个真实的案例。某创业公司把订单状态直接存成字符串，'pending'、'paid'、'shipped'，看着挺直观。结果三个月后，产品经理要求统计“所有已支付但未发货的订单”，开发写了个WHERE status != 'shipped'，把已取消的订单也算进去了。数据全乱了。后来改成枚举类型，又发现业务加了个“部分退款”状态，枚举改起来要迁移数据，麻烦得要命。这就是设计时没想清楚——状态字段应该存编码，显示层再映射成文字，而不是直接存人类可读的字符串。

再说说事务。很多人以为事务就是“要么全成功，要么全失败”，这话对，但不够。事务还有个隔离级别的问题。MySQL默认是REPEATABLE READ，意味着你在一个事务里读到的数据，和另一个并发事务提交后的数据可能不一致。听上去很绕，但实际场景很常见：你在购物车页面看到商品价格是100块，下单时价格已经改成120了。如果你用READ COMMITTED，每次读都是最新值，但可能读到中间状态。没有银弹，隔离级别是性能和数据一致性之间的取舍。

还有个很多人忽略的点：数据库的备份策略比优化SQL更重要。你优化了一条慢查询，查询从2秒降到0.1秒，这确实爽。但如果你从来没做过恢复演练，某天硬盘坏了，你才发现备份文件是坏的，那才是灾难。我有个朋友，他们公司每天凌晨自动备份，但从来没验证过备份能不能恢复。直到一次机房断电，数据文件损坏，他们拿着备份去恢复，发现备份文件只写了一半——因为备份脚本没加--single-transaction，导致备份过程中数据不一致。后来改成用Percona XtraBackup，才彻底解决。

最后说个反直觉的事。有时候，冗余字段比规范化更实用。教科书教你第三范式，告诉你订单表里不要存用户姓名，要关联用户表去查。但实际业务里，用户可能改昵称，订单历史记录里的收货人姓名却必须保持不变。所以订单表里冗余一份“用户当时填写的姓名”是合理的。规范化的目的是减少更新异常，但业务需求优先于理论教条。你要做的是理解范式背后的原因，而不是死记规则。

数据库这东西，入门容易，精通难。别指望看几篇教程就能设计出完美的库。多踩坑，多复盘，比什么都强。你写的每一条SQL，设计的每一张表，最后都会变成你经验的一部分——包括那些让你头疼的坑。