性能调优 on Liangweidong's blog

Linux 性能调试与应急排查：htop / sysdig / unhide 与挖矿病毒清理

Mon, 03 Jun 2024 00:00:00 +0800

〇、2024 视角（写于 2024-06）

本篇首发于 2024-06，过去 2 年挖矿病毒、内核 Rootkit 形态发生了一些变化：

unhide 仍是 Linux 下找隐藏进程最轻量的工具，但部分 Rootkit 已经能 hook 掉 /proc 遍历，建议结合 sysdig / bpftrace 一起看。
sysdig 2023 起被 Sysdig 公司收为闭源商业版的一部分，但社区 fork draios/sysdig 仍可拉取旧版开源；2024 推荐用 bpftrace / opensnoop-bpftrace 替代做 syscall 级追踪。
挖矿病毒命名：过去是 8 位随机名（f54e90d4），2024 已进化为伪装成系统服务名（kthrotlds、migration/0），单看名字不再可靠，必须看 cmdline + 真实可执行路径。
应急 SOP 没变：先断网 → 看进程 → 看 cron → 杀进程 → 删 cron → 改密码 → 关密码登录 → 备份数据后重装。

下面进入正文。

一、为什么需要"应急排查"清单

线上服务器出现异常，最贵的成本不是 CPU 也不是磁盘，而是"不知道下一步该敲什么命令"。本文按"症状 → 第一条命令 → 深入分析 → 处置"的顺序，整理了 4 个最常见场景的应急清单：

CPU 拉满但 top 看不出明显元凶（隐藏进程 / 多核分配）
磁盘 IO 飙高（iostat / 临时压测复现）
登录用户可疑（踢人 / 改端口）
挖矿病毒（unhide / sysdig 找进程 / 清理定时任务）

每个场景都给最小可运行命令，不讲空洞理论。

重要原则：发现入侵迹象后，先断网再排查，避免恶意进程远程"自删"破坏现场。

二、场景 1：CPU 拉满

2.1 一条命令把 CPU 吃满（用于复现 / 压测）

1
2
3
4
5
6
7


# 起 N 个 dd 占满所有核心（N = 物理 CPU 个数）
for i in $(seq 1 $(cat /proc/cpuinfo | grep "physical id" | wc -l)); do
 dd if=/dev/zero of=/dev/null &
done

# 收尾
pkill -9 dd

原理：dd if=/dev/zero of=/dev/null 不产生 IO，只用 CPU。N 个并行正好把 N 核打满。

2.2 内存打满（用于测试 OOM）

1
2
3
4
5
6
7


# 占 1G 内存 1 小时
mkdir /tmp/memory
mount -t tmpfs -o size=1024M tmpfs /tmp/memory
dd if=/dev/zero of=/tmp/memory/block
sleep 3600
umount /tmp/memory
rmdir /tmp/memory

2.3 磁盘 IO 打满（用于复现 IO 瓶颈）

1
2
3


while true; do
 dd if=/dev/urandom of=/burn bs=1M count=1024 iflag=fullblock
done

跑起来后用 iostat 观察：

1

iostat -d -x -k 1 1

关键列含义：

列	含义
`r/s` / `w/s`	每秒读 / 写次数
`rkB/s` / `wkB/s`	每秒读 / 写 KB
`await`	平均每次 IO 等待时间（ms）
`svctm`	平均每次 IO 服务时间（ms）
`%util`	设备繁忙时间占比，接近 100% 就是瓶颈
`avgqu-sz`	平均 IO 队列长度

2.4 CPU 满但 `top` 看不到凶手

很可能是进程被 Rootkit 隐藏了。ps 只能看到 /proc 里可见的进程，Rootkit 通过改系统调用 / 内核模块把进程从 /proc 抹掉。

1
2
3
4
5
6


# 安装
apt install unhide # Debian / Ubuntu
yum install unhide # CentOS

# 扫描隐藏进程
unhide proc

输出示例（节选）：

