上周三晚上十一点，我还在跟一个慢查询死磕。那条SQL跑了整整8秒，用户点一下查询，咖啡都凉了页面还没出来。老板站在我身后，那种压迫感，比数据库连接池耗尽还让人窒息。后来用了三招，8秒变成了0.4秒。今天把这套实战经验拆开揉碎讲给你听，遇到慢查询，别急着加机器，先从这些地方下手。
第一招，也是最容易被忽略的——先看执行计划，别猜。很多人一上来就加索引，加了没用又换一个，跟蒙着眼睛拆炸弹似的。我见过太多人栽在这上面。执行计划就是数据库告诉你它打算怎么干活，是走全表扫描还是索引查找，是嵌套循环还是哈希连接，一眼就能看出来。打开方式很简单，MySQL里用EXPLAIN，PostgreSQL里用EXPLAIN ANALYZE，Oracle里是EXPLAIN PLAN。重点看type列，如果是ALL，说明全表扫描，这是最慢的；如果是ref或者eqref，说明索引生效了，速度会有质变。还有rows列，那是数据库预估要扫多少行，数字越大越危险。我上次那8秒的查询，执行计划里清清楚楚写着全表扫描了一个两千多万行的表，索引被一个函数给废了——where条件里写了DATE(createtime) = '2024-01-01'，这写法让索引直接失效。改成createtime >= '2024-01-01' AND createtime < '2024-01-02'，索引立刻生效，查询时间从8秒直接掉到0.9秒。这还没完，后面还有更狠的。
第二招，索引不是越多越好，而是要精准设计。很多人以为索引是万灵丹，建了七八个索引，结果写入变慢、磁盘占用暴涨，查询也没快多少。实际上，一个复合索引顶得上好几个单列索引。比如你经常按userid和status两个条件查，那就建一个(userid, status)的复合索引，别建两个单独的。这里有个最核心的原则：最左前缀法则。复合索引按照定义顺序生效，你查询条件里必须包含最左边的列才能走索引。我见过有人建了(a, b, c)的索引，然后天天用b和c去查，索引完全没生效，还怪数据库慢。另外，索引列上别做计算，别用函数套，别做隐式类型转换——比如索引列是varchar，你传了个数字进去，数据库得把每行都转一遍才能比较，索引直接废掉。还有一点容易被忽略：区分度低的列别加索引，比如性别、状态这种只有两三个值的列，走索引还不如全表扫得快。你要真想优化，拿区分度高的列做主索引，比如用户ID、订单号、手机号，效果立竿见影。
第三招，改写SQL比调参数管用。很多时候你觉得自己写的SQL挺正常，但数据库执行起来就是慢。问题往往出在写法上。比如SELECT *，你以为方便，实际上数据库得把每一列都读出来，尤其是那些TEXT、BLOB类型的大字段，占用的IO是普通字段的几十倍。你只需要那三个字段，就只查那三个字段，别偷懒。再比如子查询，很多人习惯用IN (SELECT ...)，这在数据量小的时候没问题，数据量一大就完蛋。改成JOIN往往快得多。但JOIN也不是随便写的，小表驱动大表是铁律——用数据量小的表作为驱动表，让大表走索引去匹配，这样IO次数大大减少。还有LIMIT分页，越往后翻越慢，因为数据库得把前面所有行都扫一遍再跳过。解决办法是用覆盖索引或者记录上次查询的一条ID，然后WHERE id > 上次的ID LIMIT 20，速度能快几十倍。这些改写技巧，每一个都是我从线上事故里学来的。
第四招，别让临时文件拖垮你。你执行计划里如果看到Using filesort或者Using temporary，这俩是性能杀手。前者代表排序没法走索引，数据库得把数据放到内存或磁盘上排一遍；后者代表要建临时表，数据量大了直接往磁盘写，慢得离谱。为什么会这样？最常见的原因是你ORDER BY的列和WHERE条件里用的索引列不一致，数据库没法利用索引顺序，只能自己排。解决办法是把排序字段加进复合索引里，让索引顺序和排序顺序一致。另外，GROUP BY和DISTINCT也会触发临时表，如果数据量实在太大，考虑用汇总表——每天凌晨跑一次聚合任务，把结果存到一张小表里，查询直接读小表。我有个项目，原来实时跑GROUP BY统计，三百万行数据要4秒，改成定时汇总后，查询时间变成0.05秒，用户体验直接起飞。这个方法不高级，但绝对实用。
第五招，连接池和缓存配置要跟上。有时候SQL本身没问题，索引也建好了，但整体还是慢，问题出在连接管理上。每次新建数据库连接，TCP握手、认证、权限校验，这些开销加起来要几十毫秒。如果你在高并发场景下频繁创建连接，光握手就占了大头。连接池就是干这个的——复用已有的连接，省去重复建连的开销。HikariCP、Druid、C3P0都是好工具，但配置要合理。核心参数是maximumPoolSize和minimumIdle，别把maximumPoolSize设太大，过大反而让数据库负担加重，一般建议是CPU核心数乘以2再加1。另外，查询缓存也值得关注。MySQL 8.0之前有Query Cache，但8.0直接移除了，因为它在高并发下反而拖慢性能。现在的主流做法是用Redis做应用层缓存，把高频查询的结果缓存起来，设置合理的过期时间。比如商品详情、用户信息这种读多写少的数据，缓存命中率能到90%以上，响应时间直接从几十毫秒降到几毫秒。
第六招，监控和压测是保命符。调优不是一次性的，系统上线后数据量在涨，查询模式在变，索引可能失效，慢查询随时可能卷土重来。所以你必须建立监控体系。最基础的，MySQL打开慢查询日志，设置阈值比如1秒，每天看看哪些查询超时了。PostgreSQL有pg_statements，能统计每一条SQL的平均耗时和调用次数。再配一个像Prometheus加Grafana的监控面板，把数据库的连接数、CPU使用率、磁盘IO、慢查询次数这些指标可视化，趋势变化一目了然。还有压测，别等项目上线了才测。用sysbench或者JMeter模拟真实流量，在测试环境把并发拉上去，看看数据库在什么量级开始崩。我见过太多系统，开发环境跑得飞快，一上线就被用户打垮，就是因为没做压力测试。你提前知道瓶颈在哪，就能提前优化，而不是等用户投诉了才手忙脚乱。
说回开头那晚，我把执行计划一改、索引一调、SQL一重写，8秒变0.4秒，老板满意地走了。但第二天我又花了两个小时把监控和告警搭起来，因为我知道，今天能解决的问题，明天换个姿势还会冒出来。数据库性能调优没有银弹，就是靠这些实打实的排查手段和积累的经验，一层一层把瓶颈抠出来。你把这六招吃透，不说保证快十倍，但至少遇到慢查询的时候，心里有底，手上有活，不会再慌。
