数据库教程FGMT42‑MySQL性能优化之操作系统性能诊断

前言

风哥教程本文聚焦MySQL数据库操作系统层面性能诊断技术。在数据库运维调优实践中，多数DBA习惯优先调整MySQL内部参数、优化SQL语句，却常常忽略操作系统层面对数据库服务的底层约束。MySQL实例运行于Linux操作系统之上，CPU调度策略、内存回收机制、IO堆栈行为、网络协议栈、系统资源限制，都会直接决定数据库服务的性能上限；即便MySQL内部参数配置完全合理，操作系统存在缺陷配置、硬件资源出现瓶颈，业务依旧会出现响应延迟升高、TPS抖动、偶发卡顿等各类异常现象。

本套风哥教程面向数据库工程师、DBA、IT运维人员、云计算工程师、后端开发人员，以两台标准化主机fgedu‑net‑cn1、fgedu‑net‑cn2作为实操环境，硬件规格统一为64G物理内存，8物理CPU核心；数据库环境对半覆盖MySQL8.4 LTS与MySQL9.7版本；数据目录统一使用/fgedudb，数据库实例名、库名、用户名统一使用fgedudb、fgedudb、fgedu。风哥教程本文会完整讲解操作系统性能诊断的基础理论、核心工具集、完整排查流程、内核参数调优、故障复现与定位实战案例，打通从硬件、操作系统内核到MySQL数据库实例的完整分析链路，帮助从业者建立“先操作系统，后数据库”的标准化性能排查思路。风哥 itpux‑com

风哥教程本文内容大纲

操作系统性能诊断基础理论：数据库与操作系统协同原理；四大资源维度CPU、内存、磁盘IO、网络的性能瓶颈判定逻辑；MySQL8.4与MySQL9.7在操作系统交互层面的差异点；性能指标阈值与基线建立方法论。
Linux操作系统性能诊断工具集原理：sysstat工具家族vmstat、sar、mpstat、iostat、pidstat；进程线程分析工具top、htop、ps、pstree；性能采样工具perf；内存分析工具free、pmap、numactl；网络诊断工具ss、tcpdump。讲解每一个工具的底层原理，区分全局统计、进程级统计、线程级统计、硬件函数级统计的适用场景。
实战环境准备：fgedu‑net‑cn1（MySQL8.4）与fgedu‑net‑cn2（MySQL9.7）环境初始化、依赖包安装、操作系统基线采集脚本编写。
CPU性能瓶颈完整实战排查：模拟CPU高负载故障，从全局指标定位，到进程、线程，再到内核函数热点，联动MySQL内部performance_schema定位SQL根源，完整复现排障全流程。
内存子系统性能实战诊断：swap抖动故障、透明大页THP问题、NUMA内存分配异常、脏页回写内核参数问题；包含现象复现、指标识别、参数调整、效果验证全套操作命令。>

风哥教程 113257174

磁盘IO性能实战诊断：IO等待iowait升高、IOPS打满、磁盘await延迟过高故障；文件系统挂载参数调优，区分MySQL8.4、MySQL9.7的IO行为差异；交换分区、脏页参数实战调整。
网络子系统性能实战诊断：数据库连接抖动、TCP重传、半连接队列溢出问题；内核网络参数调优，ss命令定位数据库连接异常。
系统资源限制故障实战：ulimit资源限制、文件句柄数、进程最大线程数导致MySQL异常现象定位与修复。
操作系统基线巡检脚本开发实战，自动输出风险项。
风哥针对本文总结：故障排查流程复盘，8.4与9.7版本调优差异汇总，生产环境风险提示。

本套风哥教程内容占比分配：前言与大纲占整体篇幅5%；理论原理部分占全文30%；实战操作步骤、命令输出、故障模拟与验证占全文60%；收尾总结占全文5%。

一、操作系统性能诊断基础理论

1.1 MySQL与Linux操作系统协同底层原理