1
2
3
4
5
6
7
8


Found HIDDEN PID: 8627
 Cmdline: "<none>"
 Executable: "<no link>"

Found HIDDEN PID: 8631
 Cmdline: "/tmp/ntools"
 Executable: "/tmp/ntools (deleted)"
 Command: "ntools"

"<no link>" 加 (deleted) 几乎可以肯定是被替换的可执行文件。这种进程ps 看不到，但 unhide 跑遍 /proc 就能揪出来。

2.5 sysdig：高级武器

1
2
3
4
5


# 装
apt install sysdig # 或 yum install sysdig

# CPU Top
sysdig -c topprocs_cpu

输出形如：

1
2
3
4


CPU% Process PID
--------------------------------------------------------------------------------
1986.02% Discord 3225098
1800.44% f54e90d4 1806

1986.02% 出现在普通命令里几乎肯定是异常——单进程超过 100% 表示它多线程用了多核，但 Discord 一般不该这样。如果看到 f54e90d4 这种 8 位随机名字的可执行文件，就是挖矿木马。

定位 PID 后用下面这套"五连"：

1
2
3
4
5


cat /proc/1806/cmdline # 命令行（已抹掉的看不到）
which f54e90d4 # 找不到说明不在 PATH
find / -name f54e90d4 2>/dev/null
ls -l /proc/1806/exe # 真实可执行路径
cat /proc/1806/status # 进程状态、内存、权限

pwdx 1806 找进程工作目录：

1
2


root@host:~# pwdx 1806
1806: No such process # 进程可能已经"自删"

No such process 是典型的"恶意进程"——它在被查询的瞬间就已经退出了，只留下 /proc 里的残骸。

三、场景 2：磁盘清理与排查

1
2
3
4
5
6


# 看各目录占用
du -h -x --max-depth=1 /

# ncdu 交互式
apt install ncdu
ncdu / --exclude /home --exclude /nfs

ncdu 快捷键：

键	作用
`n`	按文件名排序
`s`	按大小排序
`r`	重新计算
`g`	显示百分比
`q`	退出

四、场景 3：SSH 登录用户异常

1
2
3
4
5


# 查看当前在线用户
who

# 踢掉某个用户
pkill -9 -t pts/2

注意 pkill -9 -t pts/2 会强杀该终端所有进程，包括用户正在跑的服务。生产环境慎用，最好先 wall 警告。

/var/log/auth.log 异常增长是被 SSH 暴力破解的信号：

1
2
3
4
5
6
7
8


# Ubuntu
tail -f /var/log/auth.log

# CentOS
tail -f /var/log/secure

# 文件超过 1M 多半是被打了
du -h /var/log/auth.log

应对：

改 SSH 端口
关闭密码登录，只允许密钥
装 fail2ban 自动封禁
内网机器直接禁外网 SSH

五、场景 4：挖矿病毒应急 SOP

本节基于实际处置过的案例整理，所有"客户信息"已脱敏。

5.1 症状

top 看到 f54e90d4、ntools、kthrotlds 等奇怪名字
CPU 长期 100%，但业务进程正常
/etc/cron.d/ 下出现随机名字的文件

5.2 排查流程

1
2
3
4
5
6
7
8


# 1. 找隐藏进程
unhide proc

# 2. 看可疑 crontab
crontab -l
cd /etc/cron.d
ls -l
cat /etc/cron.d/<可疑文件>

示例输出：

1
2
3


root@host:/etc/cron.d# ls -l
-rw-r--r-- 1 root root 201 Jan 8 2022 e2scrub_all
-rw-r--r-- 1 root root 35 Dec 10 2011 F6tfV3LP

F6tfV3LP 这种随机 8 位字母几乎肯定是恶意 cron。e2scrub_all 是 ext 文件系统自带工具，不要删。

1
2
3
4


# 看内容
cat F6tfV3LP
# */1 * * * * root /bin/WbeGGvQK 1 1
# 每分钟执行一次 /bin/WbeGGvQK（已删除的可执行）

