MySQL性能优化实战：从索引、SQL调优到分库分表全解析

1. 写在前面：为什么你的MySQL越用越慢

做后端开发这几年，我几乎每个项目都会遇到“数据库变慢”的问题。明明业务量没涨多少，SQL也没写错，可接口响应时间就是一路飙升，从50ms涨到500ms再涨到5秒。很多人第一反应是加机器、上缓存，但真正常规操作查下来，往往发现是索引没用上、SQL写法有硬伤，或者数据量已经到了单表单库扛不住的地步。

这篇文章我打算把MySQL优化这件事系统捋一遍，分成索引优化、SQL调优、分库分表三大板块。不绕弯子，不讲那种“优化很重要”的废话，直接给思路、给原理、给可以直接抄的实操方案。无论你是刚入行的后端开发，还是被慢SQL折磨的运维老手，这篇文章里的内容都应该能帮上忙。

先说一个很反直觉的事：很多慢查询根本不是数据库不行，而是SQL写法骗过了优化器，导致索引压根没生效。 我见过太多项目，表里明明建了联合索引，结果查询计划一出来还是全表扫描，就是因为查询条件的顺序、函数包裹、隐式类型转换这些细节没处理好。这些问题不搞清楚，加再多索引都是白搭。

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四张表。水平拆分的本质是降低单表数据量，让每个分片的数据量控制在合理范围内。

实操路径上，我建议按这个顺序走：

1. 先做垂直拆分，把冷热字段分离，把核心业务表单独拆库。
2. 加缓存（Redis）扛住热点读。
3. 读写分离，主库写、从库读，减轻单库读压力。
4. 以上都做了还不够，再上水平分表。

一步到位搞水平分库分表的，十个有九个后悔。后面会详细讲为什么。

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 平滑迁移方案：从单库到分库的过渡实战

最怕的就是线上直接停机迁移，那是下下策。我推荐双写策略：

1. 全量迁移：历史数据调度批量任务写入新分片库，期间记录增量日志。
2. 双写阶段：应用层同时写旧库和新分片，新分片内的写入失败不影响主流程，日志记录异常并处理。
3. 数据校验：对账程序逐条比对新旧库数据，发现不一致则补偿刷新。
4. 流量切换：逐步把读流量切到新分片，观察集群状态，最后切写流量。
5. 旧库下线：确认业务稳定后，永久下线旧库。

这个流程看起来不难，但每一步都有很多细节。比如双写阶段的消息丢失、主键冲突、数据回放顺序问题，都要逐一处理。最关键的教训是：迁移过程中一定要把补偿机制做完善，否则业务一旦恢复，脏数据流进生产环境，比停机还麻烦。

另外，很多团队会在这个过程中引入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 高频踩坑场景汇总

我把这几年遇到的典型问题整理成一张速查表，方便参考：

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追根溯源，绝大多数问题都能在你动手重构数据库架构之前解决掉。