企业官网建设流程全解析

1. 慢查询到底是什么，为什么你必须关注它

第一次接手线上MySQL数据库的时候，我最头疼的事不是别人问"MySQL怎么安装"，而是深更半夜收到一条警报：CPU飙升、接口超时、用户开始骂人。翻遍代码找不到问题，最后打开慢查询日志，一眼就看见那条该死的SQL——三张表join，一张表几百万行数据，连索引都没有，一次查询跑了几十秒。从那以后我就养成了一个习惯：接手任何数据库，第一件事就是确认慢查询日志有没有开，没开就先开上，再谈别的。

很多人觉得慢查询日志是"事后诸葛亮"，出了问题才去翻。这个想法大错特错。慢查询日志的价值恰恰在于提前发现——它不是在你已经故障的时候才出现，而是每天都把那些执行时间超标的SQL悄悄记下来，等你有空的时候去翻一翻，就能提前发现那些"现在还不致命、但数据量一涨就会爆炸"的隐患。我见过太多案例，一个小查询在十万行数据时跑50毫秒，没人管，等数据涨到一千万行的时候变成5秒，直接拖垮整个业务。慢查询日志的意义，就是让你在50毫秒的时候就注意到它，而不是等到5秒才被迫处理。

那到底什么叫慢查询？MySQL的定义很简单：凡是执行时间超过long_query_time阈值的SQL语句，都会被记录到慢查询日志里。默认情况下这个阈值是10秒，但说实话，10秒这个值在互联网业务里太奢侈了，一般我建议线上业务改成1秒甚至更低。注意，这里说的执行时间不光是SQL本身执行的时间，还包括锁等待、排序、回表这些环节的耗时，也就是说，一条SQL从开始执行到返回结果的完整时间。

慢查询日志解决的核心问题就两个：第一，知道哪些SQL慢；第二，知道它们慢在哪。前者靠日志记录，后者靠执行计划分析。这篇文章我会从怎么开启慢查询日志开始，一步步讲到怎么读日志、怎么用工具聚合分析、怎么用EXPLAIN定位瓶颈，最后分享一些我在实际运维中踩过的坑。无论是刚入门的DBA、后端开发，还是自己折腾服务器的博主，这篇文章都值得你从头到尾看一遍，因为慢查询排查这活儿，不管你用什么数据库中间件、什么云平台，思路永远是通用的。

2. 开启慢查询日志的正确姿势

2.1 先看当前状态——别急着改配置

接手一台MySQL服务器，第一件事永远都是先查现状，而不是直接改参数。我用得最多的就是这组命令：

SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'slow_query_log_file'; SHOW VARIABLES LIKE 'long_query_time'; SHOW VARIABLES LIKE 'log_queries_not_using_indexes';

这四个参数是慢查询日志的四大核心配置。slow_query_log是开关，ON就是开着；slow_query_log_file是日志文件路径；long_query_time是时间阈值，单位是秒，支持小数，比如0.5就是500毫秒；log_queries_not_using_indexes记录那些没走索引的查询。

这里有个细节很多人容易搞混：long_query_time的判定从MySQL 5.1开始就是"超过这个值才记录"，等于不算，是严格大于的关系。另外在MySQL 5.1.6之前还有个log_long_queries参数，老版本用的，现在早就废了，看到网上老教程里出现就别照着抄了。

还有一个坑是slow_query_log_file指定的目录。MySQL进程要有权限写这个文件，否则日志起不来，或者写一半卡住。常见的情况是用了默认路径，但那个分区磁盘满了，慢查询日志写不进去，你还在那傻等。我给个建议：把这个文件放到独立的数据盘目录下，跟数据目录分开，这样就算日志暴增也不会拖垮系统盘。

2.2 临时开启与永久开启，两种方式都要会

临时开启是针对当前实例的，重启MySQL后配置就丢了。这种方式适合你只是想临时排查问题，不想动配置文件：

-- 临时开启慢查询日志 SET GLOBAL slow_query_log = 'ON'; -- 设置阈值 SET GLOBAL long_query_time = 1; -- 记录没有走索引的查询 SET GLOBAL log_queries_not_using_indexes = 'ON';