5.3 清理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 1. 删二进制
rm -rf /bin/WbeGGvQK

# 2. 删 cron 文件
rm -rf /etc/cron.d/F6tfV3LP

# 3. 杀进程
pkill -9 -f WbeGGvQK
# 或按 PID
kill -9 <PID>

5.4 后续加固

改所有弱密码
关闭 SSH 密码登录
查 /etc/passwd 是否有可疑新用户
检查开机启动项：systemctl list-unit-files --state=enabled
重装系统（如果已经渗透很深）

经验上重装比清理快。挖矿病毒经常会留后门，清理成本远高于备份数据 → 重装 → 加固。

六、sysdig 进阶使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 查某个进程的系统调用
strace -p 1806

# 查网络连接最多的进程
sysdig -c topprocs_net

# 查写入文件最多的进程
sysdig -c topprocs_file

# 监听特定事件
sysdig evt.type=open and fd.name contains /tmp

更多 sysdig chisel（内置的分析命令）：

Chisel	用途
`topprocs_cpu`	CPU 占用 Top
`topprocs_net`	网络流量 Top
`topprocs_file`	读写文件 Top
`topfiles_bytes`	文件读写字节数 Top
`spy_users`	用户行为跟踪
`spy_ip`	IP 维度流量
`list_login_shells`	登录历史

七、SSH 日志监控

1
2
3
4
5


# Ubuntu
tail -f /var/log/auth.log

# CentOS
tail -f /var/log/secure

日志格式：

1

Jun 13 02:54 internal.example.com sshd[12345]: Accepted publickey for root from <攻击者IP> port <端口> ssh2

日志暴增多半是 SSH 暴力破解，可以装 fail2ban 自动封禁。

八、常见 5 个坑

unhide 报很多 Found HIDDEN：先看 Cmdline 和 Executable 两列，"<no link>" + (deleted) 才是真可疑；内核线程、kthreadd 的子进程是正常的。
pkill -9 -t pts/2 把自己踢下线：远程终端执行前确认 pts 号是自己的（who 第一行）。
crontab 里的"正常任务"删错：e2fsprogs 的 e2scrub_all 看起来像可疑脚本，是合法的——别删。
dd if=/dev/zero 把磁盘打满：of=/dev/null 不会写盘；of=/burn（不存在）会真的写满磁盘，小心。
入侵后只杀进程不清理 cron：挖矿病毒的核心是 cron 里的回连脚本，不删 cron 杀 100 次也会复活。

九、应急排查清单（建议收藏）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


[ ] top / htop 看 CPU
[ ] ps aux --sort=-%cpu | head
[ ] unhide proc 找隐藏进程
[ ] sysdig -c topprocs_cpu
[ ] who / w 查在线用户
[ ] cat /etc/passwd 查可疑账户
[ ] ls -l /etc/cron.d/ + cat 每个文件
[ ] crontab -l 查用户级定时任务
[ ] systemctl list-unit-files --state=enabled
[ ] last / lastb 查登录历史
[ ] /var/log/auth.log 查异常登录
[ ] iostat -d -x -k 1 查 IO
[ ] netstat -antp 查可疑连接
[ ] 备份数据后重装（最后手段）

十、总结

CPU 满先 top 看不见再 unhide，别忘了 sysdig 是终极武器。
挖矿病毒的根在 /etc/cron.d/ 随机名文件，不删 cron 杀 100 次也复活。
入侵后清理 = 找 → 杀 → 删 cron → 改密码 → 关密码登录 → 重装。
预防 > 应急：SSH 密钥 + fail2ban + 最小开放端口。

参考资料

MySQL 慢查询与性能调优：sysbench 压测 + buffer pool + 锁表排查

Tue, 15 Dec 2015 00:00:00 +0800

