去年双十一，我们公司的后台系统直接崩了。不是流量太大，而是运营点了一个报表，整个数据库CPU飙到99%，所有业务全部卡死。老板站在我身后，脸色铁青。那一刻我意识到，数据库优化不是锦上添花，而是生死存亡。
很多企业都经历过这种噩梦：系统上线时跑得飞快，数据量一上来就慢得像蜗牛。运维团队天天加班加索引、改SQL，但效果总是不持久。问题出在哪？绝大多数人把数据库优化当成一次性工程，以为加几个索引就万事大吉。实际上，数据库优化更像一场持续的手术，得从架构设计、查询逻辑、硬件配置、运维习惯四个维度同时下手。
先说最常见的慢查询。我们曾经有个订单查询接口，用户点一次要等8秒。拆开一看，SQL里写了三个left join，每个表都是几百万行数据。这种写法在数据量少的时候没问题，但一旦过百万，数据库就要做笛卡尔积，计算量呈指数级上升。解决办法不是删掉索引，而是重新设计查询逻辑——把关联字段拆成独立查询，在业务层做合并。改完之后，接口响应时间降到200毫秒。这个案例告诉我们：数据库优化的第一原则，是让数据库做它擅长的事，别让它干应用层的活。
索引设计是另一个重灾区。很多DBA喜欢给每个字段都加索引，觉得这样万无一失。实际上，多余的索引会让写入速度变慢，还会占用大量磁盘空间。我们优化过一个用户表，50个字段建了30个索引，每次插入数据要等3秒。后来分析业务场景发现，真正用到的查询模式只有5种，其他索引都是摆设。果断删掉25个索引，写入速度直接提升了8倍。索引不是越多越好，而是越精准越好。你得搞清楚业务到底怎么查数据，再针对性地建组合索引。
硬件层面也有陷阱。很多人以为数据库慢就是CPU不够，拼命加核加内存。但有一次我们遇到一个奇怪的问题：数据库服务器配置很高，但查询就是慢。排查了三天，发现是磁盘IO成了瓶颈——虽然用了SSD，但RAID卡配置不当，导致随机读写性能极差。换个思路，把数据库文件和日志文件分别放到不同的物理磁盘上，问题立刻解决。硬件优化的核心不是堆配置，而是找到真正的瓶颈点。
运维习惯同样关键。很多企业喜欢在白天高峰期跑数据备份或者ETL任务，结果数据库忙着做大量读写操作，业务查询自然变慢。我们调整策略，把这些重任务都挪到凌晨2点到5点执行，同时开启慢查询日志，每天自动分析Top 10的慢SQL。坚持两个月，数据库平均响应时间下降了60%。这种习惯上的改变，比任何技术手段都来得有效。
缓存是数据库优化里最容易被忽视的环节。我们有个统计报表，每天要被点上千次，每次都要从数据库里算一遍。后来引入Redis做缓存，把计算结果存起来，第一次查询后24小时内直接从缓存取。效果立竿见影，数据库压力直接降了70%。但要注意，缓存不是万能药。业务数据实时性要求高的场景，缓存反而会引发数据不一致。得根据业务特点，在实时性和性能之间找到平衡点。
说说分库分表。很多公司数据量一上千万就急着分库分表，但这是个双刃剑。我见过一个案例，把一张表拆成128个分表，查询时要用中间件做路由，结果跨表查询性能反而更差。分库分表的正确时机，应该是单表数据量超过500万行且索引优化已到极限的时候。在此之前，先尝试冷热数据分离，把历史数据归档到另一个库，让活跃数据保持在可控范围内。
回头看那次双十一的崩溃，其实早有预兆。慢查询日志里每天都有几十条超过10秒的SQL，但运维团队一直没当回事。等到大促那天，所有问题集中爆发，谁也救不了。数据库优化不是等出事了再修修补补，而是要在日常中持续排查、持续改进。从慢查询到高性能，没有一蹴而就的捷径，只有一步一步踩过坑之后，才能走出一条稳健的进化之路。
