企业官网建设流程全解析

1. 项目概述

1.1 核心需求解析

这几年做数据库相关的咨询和优化工作，接手的慢查询案例没有一千也有八百。说句实话，大部分慢SQL的根本问题不在SQL写法本身，而在索引策略和查询设计上。有些SQL，索引用对了，响应时间能从几秒降到几十毫秒；索引没用对，哪怕数据库配置再高，该慢还是慢。

我要分享的这个SQL优化实战案例，是典型的“线上数据库性能告警，排查后发现源头是一条SQL”的场景。当时生产环境的某张核心业务表数据量已经超过800万行，某条查询语句在业务高峰期平均执行时间达到5.8秒，直接拖垮了下游多个接口的响应速度。项目目标是：在不对业务系统架构做大改动的前提下，通过索引策略调整和SQL改写，把这条查询的响应时间压到500毫秒以内。

本文档的受众，一个是日常要写SQL但没系统想过索引原理的业务开发，另一个是刚入门的DBA或运维工程师。如果你是这两种角色之一，那这篇文章基本就是为你准备的。内容会覆盖：索引底层原理的通俗理解、慢SQL定位手段、索引设计策略、SQL改写技巧、执行计划的解读方法，以及并行优化等高级手段。

1.2 项目背景与性能瓶颈

先说背景。这是一个典型的订单业务系统，订单表（orders）每天新增几万条数据，累计数据量到了800万行左右。业务方反馈：后台的订单查询页面打开特别慢，尤其是按用户ID查历史订单、按订单状态做统计、按时间范围筛选数据时，经常出现超时。

我拿到手上线环境的慢查询日志后，发现了几条典型的慢SQL，其中一条出现的频率最高：

SELECT * FROM orders WHERE user_id = 'U10086' AND order_status = 4 AND create_time BETWEEN '2024-08-01 00:00:00' AND '2024-08-31 23:59:59' ORDER BY create_time DESC LIMIT 100;

这条SQL单次执行平均耗时5.8秒，高峰期甚至能到8秒以上。而且这不是个例——用户在前台每翻一页，就会触发一次类似查询，导致数据库连接池被长时间占满。

当时的索引情况很糟糕。这个表上虽然有一个联合索引，但字段顺序是(order_status, create_time)，user_id根本没用上索引，所以数据库被逼着做全表扫描。800万行数据全扫一遍，再加上排序和回表，5秒多的时间就那么来的。

这个案例非常有代表性。它的核心问题可以拆成三块：第一，索引设计不合理，完全没有考虑实际查询中最常用的过滤字段；第二，查询语句写法有优化空间，包括隐式类型转换、SELECT *等；第三，执行计划没有定期评估，索引建了之后没人持续关注是否真正被用上。你手上如果有类似的问题，仔细对照这三块排查，大概率能找到病根。

2. 索引策略：从原理到实战的核心设计

2.1 索引底层原理的通俗理解

要深入理解索引策略，不能只停留在“建索引查询就快”的层面。我习惯把数据库的索引类比成一本书的目录：没有目录，你想在一本书里找一个名词，只能从头翻到尾；有目录，先定位到章节，再定位到页码，速度自然快。

但数据库索引比书的目录复杂得多。InnoDB引擎用的是B+树结构，这是一种矮胖的多路平衡树。B+树的好处有几个：树的高度低（一般3到4层就能存放千万级数据），查询时只需要几次磁盘I/O就能定位到目标数据；数据都存储在叶子节点，并且叶子节点之间通过链表连接，非常适合范围查询。

实际工作中，我最常提醒开发朋友的几个索引特性：

• 聚簇索引：InnoDB中每张表都有一个聚簇索引，主键就是聚簇索引。叶子节点保存的是整行数据，所以通过主键查询是最快的路径，不需要额外回表。
• 辅助索引：也叫二级索引，叶子节点保存的是索引列和主键值。如果查询的列在辅助索引里都能找到，就不需要回表，这叫覆盖索引。
• 索引下推：MySQL 5.6之后引入的优化手段。多条件查询时，可以在索引遍历过程中直接过滤掉不满足条件的记录，减少回表次数。这个特性默认开启，很多时候你们觉得“索引失效”，其实不是真失效，而是存储引擎提前帮你过滤了。

