优化数据库这事儿，说复杂吧，翻来覆去就那么几招；说简单吧，真上手时一堆人抓瞎。我见过不少团队，数据库慢得像老牛拉破车，第一反应就是加机器、加缓存，折腾一圈发现还是卡。其实很多时候，问题根本不在硬件，而是写SQL的方式、建表的结构、甚至索引的使用方法出了问题。今天咱们就聊聊八种实打实的优化方法，都是老程序员踩过坑后总结的经验，不是玄学，而是有具体操作细节的。
第一个方法，也是最容易被忽略的：学会看执行计划。很多人一查数据慢，上来就改代码、加索引，完全是盲人摸象。你至少得花五分钟跑一下 ，看看数据库到底是怎么执行的。比如，是不是走了全表扫描、有没有用到索引、join 的顺序对不对。我见过一个案例，一个简单的查询跑了三秒，执行计划显示它先扫描了百万级的大表，再跟小表做嵌套循环。把 join 顺序调整一下，或者加个索引，立马降到几十毫秒。这比任何玄学优化都管用。
第二个方法是控制数据量，别把数据库当垃圾桶。很多系统越跑越慢，是因为数据表里堆了几年的历史数据，查询时全表扫描几千万行。你想想，一个用户只关心近三个月的订单，却让它扫三年的记录，不慢才怪。解决方案很直接：定期归档，把旧数据搬到历史表或冷存储里。如果业务需要快速访问近期数据，可以考虑分区表，按时间分区，查询时只扫对应分区，效率直接翻倍。别心疼历史数据，它们躺在仓库里吃灰，却拖累查询性能。
第三个方法是索引优化，但别滥用。索引不是越多越好，也不是越复杂越好。很多新手喜欢给每个字段都建索引，结果写入性能一塌糊涂，每次插入都要更新一堆索引树。正确的做法是：针对查询频率高、区分度大的字段建索引，比如用户 ID、订单状态、时间字段。同时注意复合索引的顺序，最常用来筛选的字段放前面。比如 ，复合索引应建在 上，而不是反过来。另外，别忘了定期重建索引，碎片化严重时，索引反而比全表扫描还慢。
第四个方法，别在 SQL 里写太多函数和计算。很多人喜欢在 SQL 里做字符串截取、日期格式化、甚至数学运算，比如 。这种写法会让索引失效，因为数据库要对每一行的 先执行函数再比较，等于全表扫描。正确的做法是避免在索引字段上使用函数，或者改成范围查询，例如 。如果实在避不开，可以考虑建函数索引，但这会额外消耗存储和写入性能，需要权衡。
第五个方法是优化连接查询，别动不动就 join 十几张表。我见过最夸张的 SQL，一个查询连了二十多张表，执行一次要几分钟。这种场景下，即使索引再好，也挡不住数据量的膨胀。解决办法有两个方向：一是把复杂查询拆成多个小查询，在应用层做数据组装，虽然多了几次网络请求，但整体响应时间可能更快；二是考虑用冗余字段替代 join，比如在订单表里直接存用户名而不是用户 ID，查询时少一次关联。当然这会影响数据一致性，需要业务层面权衡。
第六个方法是控制返回的数据量，别让数据库干太多传输活儿。很多前端分页做得不好，一次请求拉几千条数据，或者 把不需要的字段都查出来。数据库把大量数据传到应用层，消耗的是 IO 带宽和内存。优化方法很简单：只查需要的字段和行数，例如 。如果分页很深（比如跳到第 100 页），用 代替 ，后者会扫描大量无用行，效率极低。另外，考虑用缓存层分担查询压力，比如 Redis 或 Memcached，把热点数据提前缓存，避免重复查库。
第七个方法是调整数据库配置参数，别用默认值跑生产环境。很多开发者在本地装个 MySQL，什么参数都不改，直接推到生产。但默认配置是为通用场景设计的，缓冲区大小、连接数、日志刷新策略都偏保守。你需要根据硬件和业务负载做调优：比如 建议设为物理内存的 70%‑80%； 别设太大，否则连接池爆了反而拖垮系统； 在 8.0 版本已经废弃，就别再开它了。调完参数记得压测，别凭感觉改，否则可能适得其反。
第八个方法是考虑读写分离和分库分表。当单库扛不住并发时，别指望仅靠优化 SQL 解决问题。业务量级上去后，写操作和读操作要分开，主库负责写入，从库负责读取，分摊压力。如果数据量超过几亿行，连索引都建不下，就得考虑分表，比如按用户 ID 哈希分到多个表中。但分库分表会带来跨表查询、分布式事务、数据一致性等复杂度，需要成熟的方案。所以这是一种手段，别一上来就分，先评估业务增长趋势。
说到底，数据库优化没有银弹，每个方法都有适用场景和代价。加索引能加速查询，但会拖慢写入；读写分离能提升并发，但增加运维复杂度。你需要在性能、成本、可维护性之间找到平衡点。我见过最聪明的团队，不是把数据库调到极致的人，而是能预判业务增长、提前规划架构的人。优化不是一次性动作，而是持续迭代的过程。下次碰到数据库慢，别急着拍脑袋改，先问自己三个问题：业务瓶颈到底在哪里？这个方案的收益和成本是否匹配？有没有更简单的替代方案？想清楚再动手，往往事半功倍。
提醒一句：别迷信“优化八法”这种框架，每个系统都是独特的。你最好先做性能基线测试，记录优化前后的指标，比如查询响应时间、CPU 占用率、IO 等待时间。数据说话，比感觉靠谱得多。数据库是一门手艺活，多踩坑、多复盘、多跟同行交流，慢慢就练出来了。毕竟，那些动不动就吹“秒级优化”的人，多半没真正干过一线运维。
