数据库优化这事儿，很多程序员一开始都觉得挺高深，好像得懂一堆算法和底层原理才行。但其实真上手了，你会发现最管用的方法往往特别朴素，甚至有点“反直觉”。比如，我见过最典型的场景：一个刚上线的系统，用户才几百人，数据库跑得飞快，开发团队觉得自己优化得特别好。结果用户一涨到几千，查询突然慢得像蜗牛爬，这时候才慌慌张张去加索引、改SQL。其实，真正靠谱的优化不是等出问题再补救，而是在设计阶段就把“坑”填平。你看那些大厂的经验，从来不是靠事后打补丁，而是从一开始就想着怎么让数据少跑路、少折腾。
说到具体方法，索引绝对是绕不开的第一道关卡。但很多人对索引的理解，还停留在“建了就快”的层面。我有个朋友，做电商后台的，给订单表建了七八个索引，结果写入速度慢得要命，每次插入数据都得等半天。后来一查，才发现索引太多反而成了负担：每次写操作，数据库不仅要改数据，还得更新所有索引，等于多干了好几倍的活。正确的做法是先分析业务逻辑，找出最常用的查询条件。比如订单表经常按用户ID和时间范围查，那就在这两个字段上建联合索引，而不是单建一堆独立的。并且，索引不是越多越好，一个表超过五六个索引，收益就开始递减。你想想，数据库就像个图书馆，索引是目录卡片，卡片太多，找书反而更乱。
索引之外，SQL 语句本身的设计也藏着大学问。我见过最夸张的案例，有个公司做报表，一个查询跑了半小时，后来发现是写了个 “SELECT *”，把几十个字段全捞出来，却只用了其中三个。这就是典型的“用大炮打蚊子”。优化 SQL 的第一步，就是只取需要的字段，别偷懒用通配符。另外，避免在 WHERE 子句里做函数运算，比如 “WHERE YEAR(createtime)=2023”，这会让索引失效，因为数据库得先把每条记录的日期算一遍。正确写法是 “WHERE createtime>=‘2023-01-01’ AND createtime<‘2024-01-01’”，这样索引才能派上用场。还有个小技巧：多表关联时，尽量用小表驱动大表，别反过来。好比去超市买东西，先挑好购物清单（小表），再去货架（大表）上找，效率肯定更高。
说到表结构设计，这通常是优化里最容易被忽视的环节，却也是决定上限的关键。我有个做社交产品的朋友，早期为了省事儿，把所有用户动态都塞到一张表里，结果用户一多，查询动不动就超时。后来他们做了分表，按用户 ID 的哈希值分成 64 张子表，每个子表的数据量只有原来的六十四分之一，查询速度直接翻了十倍。分表之外，分库也是常见策略，就是把不同类型的数据拆到不同数据库实例里，比如用户库、订单库、商品库各跑各的。但这得根据业务场景来，不能盲目分。比如，如果订单和用户经常一起查询，分库反而会增加跨库查询的复杂度，得不偿失。所以，设计表结构时，要像搭积木一样，先想清楚数据之间怎么交互，再决定怎么切。
缓存是数据库优化的“外挂”，但很多人用错了地方。我见过一个团队，给每个查询都加了缓存，结果数据一变，缓存就失效，系统不停在缓存和数据库之间来回倒腾，性能反而更差。正确的做法是只缓存那些读多写少、对实时性要求不高的数据。比如用户头像、商品详情页的描述，这类数据一天改不了几次，缓存一天都没问题。但对于订单状态、库存数量这种频繁变动的数据，缓存不仅没用，还可能带来脏数据。缓存还要设置合理的过期时间，别让数据“睡大觉”。比如热点新闻的缓存设成 5 分钟，用户画像的缓存设成 1 小时，这样既能减轻数据库压力，又不会让用户看到过时信息。
连接池也是个容易踩坑的地方。很多新手觉得连接池越大越好，恨不得配几百个连接，结果数据库内存吃紧、CPU 飙升，反而更慢。实际上，连接池的大小取决于数据库的并发处理能力和服务器的硬件资源。比如，一个 MySQL 实例，CPU 是 8 核，连接池配到 50 左右就差不多了，再大也没用，因为 CPU 忙不过来，多余的连接只会排队等待。更聪明的做法是给连接池设一个“最大等待时间”，比如 5 秒，超过这个时间就报错或降级，避免请求无限阻塞。你想想，高峰期用户排队等电梯，如果电梯永远不来，还不如告诉用户走楼梯，至少别让所有人卡在门口。
说完技术层面，再聊聊运维层面的优化。定期清理无用数据听起来像废话，但很多公司就是做不到。我认识一个做物联网的平台，存了十年设备日志，总数据量超过 10TB，查询慢得离谱。后来他们做了数据归档，把三年前的历史数据移到冷存储，在线库只保留近三年的数据，查询速度提升了 80%。归档不是一次性的事，得做成自动化脚本，每个月跑一次。另外，数据库的配置参数也别用默认值。比如 MySQL 的 innodbbufferpoolsize，默认只有 128 MB，对于稍微大点的业务根本不够，得根据内存大小调到 70% 左右。查询缓存（query cache）在 MySQL 8.0 已经被移除，因为在高并发下反而拖累性能。这些细节就像开车前的检查，虽然麻烦，但能避免半路抛锚。
我想说，数据库优化不是一劳永逸的活儿，更像一场持续的小修小补。你不能指望建完索引、配好缓存就万事大吉，因为业务在变，数据量在涨，用户行为也在变。比如，一个电商平台，平时订单查询优化得好好的，到了双十一，用户集中下单，原来的索引策略可能顶不住了，得临时做读写分离、加从库。所以，最好的优化方法是建立监控体系，实时查看慢查询日志、CPU 使用率、IO 等待时间等指标，一旦发现异常就及时调整。你想想，这就像照顾一盆植物，不能浇一次水就放任不管，得根据季节、光照、土壤湿度不断调整。数据库优化也是动态平衡的过程，需要保持敏感，随时准备出手。