理解这几个概念之后，再回头设计索引，思路就通了：我们要尽量让查询走辅助索引并命中覆盖索引，尽量避免回表，尽量通过下推减少回表次数。

2.2 联合索引的设计原则

联合索引（复合索引）是这个案例中最关键的一环。很多人知道联合索引，但真正设计时容易踩坑，最典型的就是字段顺序问题。

联合索引的底层逻辑是“最左前缀原则”：MySQL索引中，多个字段是依次排列在B+树的节点中的。查询条件使用索引时，只有从联合索引最左侧的字段开始连续使用，索引才能生效。比如你建了(a, b, c)联合索引，查询条件里有a和c，那只有a能用到索引；如果查询条件里只有b和c，那整个索引都用不上。

拿这个案例来说，orders表原本的索引是(order_status, create_time)。这个索引对“按状态统计订单数”的查询可能有点用，但业务的核心查询是“按user_id筛选订单”，可user_id在索引最左侧根本不存在，于是这个索引等于废了。

给联合索引排字段优先级时，我一般按下面这个顺序判断：

1. 等值查询的字段优先放最左侧。比如user_id = ?，这类字段最能缩小数据范围。
2. 区分度高的字段优先。区分度是指字段不同值的比例。比如order_status可能只有5种值，user_id可能有几十万种，user_id的区分度远高于order_status。区分度越高，索引过滤效果越好。
3. 范围查询的字段放在最后。比如create_time的范围查询，放在最后可以充分利用索引的有序性，避免额外排序。

按照这套逻辑，orders表的索引应该调整为(user_id, order_status, create_time)或(user_id, create_time)。等值字段放前面，范围字段放后面，查询时既能快速定位用户的所有订单，又能在索引上直接按时间排序。

2.3 索引顺序调整的实操经验

调整索引不是建完就完事。我对orders表的索引做了这样的调整：

-- 原索引（低效） ALTER TABLE orders DROP INDEX idx_order_status_create_time; -- 新索引（高效） ALTER TABLE orders ADD INDEX idx_user_status_time (user_id, order_status, create_time);

注意，我故意保留了order_status在联合索引中间，而不是只建(user_id, create_time)。原因是业务上偶尔会有“查某个用户、某种状态、某段时间”的查询，把order_status放进去，还能继续走索引过滤，不至于像原来那样全靠user_id过滤完再在内存里过滤状态。

但是这里有个度的问题。联合索引不是字段越多越好。每多一个字段，B+树节点存储的空间就变大，写入时索引维护成本也变高。如果某个字段只有两种值（比如0和1），放不放进联合索引，实际过滤效果差别不大，反而浪费索引空间。

所以我更推荐的方式是：联合索引不要超过3个字段，尽量紧贴最高频的查询模式。如果你一个表上有多种查询模式，索引宁多勿缺但也不能滥建，一般一个表的总索引数控制在5个以内，不然写入性能会很差。

改完索引之后，你还需要用SHOW INDEX FROM orders;确认索引状态，看Cardinality基数是否正确统计。如果基数明显不准，可能是analyze table没有跑，索引统计信息过期，需要执行ANALYZE TABLE orders;刷新一下。

这一节的内容比较偏概念和设计，但实际价值很大。索引设计对了，后面SQL改写的压力就小很多。下面我们来看看，怎么把一条慢SQL的执行计划真正“解剖”开来。

3. 查询重写：从业务需求出发的SQL改写优化

3.1 SELECT * 的危害与规避

索引策略调整完毕，我接着在测试环境验证。结果很有意思——新索引生效之后，查询快了不少，但离500毫秒的目标还有一些距离。这时候就需要把目光转到SQL本身，开始做查询语句的改写优化。

第一个要改的就是SELECT *。

我一直跟团队开发说：*线上生产环境，尽量不要写 SELECT，尤其是大数据量表。原因不神秘，SELECT * 会导致下面两个问题：