为什么写这篇：MySQL 性能问题有三个主要来源——慢 SQL、buffer pool 配置不合理、磁盘/网络瓶颈。本文把"怎么发现 → 怎么量化 → 怎么调"整理成可复用的流程，所有命令都带真实案例参数。

适用读者：做 MySQL 性能调优的运维 / DBA / 后端。

前置知识：了解 MySQL 基本架构、知道索引的作用。

1. 第一步：找到慢 SQL（慢查询日志）

1.1 查看是否开启

1
2
3


SHOW VARIABLES LIKE '%slow%';
SHOW STATUS LIKE '%slow%';
SHOW VARIABLES LIKE 'long_query_time';

输出字段含义：

变量	含义
`slow_query_log`	是否开启（默认 OFF）
`slow_query_log_file`	日志文件路径
`long_query_time`	慢查询阈值（秒，默认 10）

1.2 在线开启 + 配置文件

1
2
3
4
5
6
7


# /etc/my.cnf
[mysqld]
slow_query_log = on
slow_query_log_file = /data/f/mysql_slow_cw.log # Linux 用这个
# slow_query_log_file = <WAMP_INSTALL_DIR>/bin/mysql/mysql5.5.16/data/show-slow.log # Windows 必须绝对路径
long_query_time = 2 # 超过 2 秒算慢
log-queries-not-using-indexes # 没走索引的也记

Windows 注意：slow_query_log_file 必须写绝对路径（如 <WAMP_INSTALL_DIR>/...），相对路径在 Windows 下不工作。

修改后重启 MySQL 生效。

2. 第二步：mysqldumpslow 快速分析

mysqldumpslow 是 MySQL 自带的"五秒出报告"工具：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 访问最多的 10 条慢查询
mysqldumpslow -s c -t 10 /var/lib/mysql/huixuli2-slow.log

# 查询时间最慢的 3 条
mysqldumpslow -s t -t 3 /var/lib/mysql/huixuli2-slow.log

# 按时间排序前 10 条含 left join 的
mysqldumpslow -s t -t 10 -g "left join" /database/mysql/slow-log

# 扫描行数最多的
mysqldumpslow -s r -t 10 -g 'left join' /var/run/mysqld/mysqld-slow.log

参数说明：

参数	含义
`-s c`	按 count（执行次数）排序
`-s t`	按 time（耗时）排序
`-s r`	按 row（扫描行数）排序
`-s l`	按 lock time（锁等待）排序
`-t N`	取前 N 条
`-g PATTERN`	grep 过滤

3. 第三步：pt-query-digest 深度分析

pt-query-digest 是 Percona 出品的专业慢查询分析工具，能生成结构化报告（响应时间、占比、参数化指纹）。

3.1 安装

1
2
3
4
5
6
7


# Debian/Ubuntu
wget http://www.percona.com/get/pt-query-digest
chmod +x pt-query-digest

# 或整套 Percona Toolkit
wget percona.com/get/percona-toolkit.rpm
rpm -ivh percona-toolkit-2.2.13-1.noarch.rpm

重要：pt-query-digest 是个 Perl 脚本，所以系统得有 Perl 解释器（CentOS / Ubuntu 自带）。

3.2 关键参数

参数	含义
`--filter 'EXPR'`	按 Perl 表达式过滤事件
`--limit N` / `--limit N%`	输出前 N 条或 N% 占比
`--host / --user / --password`	连 MySQL 用
`--history`	把分析结果保存到 history 表（带时间窗对比）
`--review`	把分析结果保存到 review 表（更精简）
`--output report`	输出标准报告
`--since '12h'` / `--since 'YYYY-MM-DD'`	时间范围起点
`--until ...`	时间范围终点

3.3 11 个常用用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


# 1. 直接分析
pt-query-digest slow.log > slow_report.log

# 2. 最近 12 小时
pt-query-digest --since=12h slow.log > report.log

# 3. 指定时间范围
pt-query-digest slow.log \
 --since '2014-05-17 09:30:00' \
 --until '2014-06-17 10:00:00' > report.log

