徐小疼1. 写在前面：为什么你的MySQL越用越慢
做后端开发这几年，我几乎每个项目都会遇到“数据库变慢”的问题。明明业务量没涨多少，SQL也没写错，可接口响应时间就是一路飙升，从50ms涨到500ms再涨到5秒。很多人第一反应是加机器、上缓存，但真正常规操作查下来，往往发现是索引没用上、SQL写法有硬伤，或者数据量已经到了单表单库扛不住的地步。
这篇文章我打算把MySQL优化这件事系统捋一遍，分成索引优化、SQL调优、分库分表三大板块。不绕弯子，不讲那种“优化很重要”的废话，直接给思路、给原理、给可以直接抄的实操方案。无论你是刚入行的后端开发，还是被慢SQL折磨的运维老手，这篇文章里的内容都应该能帮上忙。
先说一个很反直觉的事：很多慢查询根本不是数据库不行，而是SQL写法骗过了优化器，导致索引压根没生效。 我见过太多项目，表里明明建了联合索引，结果查询计划一出来还是全表扫描，就是因为查询条件的顺序、函数包裹、隐式类型转换这些细节没处理好。这些问题不搞清楚，加再多索引都是白搭。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 索引优化：先搞清楚索引为什么能快
2.1 B+树：MySQL默认索引结构的底层逻辑
聊索引之前，得先弄明白MySQL为什么默认用B+树，而不是哈希索引、二叉树或者B树。这几个结构我全部对比过，只有B+树最适合磁盘IO场景。
先说哈希索引。哈希结构等值查询确实是O(1)级别，快得离谱，但它解决不了范围查询。WHERE age > 20 AND age < 30这种需求在业务里太常见了，哈希索引直接束手无策。InnoDB的自适应哈希索引只是锦上添花，默认的聚簇索引还是B+树，原因就在这里。
再看二叉树。如果数据有序插入，二叉树会退化成一条链表，查询效率直接从O(log n)掉到O(n)。平衡二叉树虽然解决了退化问题，但每个节点只存一个key，数据量一大，树的高度就很高。InnoDB一次IO默认读16KB的页，一个节点一个页的话，3层B+树能存上千万条记录，而平衡二叉树可能中途就崩了。
B树和B+树的区别也不难理解。B树的每个节点都存数据，B+树只有叶子节点存数据，非叶子节点只存索引key。这意味着同样高度的树，B+树能存更多索引项，IO次数更少。而且B+树的叶子节点通过双向链表串起来，范围查询和排序遍历一条链表就完成了。这就是MySQL选择B+树的根本原因：减少磁盘IO次数 + 高效率范围查询。
2.2 聚簇索引与二级索引：回表是怎么发生的
InnoDB的数据和索引存储在同一个文件里，数据行按照主键顺序存储在B+树的叶子节点上，这就是聚簇索引。一张表只有一个聚簇索引，主键就是它。
普通索引（二级索引）的叶子节点不存数据行，只存索引列的值和主键值。当你用普通索引查询时，过程分两步：先在二级索引的B+树里找到主键值，再拿着主键去聚簇索引里查完整数据行。第二次查询就叫回表。
回表是性能损耗的重要来源。举个真实案例，我之前优化过一个订单表，SQL长这样：
sql复制SELECT order_id, user_id, amount
FROM orders
WHERE status = 1
ORDER BY create_time DESC
LIMIT 20;
表里有个idx_status单列索引。查询走了索引，但每行都要回表取order_id和amount，再根据create_time排序。随着订单表数据量增长，这SQL越来越慢。后来我改成联合索引(status, create_time, order_id, user_id, amount)，把所有需要的列都塞进索引里，查询直接走索引覆盖，连回表都省了，也免去了额外的排序操作。
2.3 联合索引最左前缀的原则与理解
联合索引的核心规则就八个字：最左匹配，顺序敏感。(a, b, c)联合索引，其实等效于三个索引：(a)、(a, b)、(a, b, c)。查询条件里如果不包含最左边的列a，索引就废了。
很多新手会问，为什么有这个规则？因为联合索引在B+树里的排序逻辑是：先按a排序，a相等时按b排序，b相等时按c排序。这是一个字典序排列，a是最高权重的前缀，跳过了前缀直接用后面的列定位，就像查字典直接查第二个字一样，没法定位。
但这个规则有三个实战延伸，值得记一下：
WHERE a = 1 AND c = 3：能走索引，但c条件没法用索引过滤，只能作为回表后的过滤条件。因为跳过了b。WHERE a = 1 AND b > 2 AND c = 3：b的范围条件导致c无法走索引。范围查询右边的列自动失效。WHERE b = 2 AND c = 3：完全无法走联合索引，因为没带a。
所以建联合索引的时候，设计原则是：区分度高的列放前面，经常等值查询的列优先，范围查询的列靠后。sex这种区分度极低的列，建索引基本没意义，优化器扫一遍可能比走索引更快。
2.4 索引设计实战：覆盖索引、区分度与冗余判断
覆盖索引是性价比最高的优化手段，意思就是索引里已经包含了查询需要的所有列，不需要回表。判断方法很简单：看EXPLAIN的Extra列，如果出现Using index，就是覆盖索引。
区分度则决定了索引的筛选效率。区分度 = COUNT(DISTINCT column) / COUNT(*)，越接近1越好。比如性别列区分度只有0.5左右（排除极端情况），而手机号基本是1。如果联合索引第一列放性别，那后面的列等于被架空了，因为优化器先按性别分，一下子就分出几百万条记录。
这里有个实操建议：用SHOW INDEX FROM table查看索引基数（Cardinality），如果基数远小于表行数，说明这个索引的区分度很差，建议去掉或调整位置。
冗余索引是很多人忽略的性能杀手。表里有(a,b)和(a)两个索引，后者完全冗余，因为前者已经覆盖了。每次写操作都要维护两份索引，在线业务DDL还得小心锁表，结果收益为零。我见过一张表上千行数据建了六七个索引的，其中一半都是冗余，纯属给自己挖坑。
3. SQL优化实操：让优化器按你的思路执行
3.1 EXPLAIN是慢SQL排查的第一工具
任何SQL优化，第一步永远是EXPLAIN。不加索引、列类型不匹配、查询条件写错，全都能在EXPLAIN的结果里看出来。别跟我说你看过哪篇文章说EXPLAIN不准，早期版本确实有统计信息不准的问题，但定位问题它依然是唯一标准。
实操时重点关注这几列：
- type：从好到坏依次是
system>const>eq_ref>ref>range>index>ALL。见到ALL全表扫描就要警惕，除非是查询全表的小表，否则必须改。 - key：实际使用的索引名。
NULL说明没走索引。 - rows：预估扫描的行数，这个数能帮你直观判断SQL效率。
- Extra：
Using filesort（文件排序，性能差）、Using temporary（临时表，更差）、Using index（覆盖索引，优秀）、Using where（正常过滤）。
多说一句type为index的情况，很多人以为看到index就是走了索引，其实index是全索引扫描，比全表扫描好不到哪去。它遍历的是整棵B+树，而不是通过索引定位到具体行。出现index类型，通常是查询列刚好全在索引里，但筛选条件用不上索引定位。
3.2 索引失效的六种典型场景与解法
遇到的索引失效场景太多，挑最有代表性的六种列出来：
1. 隐式类型转换。 phone是varchar类型，但查询写WHERE phone = 13800001111。MySQL会把varchar转成数字比较，索引直接失效。解决办法是查询参数老老实实加引号，或者建表时就选对数据类型。
2. 函数包裹索引列。 WHERE DATE(create_time) = '2024-01-01'，索引会失效。正确写法是范围查询：WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'。MySQL 8.0支持函数索引，但能用范围查询解决的问题，没必要额外增加索引复杂度。
3. 前置模糊查询。 LIKE '%keyword'无法走索引，LIKE 'keyword%'可以。业务层尽量避免前置通配符，搜索引擎该上就上，MySQL不是干这活的料。
4. OR连接的非索引列。 WHERE name = '张三' OR age = 20，只要有其中一个条件没索引，整个查询退化为全表扫描。改成UNION ALL两边分别走索引，是更优解。
5. 联合索引不满足最左前缀。 前面已经详细说过，这里不重复。
6. IS NOT NULL在某些场景失效。 这取决于优化器对字段统计信息的判断，解决方案是给字段设置默认值，查询避免使用IS NOT NULL。
3.3 深分页优化：LIMIT百万偏移量的杀手
LIMIT 1000000, 20这种写法在数据量大了之后会非常慢。原因在于MySQL要扫描前1000020行，然后扔掉前1000000行。扫描行数越多，耗时越长。
延迟关联是业界最常用的解法：
sql复制-- 原SQL
SELECT id, name, content
FROM articles
ORDER BY id DESC
LIMIT 1000000, 20;
-- 优化后
SELECT a.id, a.name, a.content
FROM articles a
INNER JOIN (
SELECT id
FROM articles
ORDER BY id DESC
LIMIT 1000000, 20
) t ON a.id = t.id;
原理很简单：子查询覆盖索引直接定位到20个主键ID，再聚簇索引回表取完整数据。扫描的行数从100多万降到了20，速度提升几个数量级。还有一版是记录上一页最后一条数据的ID，然后WHERE id < ? ORDER BY id DESC LIMIT 20，适合翻页这种顺序场景，但随机跳页用不了。
3.4 SQL写法的日常规范：避免隐式转换与函数包裹
除了上面说的索引失效场景，日常SQL写法还有几个我一直在坚持的规范：
- SELECT 只查需要的字段，避免
SELECT *。 一方面减少回表概率，另一方面减少网络传输量。你猜为什么很多公司规范里明确禁止SELECT *？就是因为它会破坏覆盖索引。 - 避免在WHERE子句对列做运算：
WHERE amount * 0.8 > 100会让索引失效，改写为amount > 125。 - JOIN时小表驱动大表，关联字段必须有索引。 比如订单表关联用户表，
user_id在用户表上必须是主键或有索引。 - 优化
ORDER BY排序：让排序字段尽量走索引顺序，避免Using filesort。
还有一点，很多人不知道：MySQL的优化器并不是每次都能做出最优选择。 它依赖统计信息，如果表的统计信息过时了，可能选错索引。这时可以用ANALYZE TABLE更新统计信息，或者用FORCE INDEX强制指定索引。不过FORCE INDEX是最后的杀手锏，平时别乱用，因为一旦数据分布变了，强制索引可能反而更慢。
3.5 慢SQL日志：定位问题的第一步
没有慢查询日志就谈SQL优化，等于盲人摸象。生产环境一定要开启慢查询日志，定位到具体SQL再动手。
ini复制[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = ON
long_query_time设为1秒足够捕捉大部分问题SQL。log_queries_not_using_indexes可以帮你抓出那些没走索引的查询，很多隐藏问题都是这么发现的。排查时，我习惯用mysqldumpslow -s c -t 10看执行次数最多的前10条慢SQL，优先优化那些高频慢查询，收益最大。
3.6 索引下推：一个细节优化也能带来大收益
索引下推（ICP）是MySQL 5.6引入的优化，很多人没注意过。它的作用是：在索引遍历过程中，提前使用索引中包含的字段进行过滤，减少回表次数。
举个例子，联合索引(zipcode, lastname)，查询WHERE zipcode = '100000' AND lastname LIKE '%张%'。没有ICP的话，MySQL先通过zipcode定位所有记录，再逐条回表，在数据行上判断lastname。有ICP的话，lastname的过滤直接在索引层完成，回表次数显著减少。
EXPLAIN的Extra列出现Using index condition，就代表ICP生效了。它不是让你改写SQL，而是MySQL自动优化的机制，但前提是索引设计得合理。联合索引里包含的列越多，ICP发挥作用的场景就越多。
4. 分库分表：单库扛不住的最后一招
4.1 什么情况下真正需要分库分表
分库分表是最后的方案，不是最优方案。加了分片之后，跨节点查询、分布式事务、全局ID生成这些麻烦事接踵而来。所以我先泼一盆冷水：单表数据量在千万级以内，优先考虑分区表、归档、缓存优化，别上来就分库分表。
真正需要分库分表的信号是啥？
- 单表数据量超过2000万，写入性能明显下降，索引维护开销变大，B+树层级加深。
- 单库连接数成为瓶颈，比如高峰期几百个应用实例同时连一个库，连接池直接被打满。
- 磁盘IO和日志IO有瓶颈。一个大库的redo log、binlog压力集中在一个实例上，IO吞吐跟不上。
- 需要隔离核心业务和边缘业务。比如订单库和日志库分开部署，避免互相影响。
数据量达到这个级别，垂直拆分（按业务域拆库）优先于水平拆分（按数据分片）。先按业务把用户、订单、商品拆成独立库，通常能扛很久。水平拆分是最后的选择，因为复杂度上升一个量级。
4.2 垂直拆分 vs 水平拆分：先拆库还是先拆表
垂直拆分是纵向切，把一张宽表拆成多张表，每张表存不同字段。比如用户表拆成user_base（基础信息）和user_ext（扩展信息），或者按业务域划分成用户库、订单库、商品库。垂直拆分的本质是减少单表字段数和IO扫描广度。
水平拆分是横向切，把一张表的行数据按照某个分片键分散到多张表（或多个库）。比如订单表按用户ID哈希分成order_0、order_1、order_2、order_3四张表。水平拆分的本质是降低单表数据量，让每个分片的数据量控制在合理范围内。
实操路径上，我建议按这个顺序走：
- 先做垂直拆分，把冷热字段分离，把核心业务表单独拆库。
- 加缓存（Redis）扛住热点读。
- 读写分离，主库写、从库读，减轻单库读压力。
- 以上都做了还不够，再上水平分表。
一步到位搞水平分库分表的，十个有九个后悔。后面会详细讲为什么。
4.3 分片键选择与一致性哈希
分片键是水平拆分的核心。选错分片键，整个架构就废了。分片键必须满足两点：分布均匀、查询频率高。
订单表最常见的选择是user_id或order_id。按user_id分片的好处是：查某个用户的订单列表时，只需要命中一个分片，一次查询搞定。按order_id分片的好处是：订单详情查询也能精确定位分片。但具体选哪个，要看业务里哪种查询更频繁。
我遇到过一个典型的反例：用订单创建时间做分片键，结果每月一个分片，月底查询上个月订单只需要扫一个月的数据。听起来挺合理，但实际上发现热点全集中在旺季那几个月，分片数据量严重不均，最终不得不重做分片。分片键必须保证数据分布均匀，防止热点。
分片算法上，最常见的两种：
- 范围分片：按ID范围切分，比如1-1000万放
order_0，1000万-2000万放order_1。优点是可以方便扩展新分片，缺点是容易造成热点，新数据全集中在最后一个分片。 - 哈希分片：
hash(shard_key) % shard_count。优点是分布均匀，缺点是扩展分片时，已有数据需要大规模迁移。
为了兼顾两者，很多团队用一致性哈希。但一致性哈希在数据量变化不大时，复杂度其实大于收益，业务规模没大到一定程度前，取模分片+提前规划分片数就够用了。比如预估数据量会涨到2亿，单表2000万，那就直接建10个分片，预留将来扩到20个的空间。
4.4 分片后的三大难题：ID生成、跨分片查询、分布式事务
分片完了，噩梦才刚刚开始。三大难题我要单独列出来，每一条都有具体的坑。
难题一：全局唯一ID。 自增ID在分片后无法用了，因为每个分片各自自增会产生重复ID。常用的方案有以下几种：
- 雪花算法：64位整数，时间戳+机器ID+序列号。毫秒级时间戳保证了趋势递增，机器ID保证了全局唯一。这是当前最主流的选择。
- 号段模式：由发号器批量生成ID段，比如一次拿1000个ID到本地缓存，用完再取。性能和可用性都不错，但依赖发号器这个独立组件。
- UUID：虽然简单，但不是递增的，作为InnoDB主键容易导致页分裂，性能很差，不建议用。
我自己的经验是：如果是纯自研，雪花算法最省心；如果公司有现成的发号器服务，直接用号段模式更稳。 别自己实现雪花算法，很多人在时间回拨问题上踩坑，生成重复ID导致数据错乱，追查起来欲仙欲死。
难题二：跨分片查询。 分片之后，ORDER BY create_time LIMIT 10变成了一场噩梦。因为数据分散在多个分片，你得先到每个分片捞10条，然后总排序再取前10。如果业务要跨N个分片分页，计算量呈指数级上升，网络开销更是灾难级别的。
解决思路是在分片前就想好查询场景。如果列表查询是核心场景，有两种落地方式：
- 部分聚合数据冗余：单独建一张汇总表，专门存列表页需要的数据，通过异步任务同步到ES或单独的查询库。
- 分片键兼容列表查询：比如列表页默认展示当前用户的订单，那
user_id作为分片键就天然规避了跨分片问题。
难题三：分布式事务。 分片后，一个业务操作可能涉及多个分片的数据修改。传统ACID事务只能保证单库内的一致性，跨分片就需要分布式事务方案。常见的方案有：
- 2PC（两阶段提交）：强一致性，但性能较差，协调者容易成为瓶颈。
- TCC（Try-Confirm-Cancel）：补偿型事务，业务侵入性强，但性能好，适合金融交易等核心场景。
- 本地消息表 + MQ：最终一致性方案，把跨分片的操作变成异步消息，适用大部分业务场景，实现简单。
我个人建议：能避免跨分片事务就尽量避免，通过合理的库表设计把相关数据放在同一分片。 如果实在无法避免，优先用MQ最终一致性方案，别一上来就上2PC，性能损失太大了。
4.5 分库分表中间件选型：ShardingSphere与MyCat对比
主流开源方案主要分两类：客户端模式和代理模式。
- ShardingSphere-JDBC：客户端模式，嵌入在应用里，直接和数据库交互。优点：性能好、无额外部署节点，运维成本低。缺点：框架侵入性强，不同语言需要不同接入方式。
- ShardingSphere-Proxy：代理模式，独立部署一个Proxy服务，应用连接Proxy就好，对应用透明。优点：对业务代码侵入小，多语言通用。缺点：多一跳网络，延迟略有增加。
- MyCat：也是代理模式，但这几年社区活跃度下降，功能演进慢，已经逐渐被ShardingSphere取代。新项目不建议用。
选型上，我的建议是：如果团队Java技术栈为主，选ShardingSphere-JDBC；如果多语言团队而且对性能损耗不太敏感，选ShardingSphere-Proxy；如果团队规模小、没有专门的中间件运维能力，尽量别碰代理模式，多一个节点多一份运维负担。
4.6 平滑迁移方案：从单库到分库的过渡实战
最怕的就是线上直接停机迁移，那是下下策。我推荐双写策略：
- 全量迁移：历史数据调度批量任务写入新分片库，期间记录增量日志。
- 双写阶段：应用层同时写旧库和新分片，新分片内的写入失败不影响主流程，日志记录异常并处理。
- 数据校验：对账程序逐条比对新旧库数据，发现不一致则补偿刷新。
- 流量切换：逐步把读流量切到新分片，观察集群状态，最后切写流量。
- 旧库下线：确认业务稳定后，永久下线旧库。
这个流程看起来不难，但每一步都有很多细节。比如双写阶段的消息丢失、主键冲突、数据回放顺序问题，都要逐一处理。最关键的教训是：迁移过程中一定要把补偿机制做完善，否则业务一旦恢复，脏数据流进生产环境，比停机还麻烦。
另外，很多团队会在这个过程中引入MQ——应用写完业务后把数据变更事件发到MQ，消费者同时写旧库和新分片，保证数据最终一致。这套机制对业务代码的侵入更小，开发运维起来也更灵活。
4.7 分库分表后的老问题：聚合查询与排序分页
分片后最直观的差异，就是以前一句话的聚合SQL变成了一场数据合并操作。COUNT(*)、SUM(amount)这类操作，无法在数据库层面直接聚合，得把每个分片的结果汇总到应用层再合并。
我的做法是建一张统计结果表，定时通过异步任务从各分片聚合数据，更新统计结果。业务查询只查统计结果表，完全不碰分片数据。虽然统计数据有几分钟的延迟，但换来的是毫秒级响应和数据库零压力。对大多数to B和to C业务来说，这个延迟完全能接受。
分页排序则和聚合类似。如果业务不要求实时精确，可以用汇总表或缓存解决。如果要求实时精确，可以参考深分页优化的思路：先通过分片键定位到具体分片，再在该分片上执行原来的分页SQL。如果查询条件里没有分片键，那就要在每个分片都执行分页查询，然后在应用层做归并排序。分片数据量大的时候，这个开销是巨大的。所以在设计分片键的时候就要考虑业务查询场景，这是无论如何不能省的前置工作。
5. 日常运维与调优经验：让数据库持续高效
5.1 连接数与线程池：别让数据库被连接数打垮
一个常见的生产事故就是“数据库连接数被打满”。明明数据库CPU和内存都很健康，但应用就是连不上数据库。原因往往是应用实例太多，每个实例的数据库连接池配置太大，加起来远超数据库上限。
max_connections默认是151，很多团队直接调到1000，但其实数据库处理能力和CPU核数有关，盲目调大只会让问题更严重。我习惯的公式是：连接数 = (CPU核数 * 2) + 固态硬盘数量。比如8核机器，建议连接数控制在20左右。如果应用并发高，需要更多连接，优先考虑增加数据库实例，而不是在一个实例上狂调max_connections。
连接池这边，HikariCP的maximum-pool-size默认是10，很多场景下10就够用了。如果压测发现连接池打满，先看是慢SQL导致连接占用时间太长，还是并发确实太高，对症下药，别盲目调大。
5.2 Buffer Pool：InnoDB内存使用率的核心
InnoDB的Buffer Pool是缓存数据和索引的内存区域，它的命中率直接影响查询性能。如果Buffer Pool设得太小，大量查询要走磁盘IO，性能直接腰斩。
MySQL 5.7+可以动态修改：SET GLOBAL innodb_buffer_pool_size = 4G;。建议设置为物理内存的60%-70%，但前提是机器只跑MySQL，没有和其他应用混部。
检查命中率：
sql复制SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';
Innodb_buffer_pool_read_requests是总请求次数，Innodb_buffer_pool_reads是磁盘读次数。命中率 = 1 - (reads / read_requests)，稳定在99%以上才算是健康的。如果命中率低于95%，优先加大Buffer Pool，而不是盲目优化SQL。
5.3 日常索引检查清单
运维阶段的索引管理，我建议定期跑几张检查SQL：
sql复制-- 查看所有索引
SHOW INDEX FROM orders;
-- 查看表大小、行数，判断是否需要归档
SELECT table_name, table_rows, data_length
FROM information_schema.tables
WHERE table_schema = 'your_db'
ORDER BY data_length DESC;
重点排查这几类问题：
- 冗余索引：比如同时存在
idx_a和idx_a_b，前者可删。 - 区分度低的索引：比如性别、状态这类列建的索引，实际很少被用到。
- 长时间未更新统计信息的表：跑一下
ANALYZE TABLE，让优化器拿到准确的基数信息。 - 慢SQL日志里高频出现的模式：比如同一张表反复出现
ALL全表扫描，说明索引设计没覆盖到核心查询。
5.4 读写分离与缓存：分库分表之前的过渡方案
很多团队一遇到性能问题就想分库分表，实际上读写分离和缓存能解决大部分问题。
读写分离的核心思路：主库负责写，从库负责读，通过主从复制同步数据。读多写少的场景特别适合这种方案。比如一个资讯类应用，读流量可能是写流量的几十倍，一主两从的架构就能扛住大量读请求，比分库分表简单得多。
引入读写分离后，要注意一点：主从复制延迟。 如果写操作完成立刻去读从库，可能读不到刚写入的数据。我的方案是：关键查询强制走主库，非关键查询走从库，或者“写后读”场景通过Redis缓存承接，从库只服务列表和统计类请求。根据业务容忍延迟的程度，这个策略可以灵活调整。
缓存则是更高一层的优化。MySQL命一次查询可能要1毫秒，而Redis命中只用200微秒，而且Redis能扛住每秒几万次的查询量。对于热点数据（比如商品详情、用户基本信息），先查Redis，没命中再查数据库，并回填Redis。我之前优化过一个商品详情接口，数据库QPS从5000降到200，全靠缓存扛住了热点流量。不过缓存一定要设置过期时间和防击穿策略，不然缓存雪崩会瞬间把数据库打挂。
6. 常见问题与避坑速查
6.1 高频踩坑场景汇总
我把这几年遇到的典型问题整理成一张速查表，方便参考：
| 现象 | 根本原因 | 解决思路 |
|---|---|---|
| SQL走了索引还是很慢 | 回表次数太多，或扫描行数过大 | 覆盖索引、延迟关联、索引下推优化 |
| 明明建了索引，EXPLAIN还是ALL | 隐式转换、函数包裹、最左前缀不满足 | 修正SQL写法，或调整索引顺序 |
| 分页越来越慢 | LIMIT偏移量过大 | 延迟关联或ID游标方案 |
| 连接数激增，数据库大面积阻塞 | 线上慢SQL拖长事务时间 | 定位慢SQL、优化事务、缩短锁持有时间 |
| 数据库CPU飙到100% | 全表扫描或超大排序 | 慢日志定位SQL，加索引或改SQL |
| 分片表数据分布不均 | 分片键选择不当 | 重新选分片键，或者按业务重新分片 |
| 主从切换后数据不一致 | 大事务、DDL导致复制延迟 | 拆大事务、用并行复制、配置半同步复制 |
| 缓存大量失效，数据库被击穿 | 缓存过期时间相同引发雪崩 | 过期时间加随机量、热点数据提前预热 |
6.2 索引设计的几个原则性建议
- 索引数量控制在5个以内。索引不是越多越好，每个索引都会拖慢写入性能。
- 优先用联合索引替代多个单列索引。写法灵活且节省空间。
- 小表不用建索引。全表扫描比走索引快得多，优化器通常也会自动选择全表扫描。
- 区分度低的列不建单列索引。状态、类型这类字段如果有多个值，可以考虑联合索引里作为筛选条件，但单独建索引大多数场景都不划算。
- 主键尽量用自增ID或雪花ID，避免用随机字符串，因为聚簇索引依赖主键顺序，随机主键会造成页分裂，性能大打折扣。
6.3 SQL注入问题：优化之外的必须防线
聊SQL优化的时候必须提一句安全问题。SQL注入的本质是用户输入被拼接进了SQL语句，当成代码执行了。比如登录功能直接拼字符串，用户在用户名里输入' OR '1'='1，就可能绕过验证。
预防手段很简单但非常重要：
- 所有SQL使用预处理语句（PreparedStatement），参数占位符绑定，不让用户输入进入SQL语法层面。
- ORM框架（MyBatis、JPA）用参数绑定方式，别用
${}拼接。 - 数据库账号遵循最小权限原则，应用账号不给DDL权限、不给删除权限。
- 不要把敏感数据明文入库，即使数据库泄露也不至于直接爆出客户隐私。
很多次我调优完SQL之后发现，线上居然有注入风险。性能再快，安全防线破了也是零。所以我把这条放进速查表里，提醒自己，也提醒看完这篇文章的各位。
7. 一些个人的实践经验
最后聊几句我在实际项目里的体会。
数据库优化没有银弹。索引、SQL、分库分表每一层都是可以深挖的黑洞，但不管技术方案多花哨，最终都要落到业务场景上。我见过团队为了分库分表而分库分表，结果业务数据量不到两千万，引入了一堆复杂度，光排查跨分片问题就耗掉了大量开发时间。也见过团队积累了几千万订单数据，却还在靠全表扫描扛业务，连一个最基础的覆盖索引都不建，接口超时成了常态。合理的做法是：先量化监控，再针对性优化，每个动作都要有数据支撑。
另外想说，EXPLAIN + 慢查询日志 + 压测这组工具一定要组合使用。光看EXPLAIN只能判断单条SQL的访问路径，没有压测数据，你不知道这个SQL在真实并发下会变成什么样。我自己每次SQL上线前，习惯在测试环境用sysbench或者JMeter模拟真实流量压一遍，观察数据库连接池、CPU、IO这些指标，确认没有异常再上线。
如果让我给一条最简单的实战建议，那就是：每次都从EXPLAIN开始看问题，从业务场景出发定方案，永远用数据说话。MySQL优化就是这样，把基础原理吃透，慢SQL追根溯源，绝大多数问题都能在你动手重构数据库架构之前解决掉。