你负责的数据库，最近是不是有点喘不过气来了？
查询越来越慢，报表跑半天出不来，甚至凌晨三点还收到报警说CPU快烧了。这场景我太熟了。数据量暴增，就像家里杂物越堆越多，一开始还能凑合找东西，后来连门都快推不开了。你试过加内存、换SSD，甚至把服务器从8核升到32核，结果呢？治标不治本，过两个月又卡了。别急，问题不只在硬件上，根子在你怎么管这些数据。我今天就聊聊五个优化策略，都是压箱底的东西，上手就能用。
第一个策略，也是最立竿见影的：给数据分家。
别把所有东西都塞进一张大表里。想象一下，你把十年内的订单全堆在一个仓库里，找一笔三年前的订单，得翻到猴年马月？这就是全表扫描的噩梦。分表分库，听起来高大上，其实逻辑特简单：按时间、按地域、按业务类型，把数据拆开。比如订单表，按月份分表，每个月一张小表。查询时只扫当月那几百万条，而不是上亿条。我见过一个电商平台，核心订单表从10亿条优化到每张表2000万条，查询时间从20秒降到0.3秒。分表后，备份、清理也快多了。别怕拆多了管理麻烦，现在工具多得是，像ShardingSphere、MyCat，配置文件一写，分库分表自动搞定。记住，数据量超过500万条，就得考虑分家了。
第二个策略，索引不是越多越好，得精准下刀。
很多人一听优化，第一反应就是加索引。结果加了一堆，查询没快，写入反而变慢了。索引的本质是目录，你给一本书编了50个目录，翻书找信息时，光查目录就得花半天。索引要按查询模式来建。最常踩的坑是：给每个字段都建索引，或者建了联合索引却不用最左前缀。比如你把age、name、city三个字段建了联合索引，查询时只查city和name，索引就废了。正确做法是：先分析慢查询日志，找出最耗时的SQL，针对它建索引。还有，索引字段要选择区分度高的，像性别这种只有男女的字段，索引效果约等于零。一个经验法则：单表索引不超过5个，联合索引不超过3个字段。少而精，才能真提速。
第三个策略，冷热数据分离，别让历史包袱拖慢当下。
你数据库里最活跃的数据，可能只占20%。剩下80%是半年甚至几年前的老数据，用户几乎不碰，但每次查询还得带着它们一起跑。这就是典型的“热数据”和“冷数据”混在一起。优化思路是：把热数据留在主库，冷数据扔到廉价存储或者归档库里。比如一个社交App，用户只看近三个月的帖子，那就把三个月前的帖子自动迁移到HBase或OSS上。查询时，先查热库，没结果再去冷库捞。这样主库数据量减少80%，性能立马提升。我有个客户做了冷热分离后，日均查询延迟从2秒降到0.1秒，DBA终于不用半夜爬起来处理慢查询了。
很多业务场景，读操作是写操作的几十倍。你让主库既要处理插入、更新，又要应付上千个查询请求，它分身乏术。读写分离的逻辑就一句话：写操作走主库，读操作走从库。部署一个主库加两三个从库，主库负责写入，从库实时同步数据后，专门处理查询。这样主库负载降下来，写入速度不会被打断，查询也能利用多台机器并行处理。但要注意一个细节：数据同步延迟。如果业务要求实时读刚写入的数据，就得让这类查询强制走主库。比如支付成功页面，用户刚付完款，你要立刻显示余额，那就读主库。其他场景，比如查看历史订单，走从库完全OK。搭配中间件如ProxySQL或MaxScale，读写分离配置起来比你想的简单。
一个策略，定期清理和归档，别让数据无限膨胀。
数据量暴增，很多时候不是业务增长导致的，而是因为你舍不得删。日志表、临时表、测试数据，堆了一堆。我见过一家公司的操作日志表，三年没清理过，攒了30亿条记录，占了1TB空间。其实这些日志过一个月就没人看了。优化方案是：建立数据生命周期管理。比如订单数据，三个月前的自动归档到历史库，一年前的直接压缩存储。日志表，按天分区，保留最近30天，超期自动删除。别手动搞，写个定时任务，每天凌晨跑一次。清理完你会发现，不仅查询快了，备份时间也从6小时缩到1小时。而且磁盘空间省下来，能省不少云服务费。
数据量暴增不可怕，可怕的是你还在用老办法硬扛。分表分库、精准索引、冷热分离、读写分离、定期清理，这五个策略不是选择题，是组合拳。你不用一次性全上，挑最痛的那个先动手。比如你现在的瓶颈是查询慢，先从索引和分表开始；如果是写入延迟高，读写分离和冷热分离见效最快。记住，数据库优化不是一锤子买卖，它是个持续迭代的过程。数据在涨，业务在变，你的优化策略也得跟着调整。下次半夜报警再响，你不会慌了——因为你已经有招了。