# 4. 只分析 SELECT
pt-query-digest --filter '$event->{fingerprint} =~ m/^select/i' slow.log

# 5. 只看 root 用户的
pt-query-digest --filter '($event->{user} || "") =~ m/^root/i' slow.log

# 6. 全表扫描/全 join 的
pt-query-digest --filter \
 '(($event->{Full_scan} || "") eq "yes") || (($event->{Full_join} || "") eq "yes")' \
 slow.log

# 7. 结果存到 review 表（自动建表）
pt-query-digest --user=root --password=*** \
 --review h=localhost,D=test,t=query_review --create-review-table \
 slow.log

# 8. 历史表（带时间窗）
pt-query-digest --user=root --password=*** \
 --review h=localhost,D=test,t=query_history --create-history-table \
 slow.log_20140401

# 9. 通过 tcpdump 抓 MySQL 协议再分析
tcpdump -s 65535 -x -nn -q -tttt -i any -c 1000 port 3306 > mysql.tcp.txt
pt-query-digest --type tcpdump mysql.tcp.txt

# 10. 分析 binlog
mysqlbinlog mysql-bin.000093 > mysql-bin000093.sql
pt-query-digest --type=binlog mysql-bin000093.sql

# 11. 分析 general log
pt-query-digest --type=genlog localhost.log

报告重点看 Rank（响应时间排序）、Response time（响应时间分布）、Callers（调用方）、SQL fingerprint 这几栏。

4. 第四步：buffer pool 参数调优

InnoDB 缓冲池是 MySQL 性能最关键的配置——读请求 99%+ 应该走 buffer pool，而不是磁盘。

4.1 三个核心参数

1
2
3
4
5


# /etc/my.cnf
[mysqld]
innodb_buffer_pool_size = 8G # 缓冲池总大小
innodb_buffer_pool_instances = 4 # 缓冲池实例数
innodb_buffer_pool_chunk_size = 1024M # 调整块大小

参数	推荐值	限制
`innodb_buffer_pool_size`	物理内存的 50%~80%	最大 64 TB
`innodb_buffer_pool_instances`	CPU 核心数的 1~2 倍	最大 64
`innodb_buffer_pool_chunk_size`	1024M（默认 128M）	chunk × instance ≤ pool_size

4.2 配置铁律

1

innodb_buffer_pool_size = innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances × N

如果你设的 size 不是 chunk × instance 的整数倍，MySQL 会自动调整到最近的合法值。设之前先在心里算清楚。

案例：16G 内存 8 核服务器

1
2
3
4
5
6
7


# 配置
innodb_buffer_pool_size = 8G
innodb_buffer_pool_chunk_size = 1024M
innodb_buffer_pool_instances = 4

# 验证（在线改）
SET GLOBAL innodb_buffer_pool_size = 8589934592; # 8G = 8*1024*1024*1024

4.3 评估命中率

1
2
3
4
5
6
7
8


-- 读取请求命中率（目标 ≥ 99%）
SELECT
 100 * (1 - (variable_value / (SELECT variable_value
 FROM performance_schema.global_status
 WHERE variable_name = 'Innodb_buffer_pool_read_requests')))
 AS hit_ratio
FROM performance_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_reads';

或者用 status 命令：

1
2
3
4


SHOW STATUS LIKE 'innodb_buffer_pool_read%';
# Innodb_buffer_pool_read_requests: 54329170948
# Innodb_buffer_pool_reads: 4890414994
# 命中率 = 1 - 4890414994/54329170948 ≈ 91.7% （不达标，加大 buffer pool）

目标：命中率 ≥ 99%。如果 95% 以下说明 buffer pool 配置严重不足。

5. 第五步：sysbench 基准测试

5.1 sysbench 安装

1
2
3
4
5
6
7


# Debian/Ubuntu
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
sudo apt -y install sysbench

# 验证
sysbench --version
# sysbench 1.0.20

5.2 4 步标准流程