• 覆盖索引失效。如果你只需要user_id、order_status、create_time这三列，而查询恰好能用上索引覆盖，那数据库完全可以只扫描索引，不用回表。但SELECT *意味着要把所有列的数据全查出来，索引里没有的列必须回表，一次回表就是一次随机I/O。数据量大时，回表成本是灾难性的。
• 网络传输成本陡增。SELECT *会把不需要的大字段（比如订单备注、商品快照JSON）也拉出来，传输时间白白增加。

我对这条查询做的改写：业务上这个接口只需要订单号、用户ID、订单金额、订单状态、下单时间、商品名称这几个字段，那就明确列出来：

SELECT order_id, user_id, amount, order_status, create_time, product_name FROM orders WHERE user_id = 'U10086' AND order_status = 4 AND create_time BETWEEN '2024-08-01 00:00:00' AND '2024-08-31 23:59:59' ORDER BY create_time DESC LIMIT 100;

这样做的收益有两点：一是查询的数据量少了，内存排序的临时表更小；二是如果以后建一个包含所有查询列的覆盖索引，甚至可以完全免回表。改写之后，我在测试环境实测，SQL响应时间从5.8秒降到了1.2秒左右，第一波优化立竿见影。

3.2 隐式类型转换与函数陷阱

很多SQL变慢的隐藏原因，是隐式类型转换。MySQL中比较的两个值类型不一致时，会自动把其中一个转换为另一个的类型，这会导致索引失效。

我复盘这个case时，orders表的user_id字段定义是VARCHAR(20)，但接口传参时，ORM框架有可能把参数当成数值类型传进来。如果SQL被翻译成WHERE user_id = 10086，MySQL会尝试把字符串类型的user_id转成数值类型再比较，导致索引列被函数包裹——这跟WHERE DATE(create_time) = '2024-08-01'导致索引失效是同一个道理。

排查方法很简单，跑一下EXPLAIN看执行计划，如果type列不是const或ref，而是ALL，且rows扫描行数远超实际结果集，那八成有类型转换问题。再配合SHOW WARNINGS;可以查看MySQL优化器做了什么额外的转换。

改写方法也很粗暴但有效：保证查询参数类型和字段类型一致。在SQL层面，直接传字符串：

WHERE user_id = '10086'

在程序层面，如果你的ORM是MyBatis，在Mapper.xml里用${userId}时要注意传入值类型，最好统一在Java代码里转成String。如果用的是JPA/Hibernate，参数类型定义规范一点，避免自动装箱转成了Long。这个细节很容易被忽略，但恰恰是很多线上慢SQL的元凶。

另外，还有一类常见的函数陷阱是“对索引列做运算”。比如WHERE amount + 100 > 500，这种写法索引失效；改成WHERE amount > 400就能走索引。再有就是LIKE '%关键词%'，左模糊也必然全表扫描，这种场景要么考虑全文索引，要么改用前缀匹配LIKE '关键词%'。

3.3 深分页问题的解决思路

orders表的查询还有一个经典痛点：后台订单列表要分页，业务方喜欢用LIMIT 800000, 100这种写法。这个写法在数据量小的时候没问题，但一旦偏移量很大，MySQL会先把前800100条数据全部查出来，再丢弃前800000条，只返回最后的100条。

这在索引上体现为：你可能做了几十万次回表，结果只给用户看100行。优化深分页有几个常用方法：

• 延迟关联（延迟连接）。先只从索引上查到符合条件的id列表，再用id去关联完整表：

  SELECT o.*, t.* FROM ( SELECT order_id FROM orders WHERE user_id = '10086' AND order_status = 4 ORDER BY create_time DESC LIMIT 800000, 100 ) t JOIN orders o ON t.order_id = o.order_id;

  这种方法最大的好处是子查询走覆盖索引，不需要回表；只有最后那100条确定的订单才去关联，成本大幅降低。

• 记录上次查询的游标。如果是用户下拉加载更多，不要用页码翻页，而是记住上一页最后一条记录的create_time和id，下一批查询用WHERE create_time < '2024-08-20 12:00:00'来实现。游标分页对深分页的优化效果最彻底，因为它把O(N)的扫描变成了O(1)的定位。

