数据库教程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

### 风哥教程本文内容大纲

1. 操作系统性能诊断基础理论：数据库与操作系统协同原理；四大资源维度CPU、内存、磁盘IO、网络的性能瓶颈判定逻辑；MySQL8.4与MySQL9.7在操作系统交互层面的差异点；性能指标阈值与基线建立方法论。

2. Linux操作系统性能诊断工具集原理：sysstat工具家族vmstat、sar、mpstat、iostat、pidstat；进程线程分析工具top、htop、ps、pstree；性能采样工具perf；内存分析工具free、pmap、numactl；网络诊断工具ss、tcpdump。讲解每一个工具的底层原理，区分全局统计、进程级统计、线程级统计、硬件函数级统计的适用场景。

3. 实战环境准备：`fgedu‑net‑cn1`（MySQL8.4）与`fgedu‑net‑cn2`（MySQL9.7）环境初始化、依赖包安装、操作系统基线采集脚本编写。

4. CPU性能瓶颈完整实战排查：模拟CPU高负载故障，从全局指标定位，到进程、线程，再到内核函数热点，联动MySQL内部performance_schema定位SQL根源，完整复现排障全流程。

5. 内存子系统性能实战诊断：swap抖动故障、透明大页THP问题、NUMA内存分配异常、脏页回写内核参数问题；包含现象复现、指标识别、参数调整、效果验证全套操作命令。> 

> 风哥教程 113257174

6. 磁盘IO性能实战诊断：IO等待iowait升高、IOPS打满、磁盘await延迟过高故障；文件系统挂载参数调优，区分MySQL8.4、MySQL9.7的IO行为差异；交换分区、脏页参数实战调整。

7. 网络子系统性能实战诊断：数据库连接抖动、TCP重传、半连接队列溢出问题；内核网络参数调优，ss命令定位数据库连接异常。

8. 系统资源限制故障实战：ulimit资源限制、文件句柄数、进程最大线程数导致MySQL异常现象定位与修复。

9. 操作系统基线巡检脚本开发实战，自动输出风险项。

10. 风哥针对本文总结：故障排查流程复盘，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操作系统交互关键差异理论

1. redo日志架构：MySQL8.4使用innodb_redo_log_capacity参数；MySQL9.7完全继承动态redo log，运行期间redo文件大小自动伸缩，脏页回写对操作系统压力模式发生变化，不再需要手动设置多个固定大小redo文件。

2. IO默认行为：两者Linux平台默认开启O_DIRECT，绕过操作系统缓存，减少双拷贝开销。

3. 内存模型：MySQL9.7优化内部线程内存分配，高并发场景系统态CPU占比相比8.4略有改善；9.7对NUMA感知增强。

4. performance_schema：MySQL9.7新增部分操作系统层面等待事件，更容易定位线程等待操作系统资源场景。

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

### 2.1 sysstat工具家族原理

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

1. vmstat：整机全局统计，CPU、内存swap、IO块设备、上下文切换、中断，反映整机宏观状态，无法区分单个进程数据。

2. sar：历史数据采集，周期性保存系统性能快照，可以回溯历史故障时刻指标；同时支持实时采样。系统默认通过cron任务生成sa*历史日志文件。

3. mpstat：多CPU细分统计，可以查看每一颗CPU核心独立使用率，定位单颗CPU打满的“CPU孤岛”故障。

4. iostat：块设备磁盘IO统计，输出每个磁盘分区IOPS、吞吐量、await、%util指标。

5. pidstat：进程与线程级资源统计，可以针对指定PID输出CPU、内存、IO、上下文切换统计，是数据库DBA最高频工具，打通整机指标到mysqld进程的桥梁。

### 2.2进程线程分析工具原理

1. top/htop：实时进程视图；top‑H可以展开进程内部所有线程，MySQL mysqld内部有大量后台线程、用户工作线程，可以直接看到哪一条线程消耗CPU资源。

2. 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平衡；yj配置grub内核参数`numa=off`；或者启动mysqld绑定NUMA节点。

```

echo 0 > /proc/sys/kernel/numa_balancing

```

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

```

#临时生效

sysctl -w vm.swappiness=1

#yj写入/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

```

yj关闭，修改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相关参数配置需要区分版本，不要直接套用旧版本配置模板。

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

1. 数据库业务服务器严禁出现swap持续抖动，vm.swappiness建议设置为1，一旦观测si/so不为0优先处理内存问题，不要直接调整SQL。

2. 透明大页THP务必关闭，THP会带来随机不可预测的延迟毛刺。

3. NUMA架构物理机要警惕整机内存充足，单节点内存耗尽触发swap的隐蔽故障。

4. iowait高不等于CPU瓶颈，iowait升高代表瓶颈存在磁盘IO子系统，优化CPU参数不会解决问题。

5. 所有性能指标需要对比业务基线，不能依靠瞬时单次采样就下故障结论；sysstat开启历史采样，故障发生后可以回溯历史指标。

6. 文件句柄数、进程数ulimit限制故障隐蔽，必须查看运行中`/proc/mysqld‑pid/limits`确认实际生效限制，不要只看登录shell的ulimit输出。

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