① prepare（生成压测数据）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 默认通过 INSERT INTO 导数；指定 --db-ps-mode=disable 还能用 LOAD DATA LOCAL INFILE 提速 30%
sysbench oltp_read_write \
 --mysql-host=10.0.0.10 \
 --mysql-port=3306 \
 --mysql-user=root \
 --mysql-password='{{REDACTED}}' \
 --mysql-db=sbtest \
 --table-size=1000000 \
 --tables=10 \
 --threads=32 \
 --events=999999999 \
 --report-interval \
 prepare

--table-size=1000000 --tables=10 → 10 张 100 万行表，共 1000 万行。OLTP 场景要"像生产"才有意义。

② prewarm（把数据预热到内存）

1
2
3
4
5
6


sysbench oltp_read_write \
 --mysql-host=10.0.0.10 \
 --mysql-db=sbtest \
 --tables=10 --table-size=1000000 \
 --threads=32 \
 prewarm

③ run（开始压测）

1
2
3
4
5
6
7
8


sysbench oltp_read_write \
 --mysql-host=10.0.0.10 \
 --mysql-db=sbtest \
 --tables=10 --table-size=1000000 \
 --threads=64 \
 --time=60 \
 --report-interval=10 \
 run

④ cleanup（清理压测数据）

1
2
3
4
5


sysbench oltp_read_write \
 --mysql-host=10.0.0.10 \
 --mysql-db=sbtest \
 --tables=10 \
 cleanup

5.3 报告解读（3 个核心指标）

1

[ 60s ] thds: 64 tps: 5028.08 qps: 100641.26 (r/w/o: 70457.59/20121.51/10062.16) lat (ms,95%): 17.32 err/s: 0.00 reconn/s: 0.00

指标	含义	期望
tps	每秒事务数	越大越好
qps	每秒操作数（r+w+o）	越大越好
lat (ms, 95%)	95% 事务的执行耗时（毫秒）	越小越好
err/s	每秒错误数	应为 0

完整报告示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


SQL statistics:
 queries performed:
 read: 4276622
 write: 1221892
 other: 610946
 total: 6109460
 transactions: 305473 (5088.63 per sec.)
 queries: 6109460 (101772.64 per sec.)

Latency (ms):
 min: 5.81
 avg: 12.57
 max: 228.87
 95th percentile: 17.32
 sum: 3840044.28

Threads fairness:
 events (avg/stddev): 4773.0156/30.77
 execution time (avg/stddev): 60.0007/0.01

公平性（Threads fairness） 的 stddev 越小越好——如果某个线程的 stddev 远大于其他，说明有锁竞争或热点。

5.4 真实环境对比案例

主机	部署方式	硬盘	oltp_read_write TPS	oltp_point_select QPS
工控机 A	k8s + Ceph 块存储	固态	365.23	74017
工控机 B	k8s + Ceph 文件存储	固态	529.12	85793
工控机 C	k8s + NFS	固态	155.25	45935
服务器	docker	机械	649.67	110000
工控机 D	docker	固态	567.35	190000
工控机 E	二进制	固态	259.30	180000

关键发现：纯随机点查（oltp_point_select）受磁盘影响小，受 buffer pool 影响大；读写混合（oltp_read_write）则受磁盘 IO 显著影响。SSD > 机械盘是确定收益。

5.5 其他场景

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# CPU 性能
sysbench cpu --cpu-max-prime=20000 --threads=32 run
# 看 events per second

# 内存吞吐（推荐 1MB 块大小）
sysbench memory --memory-block-size=1M --memory-total-size=100G --num-threads=1 run
# 看 MiB/sec

# 磁盘 IO
sysbench fileio --file-num=1 --file-total-size=10G --file-test-mode=rndrw prepare
sysbench fileio --file-num=1 --file-total-size=10G --file-test-mode=rndrw run
sysbench fileio --file-num=1 --file-total-size=10G --file-test-mode=rndrw cleanup
# 看 IOPS（reads/s + writes/s）和吞吐量（read MiB/s + written MiB/s）

