聊数据库优化，很多人第一反应就是加索引、换硬件、搞缓存，好像数据库慢就是个技术问题，买几台服务器就能解决。我在媒体这行跟技术团队打交道十几年，见过太多公司砸钱买设备，结果该慢还是慢。其实数据库优化这事儿，有点像给老房子装修——不是光换几个灯泡就行的，得从地基开始看，到底哪儿在漏水。
先说索引，这是最基础的优化手段，但也是最容易被玩坏的。我认识一个创业公司的 CTO，他们团队有个程序员，每张表上来就是“加满索引”，觉得索引越多查询越快。结果呢？一个月后系统崩了，因为写操作太多，每次插入数据都要更新 N 个索引，磁盘 I/O 直接爆了。索引就像书的目录——目录太多，翻书反而慢。合理做法是：先看慢查询日志，找出跑得最久的 SQL，针对性地加索引。比如 WHERE 条件里的字段、JOIN 的关联字段、排序字段，这些地方该加就加。但记住，索引不是越多越好，尤其是联合索引，必须考虑字段顺序。最左前缀原则很多人嘴上说知道，写起来就忘了，结果索引建得跟没建一样。
再说 SQL 本身，这其实是很多人忽略的优化点。我采访过一位阿里的数据库专家，他说他们最怕的不是慢 SQL，而是那些“看起来很对但实际很蠢”的 SQL。比如 SELECT ，明明只需要三个字段，却把所有字段都拉出来。数据量小的时候无所谓，一旦表里有几十个字段、上千万行，这个 就是灾难。还有嵌套子查询，写出来像俄罗斯套娃一样层层套，数据库引擎执行起来会非常慢。优化方向很简单：只查需要的字段，能用 JOIN 就别用子查询，能用 EXISTS 就别用 IN。分页查询时，很多人用 LIMIT OFFSET，OFFSET 越大越慢，因为数据库要从头数到指定位置。更好的做法是“游标分页”，记住上一次的一条记录的 ID，然后直接查询大于该 ID 的 N 条数据。
索引和 SQL 都优化完了，如果还慢，就得看表结构设计是否有问题。我见过一个电商平台，订单表里存了用户的名字、地址、手机号等字段，但用户改了地址后，所有历史订单的地址也跟着变——这就是典型的“字段冗余”带来的麻烦。更常见的问题是字段类型选错，比如存时间用字符串，存金额用 FLOAT，存状态用 VARCHAR。时间用字符串查询时无法利用索引； FLOAT 有精度问题，算钱会出错； VARCHAR 存状态，代码里还得硬编码各种值。优化建议：字段类型能小就别大，能用 INT 就别用 BIGINT，能用 TINYINT 就别用 INT。比如性别、状态这种枚举值，用 TINYINT 存 0 和 1 就行了，别搞成 VARCHAR。还有范式化和反范式化的取舍：OLTP 场景（如订单系统）尽量遵守第三范式，减少数据冗余；OLAP 场景（如报表系统）可以适当反范式化，加入冗余字段，省去 JOIN 的开销。
说到场景，数据库优化必须区分读写特性。我有个做游戏的朋友，他们的数据库读多写少，用户登录、查排行榜占了 90% 的流量。优化方式是：在主库之外部署多个只读从库，写走主库，读分散到从库。再加上 Redis 缓存，热门数据直接缓存在内存里，查询一次缓存就能把数据库请求挡掉约 90%。但另一个做金融系统的朋友情况完全相反，写多读少，而且对数据一致性要求极高，不能有缓存带来的延迟。他们的优化思路是：写操作分批处理，例如把每秒写 1000 条改成每秒写 100 条但每条包含 10 条数据；调优数据库连接池，减少频繁建连；使用分区表，按时间分区，旧数据自动归档，避免表越来越大。
硬件和参数调优这块，很多人容易走极端。要么觉得“加 CPU 加内存就行”，要么觉得“调几个参数就能解决”。实际经验是：硬件升级是必要的手段，参数调优是锦上添花。我采访过一个数据库运维团队，他们花了两个月把 MySQL 的 innodbbufferpoolsize 调到服务器内存的 70%，把 querycachetype 关掉（高并发场景下缓存反而降低性能），把 maxconnections 从 100 调到 500，并把 binlog 格式从 STATEMENT 改成 ROW。以上操作合计提升了约 30% 的性能，但真正解决核心问题的，还是前面说的索引和 SQL 优化，那才是关键。硬件层面的提升，SSD 换机械硬盘效果最明显，内存加大能减少磁盘 I/O，但 CPU 升级的感知提升通常不大——除非你跑的是超级复杂的计算查询。
还有一个容易忽视的点：数据量太大，怎么都优化不动了，就得考虑分库分表。我见过一个社交平台，用户动态表已经达到 2 亿条，加了索引仍然慢。他们采用 Sharding 方案，按用户 ID 哈希分到 16 个库，每个库再按时间分表。查询时先算用户 ID 落在哪个库，再在对应时间范围的表中查找。方案效果很好，但代价也大：跨库 JOIN 和事务基本不可用，代码里需要写大量路由逻辑。如果不想这么复杂，可以先尝试冷热分离——把最近半年的热数据放在高性能服务器上，半年以上的冷数据迁移到便宜的大容量存储。很多公司发现，90% 的访问集中在最近 10% 的数据上，冷热分离后，热库的数据量变小，性能自然提升。
说一个很多人不敢提的事实：有些查询慢，不是数据库的问题，而是业务逻辑设计有缺陷。我有个朋友做电商，他们的“我的订单”页面加载特别慢，SQL 里 JOIN 了十几张表，包括订单、商品、用户、地址、物流、优惠券等。之所以 JOIN 这么多，是因为前端一次性想展示所有细节。但用户真的需要一次性看到全部信息吗？优化方案是：页面拆成几个模块，先加载核心信息（订单号、金额、状态），其余信息（物流轨迹、优惠券明细）异步加载。这样数据库压力瞬间下降。数据库优化，永远不要只盯着数据库本身，要从应用层、业务层、架构层一起审视。很多时候，砍掉不必要的业务逻辑，比调一百个参数更有效。说到底，数据库是工具，别把它当神供着，也别把它当垃圾桶往里塞东西。想清楚数据怎么来、怎么用、怎么存，优化方案自然就有了。