这个案例中，我对订单查询接口做了分批游标化的重构。由于接口是基于“下拉加载更多”设计的，直接把分页参数从pageNo/pageSize改成了lastCreateTime + offset的方式，配合索引效果极佳，剩余耗时的瓶颈几乎消失。如果你们的系统不是这种交互方式，那延迟关联也是最稳妥的降级方案。

3.4 覆盖索引在SQL改写中的妙用

前面一直在说覆盖索引，这里详细说下到底怎么用。覆盖索引不是独立的“索引类型”，而是一种“索引刚好覆盖查询所需列”的优化状态。

比如我们要高频执行的查询是查订单列表，需要显示order_id、amount、order_status、create_time、product_name。那可以设计一个专门针对这个查询场景的联合索引：

ALTER TABLE orders ADD INDEX idx_user_cover (user_id, order_status, create_time, order_id, amount, product_name);

这个索引包含的字段覆盖了查询的所有列，当查询条件命中user_id等前缀字段时，MySQL只需要扫描这个B+树索引，就能拿到所有需要的数据，完全不需要回表查聚簇索引。对数据量大的表，这种优化减少的I/O次数是非常可观的。

不过覆盖索引的坑也在于：字段越多，索引文件越大，写入越慢。生产环境不能单纯追求覆盖所有查询列。我的建议是：核心查询建一个覆盖索引，次要查询允许回表，在保证写入性能的前提下尽量提升读性能。

在这个项目里，我在第一次改完索引后，发现users查询场景其实是两个：一个查列表需要显示商品名称；一个做统计只要count和金额。这两个场景拆分后，分别建不同的覆盖索引，效果比一个大而全的索引好得多。

4. 执行计划分析：用EXPLAIN锁定性能瓶颈

4.1 执行计划关键字段解读

SQL改写和索引调整之后，就到了验证效果和锁定瓶颈的环节。MySQL的EXPLAIN是分析查询性能最重要的工具，没有之一。很多人只会看type是不是ALL（全表扫描）或者有没有用到索引，但其实执行计划里能挖的信息特别多。

EXPLAIN输出中，我重点关注如下几个字段：

• type：连接类型。从上到下性能从好到差大致是：system > const > eq_ref > ref > range > index > ALL。如果看到ALL，优先考虑优化索引。
• key：实际用到的索引。如果是NULL，说明没有命中任何索引。
• rows：优化器预估需要扫描的行数。这个数字跟实际执行的行数往往接近，可以直接用来判断查询成本。
• filtered：经过索引条件过滤后，剩余行数的百分比。比如rows是10000，filtered是10，表示最终只留1000行。这个值越低，说明索引过滤效果越好。
• Extra：这里最容易暴露问题。出现Using filesort说明排序没走索引，Using temporary说明用了临时表，Using index说明覆盖索引生效。这几个状态分别对应不同的优化方向。

以优化后的orders查询为例：

EXPLAIN SELECT order_id, user_id, amount, order_status, create_time, product_name FROM orders WHERE user_id = '10086' AND order_status = 4 AND create_time BETWEEN '2024-08-01 00:00:00' AND '2024-08-31 23:59:59' ORDER BY create_time DESC LIMIT 100;

执行计划的输出大致是：

id select_type table type possible_keys key rows filtered Extra 1 SIMPLE orders ref idx_user_cover idx_user_cover 1286 8.33 Using where; Using index

type是ref，说明走的是非唯一索引等值匹配，key命中了新索引，rows只有1286行，filtered只有8.33，Extra中出现了Using index。这基本就是一条健康查询的理想状态了。

4.2 从实际案例倒推优化方向

我在优化过程中遇到过一个比较典型的性能问题：一条计数类SQL特别慢，慢到页面加载直接超时。原SQL大概是：

SELECT COUNT(*) FROM orders WHERE user_id = '10086' AND order_status = 4 AND create_time BETWEEN '2024-08-01 00:00:00' AND '2024-08-31 23:59:59';

原因是COUNT(*)本来想统计某个用户的订单数，但orders表非常大，即使走了二级索引，也要扫描大量索引行来做精确统计。我第一反应不是改SQL，而是先问业务方：“这个统计是实时的吗？”业务方说，页面展示用，允许分钟级延迟。