MySQL进程mysqld属于用户态应用程序，所有资源请求最终全部交由Linux内核完成。mysqld进程申请内存、发起磁盘读写、调度线程CPU时间片、建立TCP网络连接，全部经过系统调用陷入内核空间完成处理。很多性能故障表象发生在MySQL业务侧，根因却存在于操作系统内核。例如业务慢查询持续增加，排查发现并非索引缺失，而是操作系统swap频繁换入换出，InnoDB缓冲池页面被置换到磁盘，引发大量物理IO。

MySQL8.4 LTS为长期支持版本，默认开启performance_schema，InnoDB默认使用O_DIRECT IO模式绕过操作系统文件缓存；innodb_io_capacity默认提升至10000，适配SSD存储；自适应哈希索引AHI默认关闭，降低高并发下互斥锁竞争。MySQL9.7继承8.4的redo log全新架构，innodb_redo_log_capacity替代旧版本的innodb_log_file_size参数，redo日志实现动态扩容，对操作系统脏页回写、IO调度的行为进一步改变，9.7版本线程调度模型也有小幅优化，高并发场景下系统态CPU占比会与8.4版本存在差异。

风哥数据库教程 itpux‑com

对于64G内存、8CPU主机的专用MySQL数据库服务器，操作系统与数据库的资源分配基础原则：内存资源优先保障InnoDB缓冲池，预留足够内存给操作系统page cache，严格控制swap的使用；CPU层面减少不必要内核态开销，降低上下文切换；IO层面避免文件系统双缓冲；网络调大TCP相关队列参数，适配数据库大量短连接、长连接混合业务场景。

1.2四大核心资源维度性能瓶颈判定理论

1.2.1 CPU子系统理论

CPU资源核心观测维度：用户态CPU占比%user、内核态%system、iowait IO等待占比%iowait、空闲%idle；运行队列r（等待CPU调度的任务数量）；上下文切换cs；中断次数。

运行队列r的基线判定规则：8CPU主机，r持续大于等于16，代表出现CPU计算瓶颈。区分两种CPU瓶颈：第一种用户态CPU高，绝大多数场景由业务SQL大量运算、全表扫描、排序、分组聚合引发；第二种内核态CPU高，由频繁上下文切换、系统调用、锁竞争、NUMA不均衡分配、中断风暴引发。iowait高不代表CPU算力不足，代表CPU大量时间在等待磁盘IO完成，瓶颈实际在存储子系统。

1.2.2内存子系统理论

Linux内存管理机制包含物理内存、page cache页缓存、swap交换分区、透明大页THP、脏页回写机制。数据库服务器最致命的内存故障是swap抖动：si（swap‑in）、so（swap‑out）持续大于0，mysqld进程的内存被置换到磁盘，会造成实例剧烈性能抖动，TPS骤降，延迟飙升。

网上搜索风哥教程可以学习全套数据库教程

vm.swappiness内核参数控制内核倾向使用swap的程度；vm.dirty_background_ratio、vm.dirty_ratio控制系统脏页占内存阈值，脏页达到阈值内核触发回写磁盘。透明大页THP的自动压缩、内存合并操作会带来随机 latency毛刺，生产数据库服务器强烈建议关闭THP。NUMA架构下，如果mysqld进程内存只分配在单个NUMA节点，会出现局部内存耗尽，剩余节点内存空闲，触发swap，即便整机物理内存还有大量空闲，这是物理机数据库常见隐蔽故障。

针对64G内存主机部署MySQL，InnoDB缓冲池一般设置48G，预留10‑12G内存供操作系统page cache、内核、其他后台进程使用，严禁将全部内存分配给数据库缓冲池。MySQL8.4与MySQL9.7对大页支持良好，可以配置静态hugepage，提升内存访问效率，规避THP缺陷。

1.2.3磁盘IO子系统理论

磁盘IO核心指标：IOPS、读写吞吐量rMB/s wMB/s，await单次IO平均等待时间，svctm服务时间，%util磁盘设备繁忙度。await包含IO排队时间与设备实际处理时间，SSD数据库盘正常OLTP业务场景，await建议小于5ms；机械硬盘HDD await建议小于20ms。%util接近100%代表磁盘设备已经打满，新IO请求进入队列排队等待。