注意一点，SET GLOBAL改的是全局值，但对当前已经存在的连接不生效。也就是说，你改了之后，新发起的连接才会用新值，之前那些连接还是老配置。如果你想对当前会话也生效，得加上SET SESSION。这个细节在实际操作中非常容易踩，我曾经就是改了全局阈值，结果测试客户端用的是长连接，跑了半天发现日志里一条都没记，还以为是配置出了问题，实际上是会话级参数没跟上。

永久开启需要修改配置文件my.cnf（Linux）或my.ini（Windows），在[mysqld]段落里加上：

[mysqld] # 开启慢查询日志 slow_query_log = 1 # 日志文件路径，建议用绝对路径 slow_query_log_file = /var/log/mysql/mysql-slow.log # 阈值1秒，线上业务建议这个值往下调 long_query_time = 1 # 记录未使用索引的查询 log_queries_not_using_indexes = 1 # 限制日志文件大小，避免撑爆磁盘（5.7+支持这个参数） slow_query_log_file_size = 1073741824

改完之后重启MySQL服务生效。不过这里要提醒你，生产环境尽量别动不动重启，我一般做法是：先用SET GLOBAL在线开启，然后再改配置文件，等下次维护窗口重启的时候自然永久生效。这样既不间断业务，又能保证配置最终落盘。

2.3 阈值到底设多少才合理

long_query_time设置多少合适，这个问题没有标准答案，得看你的业务场景。我见过最极端的一个案例，有个团队把所有SQL都设为阈值0，结果慢查询日志每分钟几十万条，直接把磁盘打爆了。也见过一个传统企业项目，阈值设成20秒，等于什么都没记录。

我个人的经验是分场景来定：

还有一点，log_queries_not_using_indexes这个开关，我建议在开发环境开着，生产环境要看情况。它在MySQL 5.6之后有个变化，不是所有没走索引的查询都会被记录，比如全表扫描的行数小于一定阈值时不会记。而且这个开关产生的日志量极大，生产环境如果没有专人盯日志，容易被大量无效记录淹没，反而看不清真正的问题。我一般是开发环境开启，线上谨慎开启或者关闭。

3. 慢查询日志里到底记了什么——读懂每行内容

3.1 日志字段逐一拆解

开启慢查询日志之后，过一段时间你就能看到类似这样的内容：

# Time: 2024-06-15T10:23:45.123456Z # User@Host: root[root] @ localhost [127.0.0.1] Id: 812345 # Query_time: 2.345678 Lock_time: 0.001234 Rows_sent: 100 Rows_examined: 1000000 # Thread_id: 8 Schema: orders Last_errno: 0 Killed: 0 # InnoDB_trx_id: 18875 SET timestamp=1718442225; SELECT o.order_id, u.user_name, p.product_name FROM orders o LEFT JOIN users u ON o.user_id = u.user_id LEFT JOIN products p ON o.product_id = p.product_id WHERE o.status = 'pending' ORDER BY o.create_time DESC LIMIT 100;

这段日志信息量很大，一个一个说。Query_time是查询总耗时，这是你判断SQL是否超时的直接依据；Lock_time是锁等待时间，如果这个值很高，说明SQL在等待其他事务释放锁，问题未必在SQL本身的执行效率上；Rows_sent是实际返回给客户端的行数；Rows_examined是这条SQL为了返回结果而扫描过的行数——这个数值是重中之重，Rows_examined和Rows_sent的差距越大，说明扫描了大量行却只返回了少量行，典型的索引问题或者查询逻辑问题。

SET timestamp=...这行在日志里容易被忽略，但它很重要。因为慢查询日志里记录的SQL是后补的，如果你直接复制SQL执行，得到的执行计划和当时会有差异。SET timestamp让你知道这条SQL当时执行的时间点，配合监控系统就能还原当时的服务器状态。

3.2 日志格式：MySQL 5.7和8.0的差异

MySQL 5.7默认的慢查询日志格式是文本格式，可读性好，但解析起来麻烦。MySQL 8.0引入了log_output参数设置日志输出格式，可以是FILE（文本文件）、TABLE（记录到mysql.slow_log表）或者两者都写。我建议生产环境用FILE格式，理由有两个：一是文件格式可以用各种现成工具分析；二是表格式写入本身有开销，高并发下会影响性能。

log_output=TABLE的场景也有，就是当你需要直接用SQL查询慢查询记录时很方便，比如：

SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;

