直接看ps最准，因SHOW PROCESSLIST和information_schema仅反映SQL状态或逻辑元数据，无法体现操作系统级CPU、内存、磁盘真实开销；mysqld主进程的%CPU和RSS才是真实资源消耗，须用ps aux --sort=-%cpu/-\%mem定位，并验证PID归属。
直接看 ps 最准，SHOW PROCESSLIST 和 information_schema 查不到真实 CPU、内存、磁盘开销——它们只反映 SQL 执行状态或逻辑元数据，不是操作系统实际分配的资源。
怎么看 mysqld 进程真实的 CPU 和内存占用
MySQL 是单进程多线程模型，所有线程都归属同一个 mysqld 主进程。系统级资源（CPU%、RSS 内存）必须从 ps 或 top 里抓，不能靠 MySQL 内部命令估算。
- 查 CPU 占用最高的前 10 个进程：
ps aux --sort=-%cpu | head -11，重点看mysqld行的%CPU列 - 查内存占用最高的前 10 个进程：
ps aux --sort=-%mem | head -11，看RSS列（单位 KB），除以 1024 换算成 MB - 精准过滤 MySQL 进程：
ps aux | grep mysqld | grep -v grep，再加--sort=-%cpu或--sort=-%mem - ⚠️ 坑：
top默认按 CPU 排序，但可能把java或nginx排前面，漏掉已跑满 300% 的mysqld；务必确认 PID 是否真属于 MySQL 实例，可用cat /proc/<pid>/cmdline | tr '\0' ' '</pid>验证命令行参数
怎么查 MySQL 预分配的内存上限（不是实时用量）
MySQL 启动时就按配置预占关键缓冲区，真正决定内存水位的是几个硬性参数，不是“当前用了多少”。改了大部分必须重启才生效。
-
innodb_buffer_pool_size：InnoDB 缓冲池，通常设为物理内存的 50%–75%，是最大头；查法：SHOW VARIABLES LIKE 'innodb_buffer_pool_size' -
key_buffer_size：MyISAM 索引缓存（若不用 MyISAM，可设为 4M～16M） -
tmp_table_size和max_heap_table_size：取小者生效，超限会落盘拖慢查询 - 所有线程级内存（如
sort_buffer_size、join_buffer_size）乘以并发连接数，也可能撑爆内存 - ⚠️ 坑：
innodb_buffer_pool_size在 MySQL 5.7+ 支持在线增大，但需满足 chunk 对齐要求，否则报错ER_CHANGE_MASTER_WRONG_INNODB_BUFFER_POOL_SIZE
怎么查 MySQL 数据目录真实磁盘占用（别信 information_schema.TABLES）
information_schema.TABLES 中的 DATA_LENGTH 和 INDEX_LENGTH 是存储引擎维护的逻辑大小，严重失真——压缩表、未回收空间、ibdata1、ibtmp1、binlog 全都不计入。
- 查整体磁盘占用：
du -sh /var/lib/mysql（Ubuntu/Debian）或du -sh /usr/local/var/mysql（macOS Homebrew） - 查各库物理目录大小：
du -sh --max-depth=1 /var/lib/mysql | sort -hr - 找最大的 .ibd 文件：
find /var/lib/mysql -name "*.ibd" -exec du -h {} \; | sort -hr | head -20 - 看有没有异常大文件：
ls -lSh /var/lib/mysql | head -10，重点关注ibdata1、ibtmp1、mysql-bin.* - ⚠️ 坑：误删
ibdata1或ib_logfile*会导致 MySQL 启动失败，这些是 InnoDB 核心系统文件，不能像普通表文件那样直接rm
怎么快速判断是否快磁盘爆满（不是看“已用多少”，而是看“还剩多少”）
运维核心是防患于未然。磁盘爆满往往发生在业务报错之后，真正该盯的是剩余可用空间和使用率趋势。
- 查挂载点整体使用率：
df -h，重点关注Avail列（剩余可用空间） - 确认
tmpdir是否指向数据目录：SELECT @@tmpdir;，如果是/var/lib/mysql，临时排序/JOIN 产生的文件也会撑大目录 - 检查慢查询日志是否开着且没轮转：
ls -lh /var/lib/mysql/*slow*（路径取决于slow_query_log_file配置） - ⚠️ 坑：很多团队只查“已用空间”，却忽略
df -h的Avail值——它才是触发告警的黄金指标；information_schema里算出来的“总大小”加起来远小于du结果，拿它做容量规划会严重误判