MySQL8.4默认O_DIRECT模式，InnoDB数据文件读写绕过操作系统page cache，redo日志依旧使用fsync；MySQL9.7 redo日志动态管理，脏页刷盘逻辑优化，会改变IO请求的频率与大小。文件系统挂载参数noatime关闭访问时间更新，减少额外写IO；xfs文件系统是MySQL生产首选。

1.2.4网络子系统理论

数据库服务大量TCP连接，半连接队列、全连接队列溢出会出现偶发连接失败；TCP重传率升高带来访问延迟。核心观测指标：ss查看连接状态ESTABLISHED、TIME‑WAIT、SYN；netstat/ss的重传计数器。内核参数net.core.somaxconn、net.ipv4.tcp_sync_queue控制连接队列大小。高并发业务数据库服务器TIME‑WAIT数量巨大，需要合理调整tcp_tw_reuse等参数。

上51CTO搜索风哥可以学习全套数据库教程

1.3性能基线建立方法论

性能诊断不能依靠单一采样点数值判断瓶颈，需要建立业务正常运行时的操作系统基线。基线采集包含业务高峰、业务低峰两套样本，记录CPU、内存、IO、网络正常区间。当故障发生，对比基线指标，识别异常偏移，这是标准化排查的基础。单次命令输出的瞬时值参考意义有限，需要连续采样观察指标持续变化趋势。

1.4 MySQL8.4与MySQL9.7操作系统交互关键差异理论

redo日志架构：MySQL8.4使用innodb_redo_log_capacity参数；MySQL9.7完全继承动态redo log，运行期间redo文件大小自动伸缩，脏页回写对操作系统压力模式发生变化，不再需要手动设置多个固定大小redo文件。
IO默认行为：两者Linux平台默认开启O_DIRECT，绕过操作系统缓存，减少双拷贝开销。
内存模型：MySQL9.7优化内部线程内存分配，高并发场景系统态CPU占比相比8.4略有改善；9.7对NUMA感知增强。
performance_schema：MySQL9.7新增部分操作系统层面等待事件，更容易定位线程等待操作系统资源场景。

二、Linux操作系统性能诊断工具集原理

2.1 sysstat工具家族原理

sysstat是Linux生产环境必备工具包，包含vmstat、sar、mpstat、iostat、pidstat，所有工具读取/proc虚拟文件系统内核统计计数器，做数据聚合输出。

vmstat：整机全局统计，CPU、内存swap、IO块设备、上下文切换、中断，反映整机宏观状态，无法区分单个进程数据。
sar：历史数据采集，周期性保存系统性能快照，可以回溯历史故障时刻指标；同时支持实时采样。系统默认通过cron任务生成sa*历史日志文件。
mpstat：多CPU细分统计，可以查看每一颗CPU核心独立使用率，定位单颗CPU打满的“CPU孤岛”故障。
iostat：块设备磁盘IO统计，输出每个磁盘分区IOPS、吞吐量、await、%util指标。
pidstat：进程与线程级资源统计，可以针对指定PID输出CPU、内存、IO、上下文切换统计，是数据库DBA最高频工具，打通整机指标到mysqld进程的桥梁。

2.2进程线程分析工具原理

top/htop：实时进程视图；top‑H可以展开进程内部所有线程，MySQL mysqld内部有大量后台线程、用户工作线程，可以直接看到哪一条线程消耗CPU资源。
ps、pstree：静态快照，查看进程树，确认mysqld启动参数、线程数量。

2.3 perf性能采样工具原理

perf是Linux内核内置性能剖析工具，基于硬件PMU性能计数器，采样进程运行时内核与用户态函数调用栈。当mysqld进程CPU高，慢查询日志却没有记录慢SQL，此时perf top可以直接定位消耗CPU的底层函数，区分是InnoDB锁自旋、内存拷贝、内核系统调用还是SQL运算逻辑消耗CPU。perf record录制一段时间采样数据，perf report生成分析报告，还可以输出火焰图辅助可视化分析。