6. 实战：kill 阻塞连接 / 锁表排查

6.1 查锁表

1
2
3
4
5


-- 哪些表被锁住
SHOW OPEN TABLES WHERE In_use > 0;

-- 当前所有 InnoDB 事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

6.2 一键 kill 所有阻塞 trx

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 拼接成 KILL 命令，复制出来执行
SELECT
 GROUP_CONCAT(CONCAT('KILL ', trx_mysql_thread_id) SEPARATOR '; ') AS cmd
FROM INFORMATION_SCHEMA.INNODB_TRX;

-- 不 kill 自己的版本
SELECT
 GROUP_CONCAT(CONCAT('KILL IF EXISTS ', id) SEPARATOR '; ') AS kill_commands
FROM information_schema.PROCESSLIST
WHERE HOST LIKE '%example.telus.net%'
 AND id != CONNECTION_ID();

6.3 sleep 连接专项清理

应用层数据库连接池配置不当，大量 sleep 连接堆积：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 查 sleep 连接的客户端 IP
SELECT substring_index(host, ':', 1) AS client_ip, Command, Time
FROM information_schema.processlist;

-- 批量 kill 指定用户的 sleep 连接
SELECT
 GROUP_CONCAT(CONCAT('kill ', id) SEPARATOR '; ') AS cmd
FROM information_schema.PROCESSLIST
WHERE USER = 'app_user'
 AND command = 'Sleep'
 AND db = 'app_db';

7. 实战：wait_timeout 与连接池调优

7.1 现象：连接超时

应用日志抛：

1
2
3


The last packet successfully received from the server was 120,935 milliseconds ago.
The last packet sent successfully to the server was 381,491 milliseconds ago.
is longer than the server configured value of 'wait_timeout'.

7.2 修法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 查看当前超时
SHOW VARIABLES LIKE '%timeout%';

-- 在线调大
SET GLOBAL wait_timeout = 31536000;
SET GLOBAL interactive_timeout = 31536000;

-- 持久化（/etc/my.cnf）
[mysqld]
wait_timeout = 31536000
interactive_timeout = 31536000

wait_timeout 8 小时 = 28800 秒是默认值。如果你的应用有连接池（推荐！），设大些无所谓；如果没用连接池且应用端有长空闲期，应同时配合连接池侧的心跳（testOnBorrow / testWhileIdle）。

7.3 mysqldump 备份时数据库卡死

1

导出数据库，出现 SELECT /*!40001 SQL_NO_CACHE */ * FROM ，数据库卡死

原因：导出时大表加锁 + 缓存爆炸。

修法：

1
2
3
4
5
6
7


docker exec mysql /usr/bin/mysqldump \
 -u root -p'{{REDACTED}}' \
 --single-transaction \
 --quick \
 hxl_industry_iot_dev \
 --ignore-table=hxl_industry_iot_dev.hxl_location_historydata \
 > backup.sql

参数	作用
`--single-transaction`	用一致快照导出（仅 InnoDB）
`--quick`	一行一行从服务器取，不缓存到内存
`--ignore-table`	跳过不需要的表（如历史数据）

下一步

EXPLAIN 字段全解读：见《MySQL 实战速查》
索引优化案例：见《MySQL 索引优化实战》
备份恢复：见《MySQL 备份恢复实战》

2024+ 视角：MySQL 8.4/9.0 的性能调优新维度

Performance Schema 8.0+ 高级用法

performance_schema 在 8.4 LTS 起默认开启更多事件，比 slow_query_log 更细粒度：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-- 1. 找出"扫了最多行"的 SQL
SELECT
 digest_text,
 count_star AS exec_count,
 sum_rows_examined AS total_examined,
 sum_rows_sent AS total_sent,
 sum_timer_wait/1000000000 AS total_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_rows_examined DESC
LIMIT 10;