但说实话，我用得很少，还是文件格式加工具分析最顺手。MySQL 8.0里还有一个long_query_time支持微秒级别的设置，比如0.000100表示100微秒，不过日常用不到这么细。

3.3 日志会记录哪些SQL，不会记录哪些SQL

慢查询日志记录的是执行完成的SQL。也就是说，如果一条SQL因为锁等待超时、被客户端取消或者其他原因导致没有执行完成，它不会被记录。这是一个很容易被误解的点——你以为慢查询日志能捕获所有"卡住"的查询，实际上它只捕获"慢但最终执行完"的查询。那些被kill掉的、陷入死锁的SQL，还得靠其他手段排查，比如performance_schema里的事件记录。

另外，慢查询日志记录的是DML语句（SELECT、UPDATE、DELETE、INSERT等），预编译语句也会记录，比如PreparedStatement方式执行的SQL会记录对应的语句文本。但存储过程内部执行的SQL，在存储过程级别不会被记录，除非内部SQL本身超时了才会记录那条SQL。

管理类语句像CREATE INDEX、ALTER TABLE这种DDL操作，虽然也耗时，但默认情况下不记录在慢查询日志里。这点经常让人迷惑——你明明在凌晨跑了两个小时的ALTER TABLE加索引，慢查询日志里却什么都没有。MySQL 5.7开始有个log_slow_admin_statements参数，可以控制是否记录这种管理语句，建议需要分析DDL耗时时把它开开。

4. 慢查询日志别用眼睛看，工具才是亲爹

4.1 日志一多就抓瞎，先学会用mysqldumpslow

慢查询日志开了一段时间后，文件可能是几百MB甚至几个GB。这时候你如果还是用tail -f或者less一页页翻，效率极低。MySQL自带了mysqldumpslow工具，专门用来汇总分析慢查询日志。

它的基本用法很简单：

# 查看日志里最慢的10条SQL mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log

参数说明：-s是指定排序方式，c代表按执行次数计数排序，t是返回前N条，al是平均锁等待时间，at是平均查询时间。我常用的是：

# 按平均查询时间排序，看最慢的20条 mysqldumpslow -s at -t 20 /var/log/mysql/mysql-slow.log # 按执行次数排序，看哪些SQL被频繁执行且耗时 mysqldumpslow -s c -t 20 /var/log/mysql/mysql-slow.log

mysqldumpslow有个很聪明的设计：它会自动归一化SQL。什么叫归一化？就是把SQL里的具体值替换成抽象的占位符。比如：

SELECT * FROM users WHERE id = 10086; SELECT * FROM users WHERE id = 10087;

这两条在工具看来是同一类SQL，会合并统计。这样你看到的就是"某类"慢查询的总共执行次数、平均耗时、最大耗时，而不是被几千条相似SQL淹没。

不过mysqldumpslow也有局限，它只支持基本统计，看不到SQL执行计划的细节，而且对复杂的多表查询、子查询归一化处理得不算好。正常情况下，我拿它做第一轮筛选，找出嫌疑SQL，然后再对每一条单独做EXPLAIN分析。

4.2 pt-query-digest：慢查询分析的终极武器

要说慢查询日志分析工具里哪个最能打，那必须是Percona Toolkit里的pt-query-digest。这个工具比mysqldumpslow强太多了，它不仅能分析慢查询日志，还能分析通用日志、二进制日志。安装Percona Toolkit的方式各个系统不一样，Ubuntu上是：

sudo apt-get install percona-toolkit

CentOS上需要先配置Percona的yum源再安装，这里不展开。装好之后，分析慢查询日志的姿势：

pt-query-digest /var/log/mysql/mysql-slow.log

输出结果分三大块。第一块是总体报告，包括分析时间段、SQL总数、唯一SQL数、总耗时、最长耗时等。第二块是按查询类型分组的排名，会列出每个查询组的执行次数、总耗时、平均耗时、占比，默认按总耗时排序。第三块是每个查询组的详细profile，展示该组SQL的响应时间分布、归一化后的SQL文本、示例SQL等。

这个工具最厉害的地方在于，它会把所有SQL按"指纹"分组，这个指纹是基于SQL文本生成的哈希值，跟mysqldumpslow的归一化类似但更精细。你一眼就能看出哪类SQL消耗了数据库80%的时间，然后重点针对它优化。