2.4内存分析工具

free读取/proc/meminfo展示整机内存；pmap‑x PID输出进程完整虚拟地址空间映射，查看mysqld各个段内存占用；numactl‑‑hardware查看NUMA节点拓扑，numactl‑‑stat PID查看进程跨NUMA节点内存分配统计。

2.5网络诊断工具

ss替代老旧netstat，速度更快，查看TCP套接字连接状态；tcpdump抓取数据库端口网络报文，定位网络延迟、丢包、重传。

三、实战环境准备（fgedu‑net‑cn1 MySQL8.4；fgedu‑net‑cn2 MySQL9.7）

两台主机硬件规格均：8CPU、64G内存；数据目录/fgedudb，实例、库、用户名fgedudb、fgedudb、fgedu。

3.1安装依赖工具包

fgedu‑net‑cn1（MySQL8.4主机，root执行）

# RHEL/CentOS系列
yum install -y sysstat perf numactl pmap htop tcpdump ss
# Debian/Ubuntu
# apt install -y sysstat linux-tools-common linux-tools-generic numactl htop iproute2 tcpdump
# 设置sysstat历史采集开启
sed -i 's|ENABLED="false"|ENABLED="true"|g' /etc/sysconfig/sysstat
systemctl restart sysstat

fgedu‑net‑cn2（MySQL9.7主机，root执行）

yum install -y sysstat perf numactl pmap htop tcpdump ss
sed -i 's|ENABLED="false"|ENABLED="true"|g' /etc/sysconfig/sysstat
systemctl restart sysstat

3.2确认数据库实例基础配置

MySQL8.4实例fgedudb，配置文件/fgedudb/myfgedudb84.cnf关键片段：

[mysqld]
datadir=/fgedudb/data
socket=/fgedudb/mysql.sock
pid‑file=/fgedudb/fgedudb.pid
user=fgedu
innodb_buffer_pool_size=48G
innodb_redo_log_capacity=4G
performance_schema=ON

MySQL9.7实例fgedudb，配置文件/fgedudb/myfgedudb97.cnf关键片段：

[mysqld]
datadir=/fgedudb/data
socket=/fgedudb/mysql.sock
pid‑file=/fgedudb/fgedudb.pid
user=fgedu
innodb_buffer_pool_size=48G
innodb_redo_log_capacity=4G
performance_schema=ON

3.3编写操作系统基线采集脚本 baseline_collect.sh

#!/bin/bash
#风哥教程基线采集脚本，输出文件保存至/fgedudb/baseline/
mkdir -p /fgedudb/baseline
DATE=$(date +%Y%m%d_%H%M%S)
vmstat 1 3 > /fgedudb/baseline/vmstat_${DATE}.log
sar -u 1 3 > /fgedudb/baseline/sar_cpu_${DATE}.log
iostat -x 1 3 > /fgedudb/baseline/iostat_${DATE}.log
pidstat -t -p $(pidof mysqld) 1 3 > /fgedudb/baseline/pidstat_mysqld_${DATE}.log
free -h > /fgedudb/baseline/free_${DATE}.log
numactl --hardware > /fgedudb/baseline/numa_${DATE}.log
ss -s > /fgedudb/baseline/ss_net_${DATE}.log
echo "baseline collect finish ${DATE}"

脚本赋予执行权限：

chmod +x baseline_collect.sh
./baseline_collect.sh

执行完成，在/fgedudb/baseline目录生成全套基线样本，故障时再次执行脚本，对比两份日志差异，定位异常指标。

四、CPU性能瓶颈完整实战排查

4.1故障模拟（在fgedu‑net‑cn1 MySQL8.4主机）

登录数据库fgedudb，执行大量无索引全表扫描SQL，制造用户态CPU压力。