-- 2. 找出"全表扫描次数最多"的表
SELECT object_name, count_read, count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE count_read > 0
ORDER BY count_read DESC
LIMIT 10;

sys schema 1.x → 2.x（8.4+ 升级）

sys schema 是 Performance Schema 的"友好封装"，8.4 起全面升级：

1
2
3
4
5
6
7


-- sys.statements_with_full_table_scans
SELECT query, db, exec_count, total_latency
FROM sys.statements_with_full_table_scans
LIMIT 10;

-- sys.schema_redundant_indexes（推荐清理冗余索引）
SELECT * FROM sys.schema_redundant_indexes;

MySQL 8.0+ 的 `EXPLAIN ANALYZE`

1
2
3


EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = 123 AND created_at > '2024-01-01';

输出包含 实际执行时间（不再是"估算"）——比传统 EXPLAIN 精准一个量级。

InnoDB Buffer Pool 8.0+ 新参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[mysqld]
# 8.0.30+ 用容量单位（替代 innodb_log_file_size）
innodb_redo_log_capacity = 8G

# 8.0+ 自适应刷新（默认 on）
innodb_adaptive_flushing = ON
innodb_adaptive_flushing_lwm = 10

# 8.0+ 多线程刷新
innodb_page_cleaners = 4
innodb_cleaner_lsn_age_factor = high

资源组（Resource Group）8.0+

1
2
3
4
5
6
7
8


-- 创建资源组（绑定 CPU 核）
CREATE RESOURCE GROUP batch_group
 TYPE = USER
 VCPU = 2-3 -- 绑到 CPU 2、3 号核
 THREAD_PRIORITY = 10;

-- 给会话分配
SET RESOURCE GROUP batch_group;

典型场景：把报表/批处理绑到非关键 CPU 核，避免影响在线交易。

sysbench 1.0 → 1.0.20+ 的 OLTP 场景

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 2024+ 推荐用 lua 脚本（自定义场景更灵活）
sysbench \
 --db-driver=mysql \
 --mysql-host=10.0.0.10 \
 --mysql-db=sbtest \
 --oltp-table-size=1000000 \
 --oltp-tables-count=10 \
 --threads=64 \
 --time=120 \
 --report-interval=10 \
 oltp_read_write \
 prepare

# 报告解读：加关注 P99 延迟
# [ 120s ] thds: 64 tps: 5028.08 qps: 100641.26
# lat (ms,99%): 23.5 ← 99% 延迟（生产更应看这个）

2024+ 慢查询工具链

工具	状态	替代
`mysqldumpslow`	仍可用	适合 5.7/8.0 简单场景
`pt-query-digest`	2023 起归档不再维护	用 `mysql-slow-log-parser` / `sqlparse` + 自定义分析
`mydumper`	活跃	替代 mysqldump + 多线程导出
MySQL Enterprise Monitor	商业	高级告警 + 自动索引建议
Yearning / Archery	开源 SQL 审核平台	包含慢查询归集

2024+ 调优的"AI 加持"

MySQL HeatWave AutoML（Oracle 云）：自动识别热点查询并推荐索引
Yearning/Archery + LLM：自然语言问"今天哪些 SQL 慢"
Percona Monitoring and Management (PMM) 2.x：内置 Query Analytics + AI 异常检测

2024+ 实战建议

优先用 Performance Schema 替代 slow log——粒度更细、对生产影响更小
升 8.4 LTS 必看：MySQL 8.4 默认关闭 query_cache，相关参数都移除
9.0 升级注意：caching_sha2_password 已是唯一支持，JDBC 8.x+ 才兼容
生产压测：用 sysbench 1.0.20 + 真实业务流量回放，别再靠"拍脑袋"

经验补记

MySQL 9.0 起的"JavaScript 存储程序"——是的，现在可以在 MySQL 里写 JS 函数了，但仅适合 OLTP 边缘场景
SHOW PROFILE 在 8.0.26 起被弃用，统一用 performance_schema 替代