在 MySQL 日常运维工作中，我们经常会遇到 CPU 高负载、数据迁移、大表删除等棘手问题，同时也需要熟悉系统库的功能差异以及应对各类面试高频考点。本文将结合实战经验，详细讲解 MySQL 运维中的核心操作与关键知识点。
一、MySQL CPU 高负载排查方案
当 MySQL 服务器出现 CPU 高负载时，会直接影响业务的响应速度，我们可以通过以下四步排查定位问题根源：
查看进程列表 使用 top 命令查看服务器进程，定位占用大量 CPU 资源的进程，确认是否是 MySQL 进程导致的负载过高。
检查 MySQL 连接 登录 MySQL 后执行 show processlist 命令，查看当前正在执行的 SQL 语句。曾经遇到过研发执行全表 delete 操作，导致 MySQL 进程 CPU 占用率直接跑满的情况，通过该命令可以快速定位这类高危 SQL。
检查慢查询日志 慢查询日志记录了执行时间超过阈值的 SQL 语句。查看 CPU 高负载期间的慢查询日志，分析是否由低效 SQL 导致负载飙升。如果存在慢查询，需要考虑为数据表添加合适的索引，或者优化 SQL 语句的执行逻辑。
观察其他指标 除了上述操作，还需要关注数据库的其他指标，比如是否存在锁等待情况、QPS（每秒查询数）和 TPS（每秒事务数）是否出现暴涨，这些指标都能帮助我们更全面地判断问题原因。
| 查看进程列表 |
| 检查MySQL连接 |
| 检查慢查询日志 |
| 观察其他指标 |
二、MySQL 数据迁移工具选型
在业务迭代过程中，数据迁移是常见需求，不同数据量和场景下，适用的迁移工具也有所不同：
云厂商同步服务 主流云厂商都提供了成熟的数据同步服务，例如阿里云的 DTS（数据传输服务）。这类服务可以实现 MySQL 数据的实时同步，操作简单且稳定性高，适合云上环境的数据迁移需求。
开源工具 针对不同的数据库类型，有对应的开源迁移工具可供选择：
- MySQL 数据迁移可使用 Otter；
- Redis 数据迁移可使用 RedisShake；
- MongoDB 数据迁移可使用 MongoShake。
停机备份恢复（小数据量场景） 如果数据量不大，对业务中断时间要求不高，可以直接停机后对源数据库进行备份，再将备份文件恢复到目标数据库中。这种方式操作成本低，适合小型应用或测试环境的数据迁移。
三、安全 Drop 大表的正确姿势
直接 drop 大表（例如 4T 级别的数据表）会消耗大量系统资源，甚至导致数据库服务卡顿，我们可以通过以下三步安全删除大表：
创建硬链接 为大表的数据文件（.ibd 文件）创建硬链接，这样后续删除表结构时速度会大幅提升，命令如下：
ln table_name.ibd table_name.ibd.bak
删除表结构 执行 drop 命令删除表结构，此时因为硬链接的存在，不会立即删除物理数据文件，命令如下：
drop table table_name;
清理物理文件 最后通过脚本逐步缩小并删除硬链接文件，避免一次性删除大文件占用过多 IO 资源，命令如下：
for i in `seq 4096 -1 1` ; do sleep 1; truncate -s ${i}G table_name.ibd.bak; done
rm -f table_name.ibd.bak
注意：如果是云上 RDS 数据库，由于无法直接操作底层物理机，需要联系云厂商获取大表删除的官方方案。
四、performance_schema 与 information_schema 的区别
MySQL 中有两个重要的系统库 performance_schema 和 information_schema，它们的定位和用途差异显著，具体对比如下表：
| performance_schema | 包含资源消耗、资源等待等性能相关数据 | 主要用于性能调优、故障排查和性能监控，可诊断数据库性能瓶颈、分析查询执行情况 |
| information_schema | 主要存储服务器运行过程中的元数据信息 | 用于查询数据库对象的结构、权限、状态等信息，例如查看表结构、列信息、用户权限 |
简单来说，performance_schema 关注 MySQL 的运行性能，而 information_schema 关注 MySQL 的对象结构。
五、MySQL 运维高频面试题与实战经验
在 MySQL 运维相关面试中，除了技术原理，面试官更关注实战经验，以下是高频问题及核心解答：
Q：一个实例活跃线程个数多少以下才算合理？ A：活跃线程个数建议控制在机器核数的两倍以下，因为活跃线程才会消耗 CPU 资源。可以通过 innodb_thread_concurrency 参数控制 MySQL 的最大活跃线程个数。
Q：数据库升级/迁移时，如何确保数据完整性和最小停机时间？ A：提前配置老库到新库的数据同步；数据量大时，迁移前一天用 pt-table-checksum 工具校验数据一致性（可只校验主键 ID 或表数据量，提升校验速度），再执行迁移，大幅缩短停机时间。
Q：Delete 操作后，什么时候释放表空间？ A：不同存储引擎表现不同：
- InnoDB：Delete 后不会立即释放表空间，需要执行 optimize table 命令才能释放；
- MyISAM：Delete 后会立即释放表空间。
Q：如何定位最耗时或最消耗性能的 SQL？ A：一是查看慢查询日志，扫描行数最多的 SQL 往往最消耗性能；二是使用 pt-query-digest 工具分析慢查询日志，排名靠前的 SQL 即为重点优化对象。
Q：研发执行无条件 Update 操作，如何恢复数据？ A：可以通过解析 binlog 日志，生成误操作 SQL 的回滚语句，常用工具为 my2sql。
Q：如何与开发团队协作进行数据库设计和性能优化？ A：提前参与数据库设计讨论，确保表结构高效且可扩展；部署数据库监控系统，与开发团队共享监控数据，共同排查性能问题；制定数据库最佳实践规范，减少潜在问题。
Q：自增主键到上限了会发生什么？ A：自增 ID 达到上限后，新插入数据会报主键冲突错误；如果是隐藏的 row_id 达到上限，会归零后重新递增，若出现相同 row_id，后写入的数据会覆盖之前的数据。
Q：工作中遇到的最棘手 MySQL 问题是什么？如何解决？ A：这类问题需要结合实际案例回答，例如遇到某版本 MySQL 的 bug（可参考 MySQL 官方 bug 库），或者因参数配置不合理导致的性能问题，重点阐述排查思路和解决过程，体现技术深度。
六、总结
MySQL 运维工作需要兼顾理论知识和实战经验，无论是 CPU 高负载排查、数据迁移，还是大表安全删除，都需要遵循科学的操作流程。同时，熟悉系统库功能和面试高频考点，能帮助我们更好地应对工作和面试中的挑战。后续运维工作中，建议多积累问题排查案例，形成自己的运维方法论。