mysql -S /fgedudb/mysql.sock -u fgedu -p fgedudb

--模拟全表扫描压力
SELECT * FROM big_table WHERE create_time > '2024‑01‑01';
--并发多会话反复执行，拉高mysqld进程CPU占用

4.2实战步骤1：整机vmstat全局指标观测

新开操作系统终端root执行：

vmstat -n 2 10

输出关键字段解读：r运行队列，us用户态CPU，sy内核态CPU，id空闲，cs上下文切换。故障场景可以看到us持续75‑85%，r运行队列数值大于8核CPU基线阈值16。

4.3实战步骤2：sar+mpstat确认CPU是否单核心打满

#全部CPU统计
sar -u 2 8
#每颗CPU独立输出
mpstat -P ALL 2 8

如果mpstat输出中某一个CPU核心%idle接近0，其余核心空闲，即为单CPU热点故障；8.4、9.7版本在锁自旋场景容易出现单CPU被打满。

4.4实战步骤3：pidstat定位mysqld进程CPU消耗

获取mysqld PID：

pidof mysqld

假设PID=21345

pidstat -t -p 21345 2 10

‑t参数输出线程维度统计，可以看到mysqld内部各个线程的%usr、%system。找到CPU占比最高线程TID。

4.5实战步骤4 top‑H查看操作系统线程ID

top -H -p 21345

记录高负载操作系统线程TID，十进制数字，转换为十六进制，用于MySQL内部performance_schema匹配线程。

printf "%x\n 线程TID"

登录MySQL8.4实例，用十六进制OS‑THREAD‑ID查询performance_schema.threads，定位该线程对应数据库会话：

SELECT THREAD_ID,OS_THREAD_ID,PROCESSLIST_ID,PROCESSLIST_INFO
FROM performance_schema.threads
WHERE OS_THREAD_ID=0x十六进制值;

通过PROCESSLIST_ID找到对应的业务SQL，确认是全表扫描导致CPU压力。

4.6实战步骤5 perf工具定位底层函数热点（无慢查询但CPU高场景）

MySQL9.7主机fgedu‑net‑cn2场景，故障现象CPU持续高，但慢查询日志没有捕获慢SQL，使用perf采样mysqld进程PID=18762：

#实时查看热点函数
perf top -p 18762
#录制30秒采样
perf record -g -p 18762 sleep 30
perf report

观察热点函数：如果是ut_spin_loop，代表InnoDB互斥锁自旋消耗CPU；如果是内核函数代表系统调用开销大；如果是sql解析执行函数代表业务SQL运算消耗CPU。

4.7故障验证与恢复

给big_table增加索引消除全表扫描：

CREATE INDEX idx_bigtable_createtime ON big_table(create_time);

再次运行./baseline_collect.sh采集指标，观察vmstat、pidstat，用户态CPU下降，运行队列r回归基线。

五、内存子系统性能实战诊断

5.1场景一：swap抖动故障实战（fgedu‑net‑cn2 MySQL9.7）

故障现象：业务TPS剧烈抖动，数据库延迟忽高忽低，MySQL内部没有锁等待，慢查询数量随机增加。

步骤1整机内存与swap观测

free -h
vmstat 2 10

观察si、swap‑in；so swap‑out持续不为0，代表swap抖动，即便整机free内存看起来还有剩余。

步骤2确认NUMA分配状态

numactl --hardware
numactl --pid $(pidof mysqld)

故障案例：整机64G内存空闲20G，但是mysqld进程所在NUMA节点内存耗尽，内核触发swap，其他NUMA节点内存闲置。

临时修复方案：运行时关闭NUMA平衡；永久配置grub内核参数numa=off；或者启动mysqld绑定NUMA节点。

echo 0 > /proc/sys/kernel/numa_balancing

步骤3调整vm.swappiness参数，数据库服务器推荐设置1

#临时生效
sysctl -w vm.swappiness=1
#永久写入/etc/sysctl.conf
echo "vm.swappiness=1" >> /etc/sysctl.conf
sysctl -p

