直接看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//cmdline | tr '\0' ' ' 验证命令行参数

怎么查 MySQL 预分配的内存上限（不是实时用量）

MySQL 启动时就按配置预占关键缓冲区，真正决定内存水位的是几个硬性参数，不是“当前用了多少”。改了大部分必须重启才生效。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

• 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 结果，拿它做容量规划会严重误判