于是我把这条统计SQL改成了走预聚合方案：每天定时任务把前一天的用户订单统计结果写到一张统计表，查询的时候直接查统计表。

-- 建一张订单统计表 CREATE TABLE orders_daily_stats ( user_id VARCHAR(20) NOT NULL, stat_date DATE NOT NULL, order_count INT NOT NULL, total_amount DECIMAL(12,2) NOT NULL, PRIMARY KEY (user_id, stat_date) ) ENGINE=InnoDB; -- 定时任务每个小时汇总一次 SELECT user_id, DATE(create_time) AS stat_date, COUNT(*) AS order_count, SUM(amount) AS total_amount FROM orders WHERE create_time >= NOW() - INTERVAL 1 DAY GROUP BY user_id, DATE(create_time);

实时精确count在这种量级的表上，本身就是一种性能奢求。做OLTP事务和做分析统计的需求，不应该挤在同一张表的同一条慢SQL上。你如果遇到类似场景，不妨先问一句：“这个统计结果一定要绝对实时吗？”如果答案是否定的，就大胆改成预聚合。

另外还有一个count优化的小技巧：MySQL里COUNT(*)和COUNT(1)在InnoDB下性能基本一样，没有区别。但走二级索引的count，要比走聚簇索引快很多，因为二级索引的叶子节点更小，相同数据量，索引页数量更少，扫描的I/O自然更少。

4.3 回表次数与Using filesort的优化

执行计划的Extra字段如果出现Using filesort，这是一个强烈的信号：ORDER BY字段没有利用上索引的有序性。MySQL需要先把查询结果放入内部排序缓冲区，再执行快速排序，最后返回结果。当结果集很大时，filesort的开销非常明显。

在这个案例里，原始SQL有ORDER BY create_time DESC。我们建立(user_id, order_status, create_time)联合索引后，因为create_time在索引中是按升序排列的，MySQL在遍历索引的时候就已经是有序的，ORDER BY就不再需要filesort了，直接在索引末尾反向取100条就行。这是索引设计的一个隐藏红利。

我见过太多开发同事，SQL写得好好的，字段也建了索引，但就是慢，一查EXPLAIN，Extra里赫然写着Using filesort。这种问题一般就是索引字段的设计顺序和ORDER BY不一致。比如你建的索引是(user_id, create_time, order_status)，查询里ORDER BY create_time能走索引，但如果改成ORDER BY order_status, create_time，那又只能用filesort了。

有一条经验供参考：尽量让ORDER BY的字段和联合索引中的字段顺序保持一致，并且排序方向一致（全升序或全降序）。如果业务要求部分字段升序、部分字段降序，MySQL 8.0的降序索引可以处理，但如果你用的是MySQL 5.7，这种情况通常还是避免不了filesort。

回表次数的控制，则可以看EXPLAIN中的rows和实际返回的数据量。比如rows显示扫描了1286行，但最终只返回100条，这说明有1186行被查询条件过滤掉了。如果这些行分布在不同的数据页上，MySQL就要做大量随机I/O。如果Extra显示Using index，说明数据都在索引上，过滤过程不涉及回表，那这个查询就是非常高效的。

5. 并行优化：多核时代的SQL提速手段

5.1 并行度的合理配置

到了这一节，相信前面几个步骤做完，你的SQL已经比原来快了不少。但如果你处理的是更大的数据表，比如几千万甚至上亿行的报表查询、批量数据加工，单线程的SQL执行效率再怎么优化也有天花板。这时候可以考虑引入并行处理思路。

MySQL 8.0之前，InnoDB的查询是单线程的，一条SQL只能用上单核CPU。于是对于超大表的聚合操作，业界普遍的做法是引入并行计算框架（如Spark、Presto）或者做数据分片。但MySQL 8.0之后，InnoDB引擎在部分扫描场景下原生支持了并行扫描（在8.0.14以后逐步增强），最典型的是COUNT()和全表扫描的聚合操作。

如果你使用的是MySQL 8.0，可以先确认并行扫描是否生效：

SHOW VARIABLES LIKE 'innodb_parallel_read_threads';