5.2场景二：透明大页THP故障实战（MySQL8.4 fgedu‑net‑cn1）

THP自动内存合并压缩会带来随机延迟毛刺。检查THP状态：

cat /sys/kernel/mm/transparent_hugepage/enabled

输出[always]代表开启，需要关闭。临时关闭：

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

永久关闭，修改grub，内核参数增加transparent_hugepage=never，重启主机生效。

风哥 itpux‑com

5.3脏页内核参数调优实战，适配64G内存数据库主机

编辑/etc/sysctl.conf

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500

加载生效

sysctl -p

说明：MySQL8.4、MySQL9.7开启O_DIRECT时，数据文件脏页不受vm脏页参数控制；redo日志文件依旧受操作系统脏页机制影响。

5.4 pmap查看mysqld进程内存分布

pmap -x $(pidof mysqld) | more

观测RSS、Dirty内存大小，确认缓冲池内存正常分配，确认没有异常内存泄漏持续上涨。

六、磁盘IO性能实战诊断

6.1故障现象：业务大量慢查询，CPU iowait指标升高

主机fgedu‑net‑cn2 MySQL9.7，业务写压力增大，磁盘await持续大于20ms，%util接近100%。

步骤1 iostat‑x观测磁盘设备指标

iostat -x -d 2 10

重点列：r/s w/s IOPS；rkB/s wkB/s吞吐量；r_await w_await单次IO等待；%util磁盘繁忙度。

如果%util接近100%，await很高，IOPS已经达到磁盘硬件上限，存储硬件瓶颈。

步骤2 pidstat查看mysqld进程磁盘IO统计

pidstat -d -t -p $(pidof mysqld) 2 8

pidstat‑d输出进程读、写磁盘KB/s，确认IO压力来源确实是mysqld进程。

6.2文件系统挂载参数检查与优化

查看挂载信息：

mount

MySQL数据目录/fgedudb所在xfs分区优化挂载参数：rw,noatime,nodiratime，关闭atime访问时间更新，消除大量不必要写IO。修改/etc/fstab，重新挂载。

mount -o remount,noatime,nodiratime /fgedudb

风哥教程 113257174

6.3区分MySQL8.4与MySQL9.7 IO行为

MySQL8.4：innodb_flush_method=O_DIRECT；数据文件绕过page cache；redo日志使用fsync。 MySQL9.7：继承O_DIRECT，redo日志动态扩容，高写负载下IO请求大小分布发生变化；innodb_io_capacity默认10000适配SSD。登录实例确认参数：

SHOW VARIABLES LIKE 'innodb_flush_method';
SHOW VARIABLES LIKE 'innodb_io_capacity';

6.4故障模拟验证

使用sysbench制造数据库写压力，观测iostat指标；调整innodb_io_capacity参数，观察await、%util变化。

sysbench oltp_write_only --mysql‑socket=/fgedudb/mysql.sock --mysql‑user=fgedu --mysql‑db=fgedudb --threads=16 run

七、网络子系统性能实战诊断

故障现象：业务偶发MySQL连接失败，间歇性建立连接超时，数据库实例CPU、内存、IO负载并不高。

7.1 ss命令统计套接字状态

ss -s
ss -ti

查看TCP重传统计；查看SYN、TIME‑WAIT、ESTABLISHED数量。查看数据库端口套接字（MySQL端口3306）

ss -ant | grep 3306

7.2内核网络队列参数调优，适配64G/8C数据库主机

编辑/etc/sysctl.conf

net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

生效

sysctl -p

7.3 tcpdump抓取数据库端口报文，定位网络丢包重传

tcpdump -i any port 3306 -w /fgedudb/mysql_net.pcap

捕获报文保存，后期wireshark分析，定位是否网络层丢包、重传引发业务延迟。

网上搜索风哥教程可以学习全套数据库教程

八、系统资源限制故障实战（ulimit）

典型故障：MySQL运行一段时间后报错无法创建新线程、打开文件过多，实例异常断开。

