永远雪山说实话，我以前对MySQL优化这事儿多少有点不以为然。总觉着表结构设计得差不多、索引建上几个、SQL能跑就行，真出问题加个内存或者换台好点的机器，不也一样能用？直到去年接手了一个订单查询系统，线上频繁报警，一个列表接口从最开始的200毫秒慢慢涨到3秒多，数据库CPU动不动就飙到90%以上，慢查询日志刷屏刷得我看都不愿意看。那时候才真正意识到，不把索引、SQL和分库分表这套东西吃透，光靠加机器纯粹是烧钱买罪受。
这篇文章就是冲着这个问题来的。我会结合那次完整的整改过程，把索引设计、SQL改写、以及最终走上分库分表这条路的来龙去脉和实操细节拆开揉碎讲清楚。内容偏实战，每个结论都尽量给出判断依据和适用场景，不是单纯罗列知识点。适合正在跟慢查询搏斗的后端开发、DBA，也适合准备MySQL面试、想系统梳理优化思路的同学。
1. 优化前的系统现状与问题定位
1.1 线上第一现场：到底哪里慢了
先说说那个订单查询系统的处境。单表订单数据量在6500万行左右，每天新增约30万行，因为分仓、分渠道做了大量的冗余字段，单行数据又宽又长。列表页查询条件特别多：订单号、用户手机号、用户ID、下单时间区间、订单状态、支付状态、商品名称模糊搜索，这些条件用户想怎么组合就怎么组合。
当时的接口慢主要慢在三块。第一是列表查询本身，因为前端要做筛选、排序、分页，所以SQL语句是一个大JOIN带一堆WHERE条件的形态。第二是统计接口，页面顶部要展示“符合当前筛选条件的订单总数和成交金额”，这个COUNT和SUM是实时算的，数据量一大就特别吃力。第三是导出功能，一次导出一两万条数据，SQL写得不好直接把从库拖垮。
我先做了一件事：把慢查询日志的阈值从默认的10秒调到1秒，跑了大概三个小时，捞出来1000多条慢SQL。分析之后发现，高频慢SQL全部命中这么几个特征——索引用不上、MySQL选错索引、或者干脆没走索引走了全表扫描。说句难听的，一半以上的慢SQL，优化索引之后能直接提速一个数量级；剩下那些，才是SQL写法本身的问题。
1.2 排查手段：EXPLAIN是永恒的起点
面向慢SQL，我习惯的第一步永远是EXPLAIN，而不是猜。EXPLAIN的输出结果里，有几个字段我要反复强调：type、key、rows、Extra。
type字段是访问类型，从好到差大体是system > const > eq_ref > ref > range > index > ALL。实际业务SQL里，能到ref和range就已经算不错，出现ALL就得警惕全表扫描。index看着比ALL好一点，但它表示扫描了整个索引树，数据量大时同样不行。key字段表示MySQL实际选中的索引，有时候你明明建了索引它不用，这就要去看为什么。rows是预估扫描行数，它和实际行数差距越大，说明优化器对数据分布的判断越不准，统计信息可能过期了。
Extra字段更是藏着大量线索。出现Using filesort，说明排序没有走索引，数据量一大就要额外排一次；出现Using temporary，说明要用临时表，GROUP BY或者DISTINCT很容易引发；出现Using index，这是好事，说明索引覆盖了所有需要的字段；但如果出现Using where，则说明存储引擎层返回数据之后，Server层又做了一次条件过滤，一般情况下意味着索引下推没完全发挥作用或者部分条件没法用到索引。
我当时的处理习惯是：把慢SQL一条条EXPLAIN之后，按“扫描行数x访问类型”做个粗略排序，优先处理那些rows在百万级别以上、type=ALL的语句。因为这一类语句对数据库的冲击最大，一旦并发上来，直接就能把CPU打满。这里顺便说一句，定位慢SQL一定不要只盯着平均耗时，要看P99耗时和扫描行数的乘积。有些SQL平均耗时不高，但是被调用了上万次，累积起来的资源消耗非常吓人。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 索引设计：从B+树到联合索引的最佳实践
2.1 为什么索引能提速：一次有去有回的数据查找
索引加速查询的原理，往简单里说，就是数据无序、索引有序。MySQL默认的InnoDB引擎用的是B+树索引，叶子节点存的是整行数据（聚簇索引）或者索引列加主键值（二级索引）。B+树相比二叉树，最大的优点是矮胖，三层树高就能轻松存放千万级数据。也就是说，你从根节点走到叶子节点，大概只需要三次磁盘I/O，这跟全表扫描老老实实读几千万行完全是两个量级。
理解“有去有回”这件事，对优化特别重要。当你通过二级索引查数据时，如果查询列不在索引里，MySQL要先在二级索引的B+树里找到对应的主键值，再拿着主键值回到聚簇索引里查一次完整数据行，这个过程叫回表。回表次数越多，查询就越慢。这也是为什么我后面会强调覆盖索引的价值——如果能做到查询列全都在索引里，那就连回表都省了，Extra里直接显示Using index。
回到那个订单场景，订单号查询就是典型的等值查询，给订单号建唯一索引之后，走的是const访问类型；用户手机号+下单时间属于高频组合筛选条件，单独建两个单列索引效果有限，需要联合索引来支撑。这个过程中最重要的一课是，索引不是越多越好，而是越贴合查询模式越好。
2.2 联合索引设计：遵循最左前缀，但别把它当圣旨
联合索引有一个最核心的规则：最左前缀原则。比如你建了一个(a, b, c)联合索引，那数据库会先把a排好序，再在a相同的情况下排b，再在b相同的情况下排c。这带来的直接结果就是：查询条件里只有包含a的时候才能用上这个索引；只查b和c，则索引基本没用。
但是“最左前缀”不是说你WHERE条件里一定要把所有索引列都写全，而是说你从第一列开始连续命中就行。例如(a, b, c)索引可以支持a、a+b、a+b+c这三种条件组合；如果条件是a+c，则只有a能用到索引，c只能作为过滤条件，在索引返回结果之后再过滤一遍。
我当时给订单表设计的联合索引里，有一个是(user_id, order_status, pay_time)。设计思路是：用户查看自己的订单，这是最高频场景，所以user_id放第一位；同一个用户下的订单按状态筛选，order_status放第二位，能过滤掉大量不需要的行；pay_time放最后，用于支持时间排序和范围查询。看起来挺合理，但实际使用中MySQL优化器并不一定每次都走这个索引。有时候用户ID的区分度并不高，或者优化器分析统计信息后认为走另一个索引成本更低，它就会选择别的路径。
这里有个值得养成的习惯：定期用SHOW INDEX FROM table_name查看索引基数，也就是区分度。如果某列的基数远小于表行数，说明大量数据重复，这类列是不适合单独放联合索引最前面的。索引设计不是一次性工作，它要跟着业务查询模式和数据分布不断调整。
2.3 索引失效的几个场景：每一个都是踩过的坑
聊索引优化，就绕不开索引失效。我在这次排查中总结了几类高频翻车现场。
第一类是函数操作。在索引列上使用了函数或者表达式计算，索引就会失效。比如WHERE DATE(create_time) = '2024-01-01'，这个写法哪怕create_time上建了索引也走不了，因为MySQL需要对每一行先计算出DATE(create_time)的值才能比较，索引排好序的原始值帮不上忙。正确写法是范围查询：WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'。
第二类是隐式类型转换。字段是varchar类型，传参却传了数字，MySQL会先把字段转成数字再比较，等于对索引列做了隐式函数操作，索引失效。比如user_phone字段存储的是字符串，WHERE user_phone = 13800138000，看起来很合理对不对？实际上这个查询会扫描全部数据。正确做法是传字符串：WHERE user_phone = '13800138000'。
第三类是LIKE前缀模糊。索引B+树的排序决定了它只能从左到右匹配，所以LIKE 'abc%'能走索引，LIKE '%abc'和LIKE '%abc%'基本只能全表扫。业务里做模糊搜索，要么用前缀匹配，要么考虑搜索引擎，非要子串匹配就别指望MySQL索引能帮上忙。
第四类是联合索引中间列断档。前面说过，联合索引(a, b, c)如果条件跳过了b，只写a和c，那么c就用不上索引。解决办法是根据实际查询频次，把查询条件重新排列或者拆成多个索引组合。
第五类是范围查询右边失效。联合索引里出现范围查询，例如a > 100 AND b = 5，范围查询右边的列b就无法利用索引排序和查找了。这是B+树的结构决定的，所以设计联合索引时，通常把等值查询的列放在前面，范围查询列放后面。但也不能太死板，如果范围列本身区分度极高，把它放前面整体收益可能更大，这个需要实际用EXPLAIN验证。
2.4 覆盖索引与索引下推：让查询不再“回表”
覆盖索引是联调优化里的一个利器。说白了就是索引的叶子节点上已经包含了查询需要的所有列，查询从头到尾只扫描索引文件，不用回表。我的订单列表页原先有个高频SQL要查订单号、状态、金额、支付时间，最初SELECT了一堆大字段比如收货地址、备注，导致回表次数特别多。后来我把查询字段精简化，让最核心的列表查询命中了(user_id, order_status, pay_time, order_no, total_amount)这个联合索引，扫描行数没变，但每条数据都不用回表了，查询耗时直接下降了一半还多。
索引下推是MySQL 5.6之后的一个优化特性，英文叫Index Condition Pushdown，简称ICP。它的作用简单说，是让存储引擎层在扫描索引时就把部分WHERE条件先过滤掉，减少回表次数。举个实际例子，联合索引(a, b)，查询条件是a = 1 AND b LIKE 'abc%'。在ICP出现之前，存储引擎只凭a = 1把一批索引项返回给Server层，再由Server层去过滤b LIKE；有了ICP之后，存储引擎在索引遍历过程中就把b LIKE过滤掉了，回表次数明显减少。想让ICP生效，EXPLAIN的Extra字段里会看到Using index condition。我之前一直没注意这个字段，后来才意识到它对联合索引模糊匹配场景的优化价值。
这段实操下来的核心体会是：索引设计要先充分了解业务查询模式，再决定建哪些索引、索引里放哪些列，而不是每个查询条件都单独建一个索引。多列独立索引不仅浪费空间，还会让优化器难以抉择，甚至在多个单列索引之间做Index Merge，效果反而不如一个联合索引稳定。
3. SQL改写优化：从执行计划反推问题SQL
3.1 建立慢SQL发现机制：把问题找出来才能改
那次整改之前，我们团队对线上SQL质量基本处于“瞎”的状态，没人知道哪个SQL慢，哪个SQL跑得频繁，直到用户反馈页面卡了才去查。后来我做的第一件事就是普及慢查询日志配置。
在MySQL里，通过SET GLOBAL slow_query_log = ON开启慢查询日志，通过SET GLOBAL long_query_time = 1设置阈值。我一般还会加一个log_queries_not_using_indexes = ON，把那些没走索引的查询也记录下来，防止将来数据量变大才暴露问题。生产环境建议写到配置文件里持久化，别只SET GLOBAL，因为重启后设置会丢。
看到慢SQL之后，我习惯丢进EXPLAIN里看执行计划。EXPLAIN的结果看起来是一个表格，但读它的时候要有顺序感：先看type看有没有全表扫描，再看key看有没有用上预期索引，然后看rows看预估扫描行数和实际数量差异大不大，最后看Extra里有没有Using filesort或Using temporary。有一次我发现一条SQL的type明明是range，但rows显示要扫描800万行，仔细排查才发现是联合索引列顺序不对，范围查询列放在了最前面，MySQL为了拿到后面那几列的有序数据，只能把范围内所有数据都读进来再过滤，排序功能完全没利用上。
3.2 IN和EXISTS：别迷信绝对规则
关于IN和EXISTS哪种写法更快，网上能吵翻一页又一页帖子。但实际经历告诉我，MySQL优化器在5.6版本之后对IN和EXISTS做了很多改写，两种方式在绝大多数场景下性能差异并不大。真正影响性能的不是你用了IN还是EXISTS，而是子查询是否被优化器转换成了semi-join，以及关联字段是否有索引。
我记得之前有个统计SQL，查的是“某个时间段内，在指定商品集合里下单的用户数”。刚开始用了IN子查询：
sql复制SELECT COUNT(DISTINCT user_id)
FROM orders
WHERE product_id IN (
SELECT product_id
FROM products
WHERE category_id = 10
)
AND create_time >= '2024-01-01'
AND create_time < '2024-02-01';
orders表有3000多万行，这个SQL每次要执行十几秒。EXPLAIN一下，发现子查询被先物化成临时表，然后和orders表做关联，临时表没有索引，关联时等于每行都去扫临时表，慢得离谱。
改法其实不复杂，把IN改成JOIN，让products表作为驱动表，order表走product_id上的索引：
sql复制SELECT COUNT(DISTINCT o.user_id)
FROM orders o
INNER JOIN products p ON o.product_id = p.product_id
WHERE p.category_id = 10
AND o.create_time >= '2024-01-01'
AND o.create_time < '2024-02-01';
修改之后执行时间从十几秒降到不到一秒。这条经验让我明白：别背“小表驱动大表”这种口诀，重点是你得让被驱动表的关联列上有索引。驱动表全表扫描几万行并不可怕，被驱动表每一行都去全表扫描那才是灾难。
3.3 深分页优化：LIMIT offset越大越慢的终极解法
列表页一旦数据量大，就会遇到一个经典问题：翻到第100页时，SQL是LIMIT 9900, 20。MySQL并不是只读9900到9920这20行，它要先把前面9900行全部查出来，再丢弃掉，这显然非常浪费。
我这次遇到的情况正是一张订单列表翻页很深，用户经常一翻就是几百页。优化前SQL长这样：
sql复制SELECT order_no, total_amount, status
FROM orders
WHERE user_id = 123456
ORDER BY create_time DESC
LIMIT 400000, 20;
EXPLAIN显示rows扫描了40多万行。这种SQL单纯加索引已经救不回来了，因为排序之后还需要跳过前面40万行记录。
最终我用的是延迟关联方案，也叫延迟JOIN。思路是先利用索引快速定位到当前页需要的主键ID集合，再通过主键回表取出完整数据：
sql复制SELECT o.order_no, o.total_amount, o.status
FROM orders o
INNER JOIN (
SELECT id
FROM orders
WHERE user_id = 123456
ORDER BY create_time DESC
LIMIT 400000, 20
) tmp ON o.id = tmp.id
ORDER BY o.create_time DESC;
内层查询只需要扫描二级索引，二级索引比聚簇索引小得多，同样扫描40万行代价低很多；外层再拿着20个主键值回表查具体数据。实测之后，这个SQL的耗时从1.8秒降到了0.2秒左右。对深分页来说，这算是性价比最高的优化方式。
如果业务允许，还有一种更生猛的方式是“基于游标分页”，也就是前端把上一次翻页的最后一条记录的排序字段值传回来，SQL写成WHERE create_time < '上一次的值' ORDER BY create_time DESC LIMIT 20。这样数据库只需要从某个位置往后读20条，连前面那些行都不扫了。可惜很多产品交互形态不支持这种改动，所以延迟关联反而是通用解法里最实用的。
3.4 少用SELECT *，也别一股脑什么都SELECT
这个建议看起来老生常谈，但我在EXPLAIN的时候真实体会到了差别。SELECT *会把所有列都查出来，哪怕你只展示列表页那几列。对InnoDB来说，如果查询列全部包含在索引内，就能触发覆盖索引，一旦你SELECT了不在索引里的列，强制回表，性能直接掉档。
还有一个小坑，是不加必要限制条件的UPDATE和DELETE。这种语句在测试环境可能没问题，到了生产环境没有WHERE条件，或者WHERE条件的列没索引，你就是把整张表锁住，其他业务全部堵死。我在那个项目里遇到过一次半夜跑批任务，一个UPDATE语句基于时间范围做更新，结果时间列因为函数转换失效索引，最后锁定了将近一千万行，把整个订单服务拖到超时。后来总结经验就一句话：在上线前必须用EXPLAIN确认UPDATE和DELETE的WHERE条件能走索引，并且预估影响行数，绝不能拍脑袋直接执行。
4. 分库分表：一张订单表撑不住之后怎么办
4.1 分库分表的界限：不是数据量大就要拆
分库分表听着是大招，但不能乱用。很多人一听说单表几千万行就害怕，其实在合理索引和SQL优化前提下，单表几千万行仍然可以跑得很快。拆分的真正触发条件，是数据量增长已经导致索引维护成本过高、写入性能下降、以及单库的CPU、内存、磁盘I/O都顶不住了。
当时我们遇到的标准信号有这么几个。第一，单表查询即使命中了索引，响应时间也稳定在1秒以上，而且随着数据量继续增长，这个数字还在缓慢抬升。第二，热数据和非热数据混在一张表里，但归档机制迟迟没做，表的体积已经超过200GB。第三，高峰期订单写入的TPS到达瓶颈，单库的写入延迟明显变高，还伴随大量的锁等待。
这里必须提醒一句，分库分表带来的复杂度远超普通索引优化。拆分之后，跨库JOIN没了、事务跨库了、分布式ID要想办法、COUNT统计要聚合、分页排序要汇总、数据迁移要平滑，每一件事都够折腾的。所以我的建议顺序是：优先考虑索引优化、SQL改写、引入缓存、读写分离、冷热数据归档。这些招全使完还顶不住，再动分库分表。千万别一上来就拆，那是用全公司的复杂度换暂时的性能。
4.2 分库分表方案选型：垂直还是水平，先搞清楚拆什么
分库分表在方向上分为两类。垂直拆分是把一张宽表拆成多张窄表，或者把不同业务域的表放到不同数据库。比如订单主表存高频字段，订单扩展表存低频大字段，这属于垂直分表；把订单库和用户库分开部署，这是垂直分库。垂直拆分的核心思想是冷热分离、按业务边界划分，实现起来相对简单，但解决不了单表数据量持续膨胀带来的单表扫描问题。
水平拆分是把同一张表的数据按某个规则分散到多张结构相同的表或多个数据库中。比如把订单表按用户ID取模，拆成order_0、order_1、order_2等等，各自落到不同的库。水平拆分才是真正解决单表数据量过大、读写性能瓶颈的手段。我们当时的订单表就是做了水平拆分，把6500万行数据按照用户维度分散到多个分片里，每个分片的数据量瞬间降到百万级别，查询效率提升非常明显。
选择哪个方向，要看瓶颈到底是什么。如果表里大字段多导致行宽太大、缓存命中率低，优先垂直；如果一张表的行数已经多到索引层级和磁盘I/O都扛不住，那就要水平拆分。实际项目里经常是两步结合，先垂直瘦身，再水平扩展。
4.3 分片键的选择：一步错步步错
分片键是整个水平分库分表设计里最需要谨慎决定的环节，因为一旦上线，想要更换分片键堪比给火车换轮子。在选择之前需要先梳理所有核心查询的WHERE条件里，哪些字段出现频率最高，而且这些字段本身有足够的基数，不容易产生数据倾斜。
订单系统的天然候选者是user_id。因为绝大多数查询是“某个用户查自己的订单”，以user_id为分片键，数据天然能按用户打散，同时单用户查询可以精确路由到唯一分片，不需要在所有分片里全跑一遍。订单号的查询频率也不低，但不能作为分片键，因为用户输入订单号的时候并不知道这条订单属于哪个分片。这种场景需要在分片键之外，再额外维护一张订单号和user_id的映射关系表，或者干脆在生成订单号时把分片信息编码进去。
这里我经历过一次教训。在设计阶段，有人提出用下单时间作为分片键，思路是按月分表。乍一听好像挺合理，每月一张新表，归档也方便。但后来我算了一笔账：绝大多数线上的实时查询都是查最近三个月甚至最近一个月的订单，一个月的数据量放在单分片里毫无压力，而老月份的订单又几乎不会被访问，实际上每个月的表都会变成“写作热点表”，并且热点永远集中在当前月表，没法把负载分散到多个分片上。这其实不是水平拆分，只是把大表切成小表，但热点问题没解决。最后我们还是老老实实回到user_id取模的方案上，配合时间范围做二级过滤。
4.4 数据路由方案：取模、哈希、范围，如何抉择
水平拆分的数据路由算法常见的有范围分片、哈希取模分片和一致性哈希分片。范围分片是比如按时间区间把订单拆到不同表，简单直观且方便扩展，但热点问题严重，某一段数据疯狂写入时会让单分片持续高负载。哈希取模是拿分片键做哈希后对分片数量取模，数据分布均匀，但扩容麻烦，因为从8个分片扩到16个分片时，大量数据的映射关系都要变，需要做数据迁移。
一致性哈希是为了解决分布式缓存扩容问题而设计出来的，它把哈希值空间组织成一个环，每个分片负责环上的一段区间，数据按哈希值映射到环上后，再顺时针找最近的节点。加节点时，只需要迁移该节点前后一小段数据，不像取模那样大范围重排。但它也有代价，就是数据分布可能不那么均匀，通常要引入虚拟节点优化。我们在实际项目里是用用户ID取模的方式，短期内分片数量已经预留得足够多，未来几年内不需要扩容；如果真到了要扩的那一天，可以用双写迁移方案过渡。
4.5 分库分表之后，那些绕不开的“新问题”
数据拆完之后，新的问题比想象中多。首当其冲的是跨分片查询。比如运营人员想查“最近一周下单金额排名前100的用户”，这个查询的WHERE条件里没有user_id，就必须对所有分片都发一遍同样的查询，再在内存里做汇总排序。复杂度从单点查询升级成了聚合计算，对中间件和业务代码的要求都提高了。我们当时的做法是，面向运营的这种分析类需求不直接查在线订单库，把数据通过binlog同步到分析型数据库或数仓去做，让OLTP和OLAP彻底分离。
第二个绕不开的是分布式事务。分库分表后，一个用户下单可能涉及订单分片、账户分片、库存分片，原本本地事务能搞定的操作现在跨了多个库。我们项目走的是最终一致性方案，核心步骤用本地消息表加异步补偿来保证不会出现大范围数据错乱，而不是用强一致的分布式事务，因为强一致方案对性能的影响非常明显。
第三个是全局主键。MySQL单库的自增主键在分片后不能直接用，否则多个分片会产生相同ID。我们的方案是用雪花算法生成全局唯一ID，它由一个64位的long组成，包含时间戳、机器ID和序列号，既能保证趋势递增，又能满足分布式场景下的唯一性要求。需要注意的是，雪花ID是带符号的64位整型，如果你的前端语言处理大整数有精度问题，就要考虑把ID转成字符串返回，这是很常见的坑。
5. 优化过程中的常见问题与排查技巧实录
5.1 索引建了却不走：优化器的小心思
这次项目里最常见的问题就是“明明有索引，MySQL就是不走”。有个典型案例是订单状态字段status，枚举值就0到5六种，分布也比较均匀，我给它建了索引。然而实际查询WHERE status = 2不仅没走索引，还引发全表扫描。
原因其实不复杂：MySQL优化器是基于代价估算来决定是否使用索引的。当它预估你要读取的行数占全表比例很高时，会认为走索引需要大量回表，代价比全表扫描还大，所以干脆不用。这种字段区分度太低，建索引的意义本来就不大。后来我把索引策略改成联合索引，把status和高区分度的列组合在一起，只查status的场景，用覆盖索引去顶住。
遇到这类问题，优先用FORCE INDEX强制走索引验证一下效果，看看到底是索引没用还是优化器误判。如果是误判，就去更新表的统计信息，ANALYZE TABLE table_name，MySQL的优化器决策依赖统计信息，信息不准确时经常做出错误选择。
5.2 深挖慢SQL的辅助工具：别只靠肉眼
靠EXPLAIN一条条看慢SQL，效率确实有点低。后来我引入了Percona Toolkit里的pt-query-digest工具，它能解析慢查询日志并按查询模式聚合，直接告诉你哪一类SQL最耗时、执行次数最多、扫描行数最大。用这个工具，我可以快速排出优先级，先处理“总耗时 = 平均耗时x执行次数”排名靠前的SQL，而不是一条条手动翻日志，效率提升非常明显。
如果连慢查询日志都不好开，还可以直接查performance_schema和sys库里的statements相关表。比如sys.statement_analysis可以按总延迟排序查看系统里所有SQL的统计；sys.schema_unused_indexes可以找出哪些索引建了但从来没被使用过，这类冗余索引该删就删，既节省空间又减少写入时维护索引的开销。
5.3 索引数量失控：写放大和磁盘空间的隐性成本
索引能加速查询，但绝对不是越多越好。每张表增加一个索引，意味着每次INSERT和UPDATE都要额外维护一棵B+树。订单表原有12个索引，我接手时发现很多索引几乎没人用，而写入性能却因为索引过多变差，磁盘占用也居高不下。后来我用sys.schema_unused_indexes识别出至少4个超过一个月没被使用的索引，逐个下线之后，写入性能提高了约15%，表空间也明显下降。
这个经验是：建索引之前先问自己三个问题。这条SQL是高频SQL吗？这个索引能给这条SQL带来数量级上的提升吗？这个索引是不是能被已有的联合索引覆盖？三个问题都答不上来，就不要建。
5.4 分库分表实践中的迁移与双写：平滑上线的关键
分库分表上线最难的是数据迁移那一关，不可能直接停机把几千万行数据倒过去。我们采用的方案是“双写加异步迁移”。在代码层先把新的订单写入逻辑同时写到旧表和新分片表，旧表继续承担读流量。然后跑一个离线的数据迁移任务，把历史订单按照分片规则计算后导入到分片表中。数据迁移完成后再做一轮对账，确认新旧两边的数据一致。最后把读流量逐步切到新库，观察一段时间没有异常后，再停掉旧表的写入。
整个过程中最耗时的是“对账”环节，因为数据量大，直接逐行比对效率太低。我的做法是对每张分片表按时间范围做总数和金额汇总，同旧表的相同时间范围汇总做比对，如果对不上再缩小范围逐层定位，几轮下来能把不一致的数据限定在很小的范围内，处理效率高很多。
5.5 常用排查SQL与优化脚本备份
最后我把自己日常排查用得最多的几条SQL和命令整理出来，当作速查参考。
sql复制-- 查看表结构和索引
SHOW CREATE TABLE orders;
-- 查看慢查询是否开启
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';
-- 查看当前正在执行的SQL
SELECT * FROM information_schema.processlist
WHERE command != 'Sleep'
ORDER BY time DESC;
-- 查看未使用过的索引（需要开启performance_schema）
SELECT * FROM sys.schema_unused_indexes;
-- 查看语句平均耗时TOP10
SELECT digest_text, count_star, avg_latency, sum_rows_examined
FROM sys.statement_analysis
ORDER BY sum_rows_examined DESC
LIMIT 10;
-- 查看表大小
SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'your_db'
ORDER BY size_mb DESC;
用EXPLAIN分析SQL时，我建议把type、key、rows、Extra四列截图留存，优化前和优化后各做一次对比，方便复盘也方便跟同事沟通。整个过程里我最大的体会是：MySQL优化的路径有千万条，但最终都要回到数据访问的本质——减少扫描行数、减少回表次数、减少不必要的排序和临时表、避免不必要的锁竞争。你可以不会那些花哨的技巧，但一定得能读懂EXPLAIN，至少得知道自己写的SQL到底在数据库里跑了多少行。这条基本功打扎实了，再去谈分库分表和各路中间件，才真正心里有底。