数据库慢，查个东西等半天，这事儿干运维的谁没遇到过。老板在背后盯着，业务部门在群里催，你盯着屏幕上的查询时间，恨不得自己替数据库跑一遍。别急，今天咱就聊聊六个实打实的优化技巧，用好了，查询性能飙个200%不是梦。不说废话，直接上干货。
第一个技巧，索引优化别光建，得会用。很多人以为索引越多越好，结果一张表上堆了十几个索引，插入更新慢得像蜗牛。其实，索引是双刃剑。你得先搞清楚查询模式：哪些字段经常被 WHERE 条件用？哪些字段是 JOIN 的关联键？然后只给这些字段建复合索引，顺序也很关键——把选择性高的字段放前面。比如订单表里，状态字段只有几个值，但用户 ID 有上万个，那复合索引就该是 (user_id, status) 而不是反过来。建完索引后，用 EXPLAIN 看执行计划，确认是否走了索引。我见过太多人建了索引，查询还是全表扫，因为用了函数或隐式类型转换。别偷懒，检查一下。
第二个技巧，慢查询日志是你的好兄弟。很多运维嫌日志占空间，直接关了。但你想想，若不知道谁在拖慢系统，怎么优化？打开慢查询日志，设置一个合理的阈值——业务轻松秒级返回的，设 1 秒就够了；复杂报表类的，可以放宽到 5 秒。然后定期分析这些慢查询，找出执行次数多或单次耗时长的。有时，一条 SQL 语句占了 80% 的数据库负载。比如某个后台统计页面，每次加载都跑全表扫描，数据量大了自然慢。这时，加个索引或改写 SQL，效果立竿见影。别等用户投诉才去翻日志，主动监控才是王道。
第三个技巧，连接池要调优，别让连接数成为瓶颈。数据库连接不是无限资源，每建一个连接都要消耗内存和 CPU。连接池太小，请求排队；连接池太大，数据库扛不住。怎么调？先看业务并发量。比如高峰期同时有 100 个请求，连接池设 20‑30 就差不多了，因为每个连接可以复用。另外，设置合理的超时时间。如果某个连接空闲超过 30 秒，果断释放。还有，连接池的健康检查不能少，定期测试连接是否有效，避免僵尸连接占坑。我见过一个系统，连接池设了 200，结果数据库内存爆了，查个简单数据都超时。调小后，性能反而上去了。
第四个技巧，SQL 语句别写得太复杂，能拆分就别一次性写完。很多开发喜欢用一条 SQL 搞定所有事，各种子查询、多层 JOIN、临时表套临时表。结果执行计划变得复杂，内存和 CPU 全耗在排序和关联上。比如要查某个用户的所有订单和订单明细，别用一条大 SQL 联表查，可以先查订单列表，再根据订单 ID 批量查明细。虽然多了几次查询，但每次都简单，数据库能快速返回。更重要的是，这样还能利用缓存。如果业务允许，把复杂查询拆成多个简单查询，配合应用层缓存，性能提升明显。别迷信“一条 SQL 搞定一切”，那是给数据库找麻烦。
第五个技巧，数据归档和分区，让表变轻。表数据量大了，查询自然慢。比如一张日志表，存了三年数据，几千万行。你查最近一个月的记录，数据库也得把老数据扫一遍。这时，分区表就派上用场了。按时间分区，如按月或按周，查询时只扫相关分区，效率翻倍。另外，历史数据别一直留在主表，定期归档到冷存储或归档表。比如业务只关心最近三个月的订单，就把更早的数据迁走。这样主表瘦身，索引重建也快。别舍不得删，数据多了是负担。我有个客户，归档后查询时间从 10 秒降到 0.5 秒，效果立竿见影。
第六个技巧，硬件和配置别忽视，但也不要盲目升级。很多人一遇到慢查询，就想到加内存、换 SSD。可是有时问题不在硬件，而在配置。比如 InnoDB 的缓冲池大小，默认值往往偏保守。如果服务器有 64 GB 内存，可以把缓冲池设到 40 GB 左右，数据在内存里，查询自然快。但别超过物理内存的 70% ，否则操作系统会和数据库抢资源。还有，日志文件大小和刷新策略也值得调。比如把事务日志文件设大一点，减少文件切换频率。硬件升级是手段，先把配置调优，钱花在刀刃上。我见过一个案例，没换硬件，只是调了缓冲池和刷新策略，查询性能提升了 50% 。
这六个技巧听起来都不复杂，但真正落地执行，需要耐心和细心。索引优化让你少走弯路，慢查询日志帮你定位问题，连接池调优避免资源浪费，SQL 拆分减轻数据库压力，数据归档让表更轻，配置调优榨干硬件潜力。每一项都能带来实实在的性能提升。别指望一次优化就一劳永逸，业务在变，数据在涨，优化是个持续的过程。下次遇到数据库慢的投诉，别慌，从这六点入手，一个个排查。200% 的性能提升，真不是吹的，关键是你要动手做。
