MariaDB从5.5升级至10.2后CPU占用达400%故障排查求助

当前CPU占用412.5%基本跑满了E3-1231 v3的全部8个逻辑核心，瓶颈集中在计算侧，可按以下步骤排查：

1. 优先修复基础配置问题 #

你提供的my.cnf中所有InnoDB相关配置全部为注释状态，MariaDB 10.2默认存储引擎为InnoDB，未手动配置参数会导致引擎使用默认极小值运行，内存利用不足引发频繁逻辑读、查询回表等超高CPU消耗操作，同时绝大多数用户升级后忘记执行系统表适配命令也会引发额外开销：

• 先执行系统表适配命令，避免版本不兼容开销：

mysql_upgrade -u root -p

• 替换my.cnf中[mysqld]段的配置，注释原有全部被注释的InnoDB参数后添加以下配置：

# InnoDB核心配置，32G内存分配70%给缓冲池适配业务
innodb_buffer_pool_size = 22G
innodb_log_file_size = 4G
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 1 # 数据一致性要求不高可改为2进一步降CPU
innodb_lock_wait_timeout = 120
# 适配新版本的通用缓存参数
table_open_cache = 2048
sort_buffer_size = 2M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
max_allowed_packet = 64M
# 不需要全量性能监控可关闭性能架构降低CPU消耗
performance_schema = OFF

• 配置修改完成后重启MariaDB服务：

systemctl restart mariadb

重启后观察10分钟，如果CPU没有明显下降继续下一步排查。

2. 排查慢查询与执行计划异常 #

MariaDB 10.2的优化器逻辑和5.5差异极大，旧版本正常运行的SQL在新版本可能生成错误的执行计划，是版本升级后CPU飙升的最常见原因：

• 开启慢查询日志定位高消耗SQL，在[mysqld]段添加以下配置后重启服务：

slow_query_log = ON
slow_query_log_file = /var/log/mariadb/slow.log
long_query_time = 1
log_queries_not_using_indexes = ON

• 运行1-2小时收集足够日志后，分析慢日志定位TOP10高CPU消耗的SQL，用EXPLAIN语句查看执行计划，检查是否存在全表扫描、索引失效、join顺序错误等问题，必要时用FORCE INDEX强制SQL走5.5版本下的有效索引。

3. 排查其他潜在问题 #

• 检查业务侧的存储过程、触发器、定时任务：新版本的SQL语法兼容性可能导致循环逻辑出现死循环、重复执行等问题，优先排查每天固定时间运行的批量数据处理脚本。
• 不需要主从同步的场景可以临时注释log-bin=mysql-bin配置重启服务，验证是否是binlog写入逻辑导致的CPU消耗；需要主从同步的场景可添加sync_binlog = 1000参数降低binlog刷盘频率。
• 如果以上步骤都无效，可升级到10.2分支的最新稳定小版本，修复优化器相关的已知bug。

内容的提问来源于stack exchange，提问作者Rashid