做后端开发这些年，MySQL调优是我见过最容易被神化、也最容易走弯路的领域之一。一说调优，很多人第一反应就是翻出一堆参数，照着网上的“推荐配置”一顿改，结果不但没变快，反而把线上系统搞崩的案例我见过不少。实际上，MySQL调优的核心从来不是背参数，而是建立一套“定位瓶颈”的思维方法。这篇文章我想结合自己的实操经历，把MySQL调优从整体思路、关键参数、SQL索引到案例走查、常见避坑完整梳理一遍。没有基础的朋友可以从头看，有一定经验的可以直接跳到第三部分和第四部分，这些都是实际项目中收益最大、踩坑最多的地方。
1. 调优前先想清楚：MySQL性能优化的整体思路
1.1 先回答三个问题：你的目标、基线和瓶颈是什么
任何调优动作开始之前，我都会先问三个问题：目标是什么？基线在哪里？瓶颈判断的依据是什么？
目标这件事很多人其实没想清楚。你是想让数据库响应时间从200ms降低到50ms？还是想支撑翻倍的用户量？又或者是想解决高峰期CPU打满的问题？不同的目标会导致完全不同的调优方向。响应时间慢可能是SQL问题，CPU打满可能是并发模型问题，而用户量翻倍可能要动架构。先把目标写下来，后面所有工作才不会跑偏。
基线和目标同样重要。没有基线的调优是耍流氓。你改了十个参数，怎么知道哪个起了作用，哪个有副作用？我在实操中习惯在调优前至少记录一周的核心指标：每天的QPS/TPS曲线、平均查询响应时间、慢查询数量、磁盘IO使用率、连接数峰值。这些数据既是你判断问题的依据，也是你改完之后对比效果的标尺。
最后是瓶颈判断。MySQL出现性能问题，表象往往是在一端，根因在另一端。用户看到的是接口转圈，你去看服务器发现是磁盘IO满了，再往下挖发现是一条全表扫描SQL把缓冲池读穿了。所以拿到性能问题，先别急着改，把当时的监控数据拉出来，判断瓶颈到底出在哪一层：是硬件层、系统层、MySQL层还是SQL层。判断错层，后面全白干。
1.2 瓶颈分层：从硬件到SQL，每一层能拿到的收益不一样
我把MySQL性能瓶颈分成四层：硬件资源层、MySQL配置层、SQL与索引层、数据模型与架构层。这个分层基本决定了我处理问题的优先级。
硬件资源层是CPU、内存、磁盘、网络这些基础资源。这一层的问题通常表现为资源使用率打满，比如CPU 100%、磁盘IO等待时间长。硬件层优化成本最高——加内存、换SSD、扩容机器——但带来的收益却不一定最高。你换了一台高配机器，但业务SQL本身是全表扫描，那只是把问题从几分钟延迟到几十分钟而已。
MySQL配置层是参数层面的调整，包括缓冲池大小、连接数、日志刷盘策略等。这一层能解决的是“MySQL没有合理利用资源”的问题。比如缓冲池配得太小，明明有128G内存，只给了2G给InnoDB，那大量热数据只能反复走磁盘，这就是配置层的经典问题。
SQL与索引层才是调优收益最大的地方。同样的数据，一条走了索引的SQL和一条全表扫描的SQL，性能差距是几个数量级。这一层的优化几乎不花钱，靠的是对SQL和执行计划的深入理解，但产出最明显。
数据模型与架构层是最底层的思考，比如表结构设计是否合理、是否需要拆分大表、要不要引入缓存或读写分离。这个层级通常不会单次优化立刻做，但遇到量表数据过亿的场景，前面三层的优化空间都挖完之后，架构调整是绕不开的。
我的习惯是：先花最少的成本确认SQL与索引层有没有问题。因为这一层问题最常见、优化成本最低、效果最立竿见影。确认这一层没问题之后，再去看配置层，最后才考虑硬件和架构。
1.3 调优工具准备：用手上的数据说话
调优不能靠感觉，得靠数据。我常用的“调优三件套”其实很简单：慢查询日志、状态变量、EXPLAIN。慢查询日志用来发现哪些SQL是“毒瘤”，状态变量用来看MySQL整体的运行状态，EXPLAIN用来分析单条SQL的执行计划。
还有一套很管用的命令。SHOW GLOBAL STATUS里面有大量计数器，可以看当前MySQL的各种累计指标，比如Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads两个值一做对比，就能算出缓冲池的命中率，从而判断缓冲池大小是否合理。SHOW PROCESSLIST看当前正在跑的线程，定位突发的高频查询。performance_schema和sys库更是MySQL自带的高级监控体系，可以按SQL语句维度统计资源消耗。
我第一次做调优的时候就是纯靠感觉，一顿乱改，线上出了事故才回头补监控。后来养成了习惯：调优动作之前先干活，把监控和日志全部打开，确保每一条优化决策都有数据支撑。这个习惯帮我把很多线上问题从“玄学”变成了“科学”。
2. 上手就改的几个关键参数：原理与配置经验
2.1 innodb_buffer_pool_size：数据库的“工作台”应该有多大
InnoDB缓冲池是MySQL用来缓存表数据和索引的内存区域。我习惯把它比作厨师的“操作台面”——台面越大，需要用的食材和工具都能摆在手边，不用反复去储物间（磁盘）拿。所有数据读取和修改都先在缓冲池里进行，缓冲池不够用的时候，才被迫把数据从磁盘读进来，或者把脏数据刷出去。这台面的大小直接决定了数据库能不能干得快。
配置经验上，专用MySQL服务器通常把innodb_buffer_pool_size设为物理内存的50%~70%。比如一台64G内存的机器，设置32G到48G是比较常见的区间。如果机器上还跑了应用服务，就相应调低，避免内存互相挤兑导致操作系统使用交换分区。
但配置不是拍脑袋，配完要看命中率验证。查询方法很简单：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests'; SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';第一个值代表从缓冲池读的次数，第二个值代表从磁盘读的次数。命中率计算公式是：read_requests / (read_requests + reads)。一个健康的系统，这个命中率应该在99%以上。如果低于95%，优先考虑扩充缓冲池，同时检查是否存在大量的全表扫描。
还有一个细节容易被忽略：MySQL 5.7及以上版本支持动态调整缓冲池大小，不用重启就能生效，但要注意的是调整过程会逐步搬移数据页，期间会有额外的CPU和IO开销。所以我一般建议在低峰期调整，改完用SHOW ENGINE INNODB STATUS观察缓冲池的resize状态是否结束。
2.2 max_connections：并发连接数的上下限博弈
max_connections是很多人喜欢乱改的参数之一，它代表MySQL允许同时建立的最大客户端连接数。改小了，业务高峰期用户一多就直接报“Too many connections”，页面全挂；改大了，也不见得是好事，因为每个连接都要占用线程和内存，连接数过多反而会让系统资源耗尽，拖垮正常请求。
一个实用的判断方法，是去查两个关键的运行时指标：Threads_connected（当前已建立的连接数）和Threads_running（当前正在执行语句的线程数）。如果Threads_connected接近max_connections上限，但Threads_running很低，说明连接数配置太紧，可以调大。如果Threads_running本身就很高，说明是并发执行的真高，光调大连接数只会让情况更糟，这时候要去看SQL本身的效率和锁等待情况。
我实际项目里最常见的配置区间是200到500。大多数中小业务系统，350左右已经能撑住日常流量。真正需要担心的不是连接数，而是大量空闲连接占着不释放。这个问题要靠wait_timeout和interactive_timeout来约束。我曾经排查过一个线上系统，连接数长期突破上限，排查发现是应用层没有正确的连接池回收策略，加上wait_timeout默认8小时太长，空闲连接堆积成山。把wait_timeout调成300秒之后，连接数压力立刻缓解。
2.3 innodb_flush_log_at_trx_commit：性能与数据安全之间的取舍
这个参数控制的是事务提交时，日志从内存缓冲区刷到磁盘的策略，有三个取值。取1表示每次事务提交都把redo log刷到磁盘，最安全，性能也最差，但能保证即使数据库宕机也不丢数据。取2表示每次提交只写到操作系统的缓存里，由操作系统定期刷盘，性能好很多，但机器断电时可能丢最近的数据。取0则是每秒钟刷一次盘，性能最好，但MySQL自身崩溃都可能丢数据。
绝大多数业务场景，我建议保持默认值1。尤其涉及订单、支付、资金类的系统，数据安全永远优先于性能，丢一条事务记录就是重大的事故。但如果你的系统属于日志类、统计类，或者可以接受少量数据丢失的辅助系统，那么2是一个性价比很高的折中方案，实测能比1带来两三倍以上的写入吞吐提升。
有人会问，这个参数和sync_binlog是不是一回事。其实两者独立控制，innodb_flush_log_at_trx_commit管的是redo log，sync_binlog管的是binlog。最安全的状态是两者都为1，但这会让每次提交经历两次刷盘。如果对写入性能要求很高又不想丢数据，可以在保证底层存储IO能力的前提下，把sync_binlog调成1、innodb_flush_log_at_trx_commit保持1，然后升级SSD，这是我在项目里验证过的相对稳妥的方案。
2.4 容易被忽视的几个参数
除了上面三个大头，还有几个参数在特定场景下效果非常明显。
innodb_log_file_size定义redo log文件的大小。默认配置偏小，在高并发写入场景下，日志轮换频繁，会导致不必要的刷盘和性能抖动。调到512M到1G，配合较大的缓冲池，写入性能会更稳定。但文件太大也会让崩溃恢复时间变长，需要权衡。
tmp_table_size和max_heap_table_size控制内存临时表的最大值。排序和去重操作如果数据量超过这个值，临时表会落到磁盘上，性能骤降。出现大量Using temporary类型的执行计划时，可以考虑调大这两个参数。
还有一个要说的是query_cache。这个参数在5.7及以下版本默认关闭，到8.0直接移除了。很多旧教程还推荐开查询缓存，但实际体验下来，在写多读少的场景下，查询缓存反而会成为全局锁一样的瓶颈。所有针对它的调优知识点都可以丢掉了，不用担心这个参数，8.0之后没有它反而省心。
参数调整有个重要原则：一次只改一个。我曾经遇到过一个线上故障，同事一次性改了缓冲池、日志刷盘、排序缓冲等七八个参数，结果出问题根本定位不到是哪个参数引起的。后来我给自己定了个规矩：任何环境改动，一次只改一个参数，改完观察，确认稳定再改下一个。
3. 拉大差距的重头戏：SQL与索引层面的调优实战
3.1 慢查询日志：定位问题SQL的第一入口
配置调得再合理，也挡不住一条烂SQL拖垮整个系统。所以我的调优流程里，第一步永远是打开慢查询日志，把那些“害群之马”找出来。慢查询日志本身很简单，就是记录执行时间超过阈值的SQL语句。
在MySQL中可以通过以下方式临时开启：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; -- 超过1秒的SQL都会被记录 SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';线上生产环境，我建议long_query_time先设置为1秒甚至0.5秒。等业务稳定再把阈值放到2秒，减少日志量。还有两个容易忽略的开关：log_queries_not_using_indexes可以记录所有没有走索引的SQL，哪怕它执行很快，这个开关对发现隐性问题很有用；log_slow_admin_statements控制是否记录ALTER TABLE这类管理语句。
拿到慢查询日志之后怎么分析？我常用系统自带的mysqldumpslow工具，也可以直接打开日志文件看，慢日志文件里记录了每一条SQL的执行时间、锁等待时间、返回行数和扫描行数。重点看两类：一类是执行频率高、单次执行也不算快的SQL，这类SQL平均耗时虽然不大，但累积起来会吃掉大量资源；另一类是单次执行极慢的SQL，这类往往是全表扫描或者复杂关联查询。
3.2 读懂EXPLAIN：执行计划里的每一个关键信号
没有EXPLAIN的慢SQL分析等于盲人摸象。EXPLAIN是MySQL提供的一条命令，作用就是展示MySQL执行一条SQL时的具体计划。用法很简单，在SQL前面加EXPLAIN关键字，MySQL会返回一张执行计划表。这里面的每个字段都是有价值的信号。
我最先看的永远是type列。这张表把访问类型从好到坏分成好几个层级，依次是system（表中只有一行）、const（用主键或唯一索引查到一行）、eq_ref（关联查询时驱动表每行只匹配一行）、ref（用普通索引等值查询）、range（用索引做范围查询）、index（遍历索引树）、ALL（全表扫描）。看到ALL基本可以断定这条SQL有问题，但也别慌，全表扫描不是罪不可赦，如果表数据量本来就很小，那走全表扫描反而比走索引更高效。
其次是key列，看实际用了哪个索引。有时候你给表建了索引，但MySQL没有选它，这就是典型的“索引白建”。再看rows列，它估算的是MySQL认为它需要扫描的行数。这个值和实际表行数差距越大，说明统计信息越不准，或者SQL写法给了优化器错误的引导。最后别忘看Extra列，出现Using filesort表示排序没有走索引，产生额外开销；出现Using temporary说明用到了临时表，通常是GROUP BY或者DISTINCT导致，要特别警惕；出现Using index则是好信号，表示覆盖索引生效，不用回表。
EXPLAIN不是万能的，它显示的rows是估算值而非实际值，而且EXPLAIN只展示单条SQL的计划。真正确认问题，还要配合PROFILING或者状态变量来看实际耗时。但绝大部分情况下，慢SQL通过EXPLAIN就能定位到七八成问题。
3.3 索引设计：最左前缀法则与常见的索引失效
索引是MySQL调优里的第一生产力，但建了索引不等于万事大吉。联合索引遵循最左前缀法则：一个(a, b, c)联合索引，可以匹配(a)、(a, b)、(a, b, c)三种查询组合，但如果查询条件跳过了a直接以b开头，这个索引就无法使用。这是我在实际业务场景里反复验证过的，很多人建了联合索引但查询条件用不到最左列，索引就直接失效了。
常见的索引失效场景还有这么几个。第一，对索引列使用函数，比如WHERE DATE(create_time) = '2024-01-01'，这种写法会让索引失效，正确的做法是改成范围查询WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'，这样不仅索引能用，查询也更准确。第二，LIKE模糊查询时前置通配符，LIKE '%关键字'这种写法索引也会失效。第三，隐式类型转换，比如索引列是字符串，查询条件却传了数字，MySQL做了类型转换后索引照样用不上。第四，索引列参与了运算，比如WHERE price + 10 > 100这种写法也需要改写。
还有覆盖索引的概念，我觉得价值很高。普通索引查到行号之后还需要回表去查整行数据，但如果查询的字段都在索引树上，MySQL就不需要回表了，直接就能返回。举个例子，SELECT user_id, status FROM orders WHERE user_id = 123，如果user_id是索引列，而status不是，那就要回表；如果我在(user_id, status)上建了联合索引，那么这个查询可以直接从索引树拿到全部需要的字段，速度会快很多。覆盖索引还能减少随机IO，在高并发场景下效果明显。
3.4 深分页和Join：两个高频性能陷阱
深分页问题在日常业务里太常见了。LIMIT 200000, 10这个写法，MySQL会先扫描出前面200010条记录，然后丢掉前200000条，只返回最后10条。这个过程中所有扫描和排序都是真实发生的，所以页码越深，查询越慢，而且是线性上升的。
优化深分页有个经典做法叫延迟关联。思路是先通过子查询快速定位到目标行的主键ID，再拿这批ID去关联原表取完整数据。比如：
-- 优化前 SELECT * FROM orders ORDER BY create_time DESC LIMIT 200000, 10; -- 优化后 SELECT o.* FROM orders o INNER JOIN ( SELECT id FROM orders ORDER BY create_time DESC LIMIT 200000, 10 ) t ON o.id = t.id;子查询里只查主键和排序字段，用的是覆盖索引，扫描成本低很多，外层再按主键精确取行。还有一种思路是基于索引做偏移量循环，即每次记下上一页最后一条记录的位置，用WHERE create_time < 上一页最后时间来取下一页，而不是用OFFSET。这两种方式我都实测过，延迟关联实现简单、改动小，推荐优先考虑。
Join层面的坑，最典型的是没有索引驱动的关联。一张千万级的大表和一个只有几十行的小表做JOIN，如果关联字段没有索引，MySQL的嵌套循环可能要做几百万次数据比对。这里有一条铁律：关联查询中，驱动表（小表）的关联字段需要有索引，被驱动表（大表）的关联字段也必须有索引。另外要记住一个原则——小表驱动大表。在编写查询时，尽量把筛选后数据量小的结果集作为驱动表，优化器在很多情况下会自动调整，但复杂场景下手工调整会更可靠。
有一次我帮一个团队排查一条报表SQL，三张表做JOIN，带了一堆WHERE条件，执行时间稳定在8秒。用EXPLAIN一看，type列全是ALL，于是给关联字段和WHERE条件里的筛选字段补了索引。修改之后执行时间降到0.1秒，整个报表页面像换了台机器一样。这种案例在调优工作中几乎每天都在发生：SQL慢，往往就是缺一个索引或者有一个索引失效。
4. 从一次线上事故说起：完整调优案例走查
4.1 故障现象：一个订单查询接口的响应时间暴涨
有一段时间，我负责的一个业务系统在下午高峰期频繁出现接口超时告警。最开始只是零星几条，后来越来越密集。这个接口是订单查询，业务方反馈用户端页面加载要转圈好几秒。查监控数据，MySQL所在机器的CPU使用率不算太高，内存也还有余量，但磁盘IO等待时间明显升高，慢查询日志里的记录数量比平时翻了十几倍。
第一反应是去看慢查询日志，还真让我一眼就看到了问题：一条查询订单列表的SQL，单次执行时间竟然到了2.6秒，平时这个接口全链路也就80毫秒。从慢日志的扫描行数和返回行数来看，扫描了38万行，最终只返回20行数据——典型的“大海捞针”式查询。这条SQL的业务逻辑是按用户ID、订单状态、下单时间三个条件筛选订单，再按时间倒序取第一页。
4.2 定位过程：从慢日志到执行计划的逐层排查
拿到慢SQL，我立刻在测试库里跑了一遍EXPLAIN，结果很直观：type列显示ALL，全表扫描；rows列估算38万行；Extra列还出现了Using filesort。看到这三个信号，问题其实已经比较清楚了——这张订单表的查询条件字段没有合适的索引，MySQL只能把整张表读一遍，再在内存里做排序。
但这里有个值得留意的细节：表里其实已经有一个订单号的唯一索引，也有一个按创建时间的索引。那为什么WHERE条件用了user_id、status和create_time，优化器还是走全表呢？因为这三个字段没有组成联合索引，单靠其中一个根本无法高效过滤。create_time索引虽然存在，但订单表的create_time分布极其不均匀——这张表上线快三年了，90%以上的订单都集中在最近几个月，而查询场景里用户通常会选择半年前甚至更早的订单。优化器遇到这种情况，评估下来走create_time索引还不如全表扫描加排序来得“划算”。
这个例子很典型：不是索引不够多，而是没有根据查询模式设计正确的联合索引。
4.3 实施优化：建立联合索引和改写SQL
定位到问题后，我做了两步操作。
第一步，建立联合索引。根据查询条件的组合，我把联合索引设计为(user_id, status, create_time)。设计顺序的逻辑是：user_id是等值筛选，选择性最高，放在最左边；status也是等值条件，次之；create_time是范围条件，放在最后。这样查询走索引时，能够通过user_id和status快速定位到目标集合，然后在create_time索引段内做范围有序扫描，同时解决排序问题——因为索引本身按create_time有序，查询到结果时已经天然排好序了，Using filesort也顺带消失。
需要注意的一点是，如果条件里status有多个值（比如使用IN (1,2)），索引在status之后的部分可能不会完全使用；但在这个案例里，status是等值条件下的IN，MySQL 5.6之后的索引条件下推优化也能妥善处理，整体效果依然很好。
第二步，改写SQL。原SQL里用SELECT *获取所有列，我改为按接口实际需要的字段进行SELECT。这几个字段正好全部在联合索引的叶子节点上覆盖到了，变成了覆盖索引查询，连回表都省了。同时分页查询改造，改用上一页订单ID作为游标来取下一页，而不是用LIMIT OFFSET来做深分页。
优化完成后，我在测试库先验证了一遍：同样的查询条件下，执行时间从2.6秒降到45毫秒，扫描行数从38万降到了不足1000行，EXPLAIN里type从ALL升级为ref，Extra也没有Using filesort了。上线之后连续观察一周，这个接口的线上平均响应时间稳定在60毫秒左右，高峰期再也没出现超时告警。
4.4 复盘：调优前后对比和踩坑记录
复盘这个案例，有几个地方值得拿出来单独说。
第一个是一开始差点走弯路。最初我准备直接扩充硬件资源来解决，理由是磁盘IO等待时间长。但仔细分析后发现硬件层面的IO压力是结果而不是原因——SQL读了几十万行，数据全不在内存里，导致反复读磁盘。就算换了再快的磁盘，这种写法依然会被拖慢。正确的顺序是先优化SQL，再看硬件需要不需要升级。
第二个是索引上线时的风险控制。给线上大表建索引时，如果直接执行ALTER TABLE，MySQL会重建整张表，几千万行的订单表可能锁写几个小时。我当时的做法是用pt-osc这类在线变更工具，或者利用8.0版本的ALGORITHM=INPLACE选项，在不阻塞业务读写的情况下完成索引创建。这一步如果没注意，优化的过程本身就会变成一次事故。
另外还发现一个附加问题：这个接口在高峰期偶尔报“Too many connections”。查了一下Threads_connected，确实到了峰值上限。原因是应用层的连接池配置过大，加上很多长时间空闲的连接没有及时释放。我把wait_timeout从默认的8小时调到300秒，同时调整了应用连接池的最小空闲连接数，这个问题也没有再出现过。
5. 避坑指南：常见问题、排查套路与实操笔记
5.1 改完参数不生效是怎么回事
参数改完不生效是我在交流群里看到最多的问题。通常有三种原因。
第一种是改错了级别。MySQL参数分全局级和会话级，你用SET SESSION改的只对当前会话生效，别的连接感知不到。用SET GLOBAL改的是全局级别的，但是注意：已经存在的旧连接不会立刻拿到新值，要重新连接才会应用。所以改参数后，要么等连接重建，要么主动重启应用。
第二种是参数被静态限制。像innodb_buffer_pool_size这类参数其实支持动态修改，但innodb_log_file_size、max_connections在部分版本里就不能在线生效。遇到这类参数，需要修改配置文件并重启MySQL。改配置文件之前务必做好备份，重启之前再看一遍配置项有没有语法错误。
第三种是重启之后丢配置。很多人只用了SET GLOBAL临时改，没有更新配置文件，MySQL一重启就回到原样。正确的姿势是两条路同时走：一边在线SET GLOBAL，一边把配置写进/etc/my.cnf或/etc/mysql/mysql.conf.d/对应文件，双保险。
5.2 索引建了但优化器就是不选
这是另一个高频困惑。索引明明建了，EXPLAIN出来还是ALL。我遇到过几个具体情况。
一个是统计信息过期。MySQL的优化器靠表的统计信息来决定执行计划，如果表刚经历过大量数据变更，统计信息没跟上，优化器就会做出错误判断。解决办法是执行ANALYZE TABLE 表名刷新统计信息，很多情况下刷完之后执行计划就正常了。
另一个是数据分布问题。优化器评估后发现，就算走索引也仍然要访问大量行，那还不如全表扫描+顺序读。比如一张小表总共几百行，索引查询需要访问其中一半数据，优化器就会倾向全表扫描。这种情况不是病，不需要强行纠正。
还有一个是查询写法限制。前面提到的隐式类型转换、函数包裹索引列、LIKE前置通配符都会让优化器想用索引也用不上。这种问题只能靠改写SQL解决，没有捷径。
如果实在判断不了优化器为什么选了次优计划，可以用FORCE INDEX强制走某个索引来对比效果。但这个方法我只建议在排查阶段用，不建议上线长期使用——表数据量变化后，强制索引可能反而不如优化器自己的选择。
5.3 磁盘IO持续高的排查套路
磁盘IO高是MySQL最容易被误诊的问题之一。很多新手看到IO高，第一反应是加内存，或者换高性能SSD。但在动手之前，我建议先区分两类情况：逻辑IO高和物理IO高。
逻辑IO高意味着数据库频繁地进行大范围的数据读取，表现在SHOW GLOBAL STATUS里面的Innodb_pages_read持续增加。这种情况的根因通常是SQL扫描行数过多，要么是缺索引，要么是查询条件不带过滤且大量读取。物理IO高则是数据不在内存中，必须从磁盘读取，这跟缓冲池大小和冷热数据比例有关。
排查顺序我一般是这样的：先用iostat看磁盘的利用率、IO队列长度和等待时间，确认IO压力真实存在；再打开performance_schema或者sys库，按SQL语句分组统计磁盘逻辑读次数。sys.statement_analysis这个视图能直接列出每条SQL的累计执行次数、总耗时、扫描行数，非常好用，我线上定位问题SQL基本都靠它。
物理IO持续高还有一个容易被忽略的原因——脏页刷盘。如果业务是密集写入型，innodb_io_capacity设置过低，会导致InnoDB在批量刷脏页的时候产生IO尖峰。这种情况下调整innodb_io_capacity和innodb_io_capacity_max，配合合理的innodb_max_dirty_pages_pct，能有效平滑刷盘节奏。
5.4 连接数暴涨的应对方案
连接数暴涨在业务大促或者突发流量场景下非常常见。处理这类问题不能只盯着max_connections这一个参数，我总结了一套组合拳。
第一是快速止血。如果当前Threads_connected已经接近上限，先临时调大max_connections，给业务喘息空间，但这个操作会加大MySQL本身的压力，适合短期顶一下，不适合长期维持。同时立刻把连接池参数优化：缩短wait_timeout，让空闲连接快速释放。
第二是找源头。连接数暴涨往往不是数据库的问题，而是应用层的连接池配置不合理。应用连接池的maximum-pool-size如果配得过大，在流量尖峰时所有线程同时抢连接，瞬间就会把数据库连接数打满。我在项目里曾遇到过一次事故，应用侧连接池上限配到了200，三个服务实例同时扩容，结果数据库瞬间收到600个连接，直接把MySQL打挂了。后来把应用连接池上限压到50每实例，数据库侧再配合合理的max_connections，就稳下来了。
第三是处理慢查询。如果连接数高且Threads_running高，说明大量连接进来后都在跑很慢的SQL，连接被长时间占用。这时候核心任务是找慢SQL并优化，否则连接数只会持续堆积，光调参数没意义。如果短时间内无法优化SQL，可以考虑在数据库前面加一层查询缓存或把读流量切到只读副本，这些都是过渡方案，但能争取到优化时间。
5.5 软件层优化到顶之后的路
把SQL和参数都优化到位之后，单机MySQL的性能上限早晚会到来。这时候要考虑的就不仅仅是“调优”二字了，而是整个数据架构的演进。
最基础的一步是读写分离。业务中的读流量通常远大于写流量，把读流量分到只读副本上，应用层通过中间件做路由，能够显著减轻主库压力。这里要注意的是，读写分离会有主从延迟问题，如果业务对一致性要求很高，读自己的写这种场景需要做特殊处理，比如强制读主库。
再往前走是分库分表。当单表数据量超过千万甚至上亿，即使索引设计很合理，写入性能也会遇到瓶颈。分库分表不是小事，它会引入分布式事务、全局ID、跨库查询等一系列复杂问题，所以一定要在架构层面充分论证后再动手。还有一种更温和的过渡方案是数据归档，把历史订单数据迁移到归档表或冷存储，业务表只保留近几个月的数据，这种方式执行成本低，在业务允许“查旧数据走专门通道”的前提下非常实用。
还有就是在数据库前面叠加缓存层。热点数据进Redis之类的内存缓存，数据库只承担最终一致性写入和兜底查询。这一层加得好，数据库的压力可以下降一个数量级。我见过很多性能问题其实根本不该找数据库解决——有些数据读多写少、实时性要求不高，却每次实时查库，这种场景不优化缓存策略，数据库再调也没什么用。
我个人在实际操作中的体会是：MySQL调优的终点不是某个参数完美，而是你对自己的数据访问模式有了清晰认知，知道哪部分工作数据库自己能干好，哪部分应该交给缓存、交给拆分、交给架构去解决。尊重每一层的职责边界，性能问题才能真正长治久安。