默认值通常是4，最大可调到32。这个参数控制的是InnoDB扫描过程中用于并行读取数据的线程数。对于大表COUNT操作，调大这个参数可以明显缩短执行时间。我的实测经验是：

不过要注意，并行线程数不是越大越好。线程数过高会引发大量的上下文切换，反而拖慢性能。建议以CPU核数为基准，设置为物理核数的一半到全部之间。另外，并行扫描只对“扫描类操作”有效，对于ORDER BY和GROUP BY这类需要在内存里做二次处理的查询，优化效果不明显。

5.2 从业务侧拆分大查询

如果数据库版本比较老，走不了并行扫描，还有一种普适性更强的方案：把一条大SQL拆成多条小SQL并发执行。

举个例子，之前我处理过一个客户数据系统，需要统计4000万行数据的月度报表，原始SQL是：

SELECT user_id, COUNT(*), SUM(amount) FROM orders WHERE create_time BETWEEN '2024-08-01' AND '2024-08-31' GROUP BY user_id;

这条SQL在MySQL 5.7上跑了接近40秒。我把数据按user_id的hash拆成16个分片，每个分片用一条独立SQL查询，再在应用层把16个结果合并：

-- 分片0：user_id hash后末尾为0的数据 SELECT user_id, COUNT(*), SUM(amount) FROM orders WHERE create_time BETWEEN '2024-08-01' AND '2024-08-31' AND MOD(CRC32(user_id), 16) = 0 GROUP BY user_id; -- 分片1：MOD(CRC32(user_id), 16) = 1 -- ... 以此类推，共16条

在应用层用线程池并发执行这16条SQL，每条耗时大约8~12秒，整体控制在15秒以内，比原来单条40秒快了一倍多。这个思路本质上是把数据库的压力分摊到多个CPU内核上，相当于应用层的“并行查询”。

需要注意的是，拆分的维度要选对。分片字段必须和查询条件里的等值字段强相关，不能随机拆。最理想的是按user_id、shop_id这类业务实体的ID来分，这样每个分片内部的数据天然有边界，合并时也不会出现重复或遗漏。

5.3 并行优化与索引优化的协同关系

并行优化不是用来替代索引优化的，两者是合作关系。如果一条SQL连索引都没建对，全表扫描几百万行，就算并行度拉满，效果也是杯水车薪。反过来，如果你索引已经做到极致，但受限于CPU单线程瓶颈，并行优化就能帮你突破最后那几倍的性能提升。

我的建议是记住下面这个优先级：

1. 索引设计解决“要不要扫那么多数据”的问题——这是最大的、成本最低的优化空间。
2. SQL改写解决“怎么扫更聪明”的问题——减少不必要的回表、排序、分组。
3. 并行优化解决“怎么扫更快”的问题——把剩余无法避免的扫描负载分摊到多个线程上。

这个case里，我正是按照这个顺序做的：先调索引，再改SQL，最后当发现统计类的查询依然偏慢时，才考虑做并行拆分。老实说，八成以上的慢SQL到第二步就能解决，并行优化属于锦上添花的手段。千万不要一开始就想着并行，那是舍本逐末。

6. 常见问题与排查技巧实录

6.1 索引失效的常见原因排查

做SQL优化的高频问题，就是“我明明建了索引，为什么查询还是慢”。这个问题基本可以归纳为下面几个原因：

• 查询条件里对索引列做了函数运算。比如WHERE DATE(create_time) = '2024-08-01'，改成WHERE create_time >= '2024-08-01 00:00:00' AND create_time < '2024-08-02 00:00:00'。
• 隐式类型转换。比如varchar字段传了数值进来。熟练的DBA会告诉你：只要看到执行计划的key为NULL，优先查这个。
• LIKE左模糊。LIKE '%abc'走不了索引，LIKE 'abc%'可以。
• OR条件里有非索引列。WHERE user_id = '10086' OR product_name = 'xxx'，如果product_name没有索引，整个查询可能走全表扫描。可以把OR拆成两个查询用UNION合并，或者给product_name也建上索引。
• 联合索引未遵守最左前缀原则。前面已经详细讲过，这是设计问题。