8.1查看mysqld进程实际ulimit限制

不要直接执行ulimit，要查看运行中进程限制：

cat /proc/$(pidof mysqld)/limits

重点看：Max open files，Max processes。数据库主机文件句柄建议设置65535以上。

8.2修改systemd服务资源限制（MySQL8.4示例）

编辑mysqld systemd单元文件，增加：

[Service]
LimitNOFILE=65535
LimitNPROC=65535

重载systemd，重启实例生效。

systemctl daemon‑reload
systemctl restart mysqld@fgedudb

修改完成，再次查看/proc/<pid>/limits验证生效。

上51CTO搜索风哥可以学习全套数据库教程

九、操作系统基线巡检完整脚本

完整脚本os_check_mysql.sh，放置/fgedudb/script/os_check_mysql.sh，可以定期执行输出风险提示，脚本适配MySQL8.4、MySQL9.7，主机名fgedu‑net‑cn1/fgedu‑net‑cn2。

#!/bin/bash
MYSQL_PID=$(pidof mysqld)
echo "==========操作系统巡检报告  $(date)=========="
echo "1.CPU基线检查 vmstat输出"
vmstat 1 2
echo -e "\n2.内存swap检查"
free -h
cat /proc/sys/vm/swappiness
echo -e "\n3.THP状态检查"
cat /sys/kernel/mm/transparent_hugepage/enabled
echo -e "\n4.NUMA状态"
numactl --hardware
echo -e "\n5.磁盘IO状态"
iostat -x 1 2
echo -e "\n6.mysqld进程资源限制 /proc/$MYSQL_PID/limits"
cat /proc/$MYSQL_PID/limits
echo -e "\n7.网络套接字统计"
ss -s
echo "========巡检结束========"

赋予权限：

mkdir -p /fgedudb/script
mv os_check_mysql.sh /fgedudb/script/
chmod +x /fgedudb/script/os_check_mysql.sh
/fgedudb/script/os_check_mysql.sh

风哥针对本文总结

风哥教程本文完整阐述MySQL操作系统性能诊断整套知识，分为理论原理与大量实战操作。生产环境MySQL性能故障排查，必须遵循“先操作系统层，后数据库实例层”的顺序，优先确认CPU运行队列、swap抖动、iowait磁盘IO、网络队列、ulimit资源限制这些底层风险点，再进入SQL、索引、InnoDB内部参数调优环节。

对比MySQL8.4 LTS与MySQL9.7版本，两者操作系统交互层面有重要差异：redo日志动态管理、IO默认行为、performance_schema新增监控事件，在两套版本主机fgedu‑net‑cn1、fgedu‑net‑cn2上调优时，内核参数可以统一，但数据库内部IO、redo相关参数配置需要区分版本，不要直接套用旧版本配置模板。

生产实操几个关键风险点必须牢记：

数据库业务服务器严禁出现swap持续抖动，vm.swappiness建议设置为1，一旦观测si/so不为0优先处理内存问题，不要直接调整SQL。
透明大页THP务必关闭，THP会带来随机不可预测的延迟毛刺。
NUMA架构物理机要警惕整机内存充足，单节点内存耗尽触发swap的隐蔽故障。
iowait高不等于CPU瓶颈，iowait升高代表瓶颈存在磁盘IO子系统，优化CPU参数不会解决问题。
所有性能指标需要对比业务基线，不能依靠瞬时单次采样就下故障结论；sysstat开启历史采样，故障发生后可以回溯历史指标。
文件句柄数、进程数ulimit限制故障隐蔽，必须查看运行中/proc/mysqld‑pid/limits确认实际生效限制，不要只看登录shell的ulimit输出。

操作系统是MySQL性能的底座，如果底座配置不合理，无论如何调整数据库SQL和参数，业务性能都无法达到预期。本套风哥教程所有命令全部基于64G内存8CPU硬件规格，读者需要根据自己真实业务硬件规格做参数适配调整。