用pt-query-digest还有一个场景我特别推荐：对比分析。比如大促前后分别收集一个慢查询日志，然后用工具的--review选项对比两次的差异，就能知道哪些SQL的耗时在大促期间恶化最严重。这个功能在容量规划和限流策略制定时非常有价值。

4.3 没有Percona Toolkit时怎么办——纯SQL查询方案

有些环境不让装第三方工具，或者你觉得装重量级工具不划算。没关系，还有土办法。MySQL 5.7+可以把慢查询日志输出到表里，然后直接用SQL分析：

-- 开启表格式输出 SET GLOBAL log_output = 'TABLE'; SET GLOBAL slow_query_log = 'ON'; -- 按执行次数排序，看高频慢SQL SELECT LEFT(SUBSTRING(sql_text, 1, 50), 30) AS sql_prefix, COUNT(*) AS cnt, ROUND(AVG(query_time), 2) AS avg_query_time, MAX(query_time) AS max_query_time FROM mysql.slow_log GROUP BY sql_prefix ORDER BY cnt DESC LIMIT 20;

不过我得说，这种方法的分析能力有限，只能做初步统计。而且mysql.slow_log表引擎是CSV，查询效率感人，数据量大了会越来越慢。所以它只适合救急，真正的高效分析还得靠文件格式加专业工具。

5. 从发现慢SQL到定位瓶颈——EXPLAIN实战解读

5.1 一条慢SQL的标准分析流程

日志发现了慢SQL，复制到测试库，怎么一步步找到问题根源？我的标准动作是：

第一步，看SQL本身，搞清楚它是干什么的，涉及哪些表，逻辑是否合理。第二步，用EXPLAIN看执行计划。第三步，分析每个表的访问方式、关联顺序、扫描行数。第四步，结合索引情况和数据分布验证。第五步，改写SQL或者加索引。

EXPLAIN的用法很简单，就是在SQL前面加上EXPLAIN关键字：

EXPLAIN SELECT o.order_id, u.user_name, p.product_name FROM orders o LEFT JOIN users u ON o.user_id = u.user_id LEFT JOIN products p ON o.product_id = p.product_id WHERE o.status = 'pending' ORDER BY o.create_time DESC LIMIT 100;

执行后你会得到一张表，重点关注这么几个列：

• type：访问类型，从好到差依次是system、const、eq_ref、ref、range、index、ALL。看到ALL就说明在做全表扫描，这是最常见的慢查询根因。
• key：实际用到的索引，如果为空，说明没走任何索引。
• rows：预估扫描的行数，这个数是优化器估计的，不一定精确，但量级很有参考价值。
• Extra：这一列信息量巨大，看到Using filesort说明需要文件排序，看到Using temporary说明用了临时表，看到Using where说明索引条件下推不充分。

还是用上面那个例子，如果EXPLAIN结果显示orders表的type为ALL，预估扫描100万行，那问题就很明显了：WHERE o.status = 'pending'这个条件没有索引可用，MySQL只能挨个翻表看看哪行符合条件。再加个ORDER BY o.create_time DESC，又触发文件排序，双重debuff，不慢才怪。

5.2 一个完整的优化案例拆解

我给你看一个我自己实际处理过的案例。业务反馈某个列表页接口越来越慢，最开始50毫秒，现在1.2秒，还没到警报线，但趋势不对。抓慢查询日志找到SQL：

SELECT id, title, user_id, create_time FROM articles WHERE category_id = 105 AND status = 1 ORDER BY create_time DESC LIMIT 10;

EXPLAIN结果：

type: ref key: idx_category rows: 23456 Extra: Using where; Using filesort

表面看起来走了idx_category索引，不算太差，为什么慢？仔细分析：category_id = 105这个分类下有两万多行，然后还要在结果里过滤status = 1，再按create_time排序，最后取10条。问题就出在这里——索引只过滤了分类，没有同时处理状态和排序，导致MySQL查完两万多行后还要做文件排序，当然快不起来。

优化方案是建一个联合索引：

ALTER TABLE articles ADD INDEX idx_cat_status_time (category_id, status, create_time);

注意索引列的顺序有讲究：等值条件的列放前面，这里是category_id和status，排序字段create_time放最后。这样设计的原因是，MySQL可以用这个索引同时完成过滤和排序，避免Using filesort。优化后EXPLAIN变成：

type: ref key: idx_cat_status_time rows: 186 Extra: Using index condition