排查索引失效最顺手的工具还是EXPLAIN。如果你的type等于ALL但明明有索引，一步步对照上面的五条来筛查，基本不会跑偏。

6.2 慢查询日志的分析方法

慢SQL日志是SQL优化工作的起点。以MySQL为例，开启慢查询日志有两种方式，一种是临时开启（重启失效），一种是修改配置文件永久生效。

-- 临时开启慢查询日志，阈值2秒 SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

生产环境建议把long_query_time设置为1秒甚至0.5秒，因为互联网应用的接口响应标准普遍在1秒以内。把阈值设成1秒，可以提前捕获到那些“还是有点慢但勉强没引发事故”的SQL。

拿到慢查询日志后，推荐用mysqldumpslow或pt-query-digest做聚合分析，重点看两类指标：

• 查询总耗时占比：哪些SQL累计占用了数据库最多的执行时间，它们就是核心优化目标。
• 平均查询耗时：平均耗时高的SQL，多半是索引设计问题；平均耗时低但执行次数极多的SQL，要考虑能不能通过缓存或预聚合减少执行次数。

在这个项目的复盘里，我第一天做的就是慢查询日志聚合，从100多条慢SQL里筛出最核心的5条，分给团队按优先级去优化。没有这一步，你会被各种看起来都慢的SQL淹没，不知道从哪里动手。

6.3 优化前后的数据对比与验证

优化完了不能拍拍屁股走人，要有一套明确的验证机制。我的常规做法是分三步：

第一步，测试环境复现。把生产环境的典型数据量缩放到测试环境（比如按比例抽取100万行），跑优化前后的SQL，对比执行时间、扫描行数和CPU消耗数据。这里最重要是数据分布要接近生产，否则优化效果可能失真。

第二步，生产环境的灰度准备。在业务低峰期执行一次EXPLAIN，确认最终执行计划符合预期，同时观察数据库的慢查询日志，确认优化后的SQL不再出现在慢日志列表中。

第三步，监控与回归验证。上线之后，重点盯三样东西：接口平均响应时间、数据库CPU使用率、慢查询数量。如果三样都有明显下降，这次优化就算真正落地了。

这个case最终的效果：orders表核心查询从5.8秒降到了接近180毫秒，整体接口响应提升了30倍左右；数据库高峰期CPU使用率从72%降到了38%，慢查询日志里的该条SQL彻底消失。数据说明，在整个优化链路中，索引策略调整占了大头，SQL改写次之，并行优化作为辅助手段处理了统计类查询的最后瓶颈。

6.4 一个容易被忽视的细节：统计信息过期

最后分享一个很多人容易踩的坑：索引建好了，数据量变化很大，但统计信息没更新，优化器选错了执行计划。

InnoDB的优化器依赖统计信息来决定走哪个索引。如果一张表的数据从100万增长到了800万，但统计信息还是老的，优化器可能仍然以为“这个索引选择度不高”，从而选择全表扫描。

遇到这种情况，刷新统计信息的方式很简单：

ANALYZE TABLE orders;

但注意，不要在业务高峰期频繁执行ANALYZE，它本身也有IO开销。可以在每日维护窗口执行，顺便更新所有核心表的统计信息。

如果ANALYZE之后优化器仍然不走最优索引，可以强制指定索引来验证效果：

SELECT ... FROM orders FORCE INDEX(idx_user_status_time) WHERE ...;

这个方式适合在排查阶段使用，验证索引是否真的有效。但要明白，这不是长久之计，SQL里硬写FORCE INDEX在数据分布变化后可能反噬，最终还是要从索引设计和统计信息上解决问题。

回到项目本身，这次SQL优化给我最大的启发其实不是具体的哪条语句或哪个参数，而是一套标准化流程的价值：慢日志发现问题 → 执行计划定位瓶颈 → 索引策略调整 → SQL改写优化 → 性能验证回归。这套流程不需要高深的理论，但每一步都踏踏实实。你如果正在被慢SQL折磨，不妨先别急着搜“优化技巧”，而是把这条链路从头到尾走一遍，很多问题会在过程中自动浮出水面。