直接看 ps 最准，因 SHOW PROCESSLIST 不反映系统资源消耗；mysqld 主进程的 %CPU 和 RSS 才是真实开销，需用 ps aux --sort=-%cpu/-\%mem 定位，并验证 PID 是否属 MySQL 实例。
怎么看 MySQL 进程本身占了多少 CPU 和内存
直接看 ps 最准，因为 SHOW PROCESSLIST 只反映 SQL 执行状态，不反映系统资源消耗。MySQL 是单进程多线程模型，mysqld 主进程的 CPU 和 RSS（常驻内存）才是真实开销。
- 查 CPU 占用最高的前 10 个进程：
ps aux --sort=-%cpu | head -11（含表头），重点关注mysqld行的%CPU - 查内存占用最高的前 10 个进程：
ps aux --sort=-%mem | head -11，看RSS列（单位 KB），换算成 MB 除以 1024 - 只盯 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' ' ' 验证）。
怎么查 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）乘以并发连接数，也可能撑爆内存
坑点：改了这些变量必须重启 MySQL 才生效（除少数动态变量外）；而且 innodb_buffer_pool_size 在 MySQL 5.7+ 支持在线调整，但仅限增大，且需满足 chunk 对齐要求，否则报错 ER_CHANGE_MASTER_WRONG_INNODB_BUFFER_POOL_SIZE。
怎么定位哪个 SQL 或线程在吃资源
SHOW PROCESSLIST 是第一道筛子，但它只告诉你“谁在跑”，不告诉你“谁在烧 CPU”。得结合运行时状态和执行时间交叉判断。
- 查活跃查询（非 Sleep）：
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND TIME > 60; - 重点看
STATE列：出现Sending data、Copying to tmp table、Sorting result且TIME持续增长，基本就是问题 SQL - 配合
EXPLAIN看执行计划：对可疑ID执行EXPLAIN FORMAT=TREE SELECT ...（MySQL 8.0+），检查是否全表扫描、没走索引、临时表/文件排序过多 - 别忽略
User和Host：有时是某个应用服务的连接池疯刷心跳或重试 SQL，不是业务逻辑本身的问题
常见误判：看到 State: Locked 就以为是死锁——其实更可能是表级锁（如 ALTER TABLE）、MDL 锁（元数据锁），或是长事务阻塞了 DDL，得查 performance_schema.metadata_locks 或 information_schema.INNODB_TRX。
怎么关联 Linux 系统指标和 MySQL 状态
单看 MySQL 内部指标容易断章取义。比如 Threads_connected 高，未必是业务压力大，可能是连接泄漏；CPU 100% 也未必是 SQL 慢，可能是磁盘 I/O 卡住导致线程集体等待。
- 先看系统负载：
uptime或cat /proc/loadavg，如果 load > CPU 核数 × 3，大概率有 I/O 或锁瓶颈 - 查 I/O 等待：
iostat -x 1 3，关注%util（接近 100% 表示磁盘饱和）和await（平均响应时间 > 10ms 就值得怀疑） - 查网络连接：
netstat -ant | grep :3306 | awk '{print $6}' | sort | uniq -c | sort -rn，快速识别异常大量TIME_WAIT或ESTABLISHED - 查 MySQL 当前连接数：
SHOW STATUS LIKE 'Threads_connected';，再比对max_connections，避免连接打满后新请求排队
最容易被跳过的环节：没确认 MySQL 是不是绑核运行（taskset -cp <PID>），或者被容器 cgroup 限频限内存却没感知——此时 top 看到的 CPU% 是虚高，实际计算能力已被掐脖子。
