网站数据库不是网站一堆表格的集合，它更像一个仓库管理员，数据只不过这个管理员从不睡觉，网站也不会把货放错架子。数据你打开任何一个电商网站，网站搜索“运动鞋”，数据零点几秒内返回几百条结果，网站背后就是数据数据库在干活。它得从几百万条商品记录里，网站按品牌、数据尺码、网站价格、数据库存状态一层层筛，网站最后把最匹配的数据那几十条递到前端。这个过程如果靠人工翻账本，网站大概得翻到明年。

我见过不少小团队把数据库当文件柜用。早期访问量低，随便写个查询就能跑，没人觉得有问题。直到某天促销活动上线，订单表突然涨到两百万行，原本“秒开”的页面变成转圈圈。运维跑过去一看，一条SELECT * FROM orders WHERE user_id = 123没加索引，全表扫描硬生生扫了两百万行。加个索引，查询时间从3.2秒掉到0.01秒。这种事在技术圈里老掉牙，但每年还是有人踩坑。

数据库分两大类：关系型和非关系型。关系型像MySQL、PostgreSQL，数据存在表里，表和表之间能通过外键关联。你下个订单，订单表记一笔，用户表扣积分，库存表减数量，三张表通过事务绑在一起，要么全成功，要么全回滚。非关系型像MongoDB、Redis，结构更随意。Redis常被拿来当缓存，把热点数据塞内存里，读的时候直接命中，不用每次都去磁盘上翻。

选哪种？看场景。用户余额、支付记录这种，必须用关系型，因为钱不能算错。商品详情页的评论列表，读多写少，用MongoDB存文档也行，每条评论一个JSON对象，取出来直接塞给前端。我自己的习惯是：核心交易走MySQL，会话状态和排行榜丢Redis，日志类数据扔Elasticsearch。没有银弹，只有合不合适。

再说说索引。很多人以为索引越多越好，其实不是。每加一个索引，写入时就要多维护一棵B树。你给“性别”字段加索引，总共就男、女、未知三个值，查询优化器根本懒得用，反而拖慢插入速度。真正该加索引的是那些经常出现在WHERE、JOIN、ORDER BY里的列，而且区分度要高。比如用户ID，几乎每条都不同，索引效果就好。

备份这事也值得提一嘴。我见过一个创业公司，数据库跑在单台云主机上，没做自动备份。某天运维手抖，DELETE忘了加WHERE，整张用户表清空。最后靠binlog恢复，但丢了最近两小时的数据。两小时里注册的新用户全没了，客服电话被打爆。后来他们上了主从复制，每天凌晨全量备份，binlog实时同步。成本没涨多少，但睡觉踏实了。

数据库调优没有终点。今天加个索引解决慢查询，明天数据量翻倍又得重新分库分表。读写分离、连接池、缓存穿透、雪崩——每个词背后都是一堆血泪案例。别指望一次设计就能扛住所有流量。先让系统跑起来，再根据慢查询日志一点点改。改着改着，你就知道哪些字段该冗余，哪些表该拆，哪些查询该走缓存。

说到底，数据库就是个工具。它不会自己变快，也不会自己变稳。你得盯着它，像盯着一个随时可能出状况的老伙计。它出问题的时候从不提前打招呼，但只要你平时把索引、备份、监控这几件事做到位，它大多数时候还是靠谱的。

(责任编辑：休闲)