扫描行数从两万多降到186行，接口耗时从1.2秒回到30毫秒。这个案例就是说，慢SQL排查不能只满足于"走了索引"，要看索引是否真的覆盖了查询的所有需求。

5.3 索引没生效的几种常见原因

索引建了但没用上，这是比没建索引更让人头疼的情况。我总结了几个常见原因：

隐式类型转换。如果字段是VARCHAR类型，SQL里写WHERE user_id = 12345（数字），MySQL会隐式把字符串转成数字，导致索引失效。正确写法是WHERE user_id = '12345'。

对索引列使用函数。WHERE DATE(create_time) = '2024-06-15'会让索引失效，因为MySQL要先对每一行的create_time执行DATE函数才能比较。正确做法是WHERE create_time >= '2024-06-15 00:00:00' AND create_time < '2024-06-16 00:00:00'。

前导模糊查询。WHERE title LIKE '%MySQL%'，百分号在最前面的模糊匹配没法用索引，只能全表扫。这个没有特别好的索引解法，如果确实有需求，考虑全文索引或者搜索引擎。

联合索引不满足最左前缀原则。建了(a, b, c)联合索引，但查询条件只用到b和c，不包含a，索引失效。

优化器选择不用索引。这也是一种情况，你以为MySQL会走索引，但优化器经过成本估算，认为全表扫描更快（比如数据量很少，或者要回表的行数占比太高，比如超过20%~30%）。这种情况有时候可以通过FORCE INDEX强制走索引，但我不建议直接这么干，更健康的做法是优化SQL本身的逻辑，或者更换索引设计。

排查索引问题最实用的工具是EXPLAIN之外再配合SHOW WARNINGS。执行完EXPLAIN后再加一句SHOW WARNINGS，MySQL会告诉你它实际重写后的SQL长什么样，方便对照。

6. 慢查询的治理闭环——从发现到预防

6.1 日志只是起点，要建立问题跟踪机制

很多团队开了慢查询日志之后就再也不管了，三个月后日志文件几个GB，但没有任何人看过。这是典型的"开了个寂寞"。我建议是形成一套循环：每日采集 → 每周分析 → 每季度治理回顾。

每日采集可以靠定时任务，比如每天凌晨跑一次pt-query-digest，把结果输出成当天报告，存到固定的目录。每周抽时间看一周汇总，挑出Top 10耗时组织开会讨论。新增慢SQL要登记，优化完要验证，没优化完的要放进待办池。

这套机制看起来简单，但真正坚持下来的团队不多。很多人的思维是"业务不报障就不管"，等业务方找上门来的时候，往往已经是用户都感知到卡顿的阶段了。我觉得做技术的，应该有这种"主动出击"的觉悟。

6.2 结合监控平台实时告警

日志分析是事后行为，实时告警才能防患于未然。现在主流做法是把MySQL的SHOW GLOBAL STATUS里的指标，或者performance_schema的数据，采集到Prometheus这类监控平台，配上Grafana做可视化看板。

关键的告警项有这么几个：

实时监控的一个难点是阈值怎么定。我建议是先从半年的慢查询日志里算出每天的平均数和P95值，再用这个做基线。不要拍脑袋定一个1秒，因为不同业务差异太大。

6.3 推荐一套我常用的慢查询巡检脚本

我把自己日常巡检用的一个Shell脚本简化后放在这里，逻辑很简单：每天跑一次，把当天的慢查询日志分析结果邮件发给自己，或者写到指定文件里，周末再汇总。

#!/bin/bash LOG_DIR="/var/log/mysql" SLOW_LOG="${LOG_DIR}/mysql-slow.log" REPORT_DIR="/var/log/slow_report" TODAY=$(date +%Y%m%d) mkdir -p ${REPORT_DIR} # 用pt-query-digest分析当天的慢日志 pt-query-digest ${SLOW_LOG} --since 24h > ${REPORT_DIR}/report_${TODAY}.txt # 取Top 5输出到单独文件 pt-query-digest ${SLOW_LOG} --since 24h \ --limit 5:95:1 > ${REPORT_DIR}/top5_${TODAY}.txt # 统计当天慢查询总量 slow_count=$(grep -c "^# Query_time:" ${SLOW_LOG}) echo "Date: ${TODAY} SlowQueries: ${slow_count}" >> ${REPORT_DIR}/summary.txt

这个脚本你可以用crontab每天凌晨跑一次：

0 2 * * * /usr/local/bin/slow_query_analyze.sh

脚本运行完之后，早上上班第一件事就是随手翻一下报告，看看昨天有没有新的慢SQL冒出来。养成这个习惯之后，你会发现线上SQL的性能问题基本都能在爆发之前被扼杀在摇篮里。

7. 那些年我踩过的坑——慢查询日志的隐秘角落

7.1 参数改了不生效的连环坑

慢查询日志相关参数有全局和会话之分，这是最基础的坑。但更隐蔽的坑是：MySQL 8.0里SET GLOBAL设置了slow_query_log之后，如果配置文件里写的是slow_query_log = OFF，重启之后会被配置文件覆盖回去。你以为永久开启了，实际上重启之后又关了。这种问题在日志文件上看不出来，直到某天发现慢查询日志突然不更新了才察觉。

解决方法是改完配置文件后必须验证一遍，用SHOW VARIABLES确认所有相关参数的实际值。我自己有个习惯，改完配置之后写一条慢SQL故意触发一下，然后去看日志文件有没有新增记录。这个验证动作只要几秒钟，能省掉后面无数排查时间。

7.2 磁盘满导致日志写不进去

慢查询日志默认会无限增长，如果不做日志轮转，迟早占满磁盘。磁盘满了MySQL会怎么样？不会崩溃，但会拒绝写操作，造成写入阻塞，这比慢查询本身更严重。我在生产环境见过最惨的一次就是慢查询日志直接把根分区写满，所有业务写入全部卡死，最后不得不删日志紧急恢复。

我的处理经验是三层防护。第一，日志文件和数据库数据目录分开，别放在同一个分区。第二，用logrotate做日志切割，按天或者按大小轮转，保留最近7天。第三，开启slow_query_log_file_size限制单个文件大小，超过自动轮转。这三层都做到，基本不会出大问题。

7.3 不要忽视锁等待时间高的慢查询

有时候Pull出来的慢SQL，Query_time很高，但Rows_examined并不大，执行计划也走了索引。这时候问题很可能不在SQL本身，而在Lock_time上。Lock_time高说明SQL大部分时间在等待锁释放。

怎么验证？看慢查询日志里Lock_time和Query_time的比值。如果Lock_time占了大头，你需要排查其他并发事务。特别是线上业务用了SELECT ... FOR UPDATE、UPDATE、DELETE这类会加锁的语句，在高并发场景下容易互相阻塞。这时候光优化SQL没用，得从业务层下手，比如减小事务范围、减少锁的持有时间、用乐观锁代替悲观锁。

7.4 慢查询日志记录的是"因"还是"果"？

最后讲一个我自己的理解。很多人一看到慢查询日志里某条SQL耗时5秒，就认定这条SQL是性能问题的根源，急着改写SQL。但慢查询日志记录的只是表象，真正的"因"可能是它执行时的系统状态——比如当时服务器负载本来就高，磁盘IO饱和，CPU被打满，任何SQL执行都会变慢。

所以分析慢查询日志时一定要结合当时的时间点和监控数据来看。如果某条SQL平时执行很快，只有特定时间段才慢，那要考虑的不光是SQL本身，还有服务器的资源竞争、定时任务冲突、备份作业并发等问题。慢查询排查是一个系统性的工作，不能只盯着SQL文本，而要把它放到整个运行环境里去理解。

8. 最后：一个老运维的心里话

做了这么多年数据库运维，我越来越觉得慢查询排查这事儿，真正考验人的不是工具用得有多熟练，而是你有没有一套完整的思路。日志开没开、阈值合不合理、看到慢SQL之后能不能快速定位到索引问题和锁问题、优化完之后有没有持续跟踪验证，每一步都环环相扣。

我个人最深的体会是，慢查询日志不是用来背锅的，而是用来帮团队提前发现隐患的。它记录的每一条慢SQL，都是数据库在告诉你"我这儿有个地方快撑不住了，你有空来修一下"。你认真对待它，它能帮你把很多故障消灭在萌芽状态；你无视它，它就会在某个深夜给你一个大惊喜。

如果你现在还没有开启慢查询日志，今天就动手开起来，阈值设成1秒，然后把日志分析工具装上。一个月后再回头看，你会感谢当时的这个决定。