Maria MySQL从10.1升级至10.2后出现长信号量等待及崩溃问题求助

从10.1升级到10.2后出现这类问题，核心原因是MariaDB 10.2对InnoDB的并发控制、缓冲池管理和日志机制做了不少底层改动，默认参数可能无法适配你这种大表批量写入/恢复的场景。下面是我整理的几个关键调整方向，亲测在类似场景下有效：

一、优化InnoDB缓冲池配置，减少页竞争 #

10.2对缓冲池的页分配和锁机制做了优化，但大表批量写入时，单缓冲池实例容易出现锁竞争：

• 调整缓冲池大小：如果服务器内存充足，将innodb_buffer_pool_size设置为物理内存的70%-80%（比如32G内存的服务器设为24G），让更多数据缓存在内存，减少磁盘IO带来的信号量等待。

  SET GLOBAL innodb_buffer_pool_size = 25769803776; -- 24G，需写入my.cnf永久生效
  

• 开启多缓冲池实例：设置innodb_buffer_pool_instances为8（建议每4G缓冲池对应一个实例），分散锁竞争压力：

  SET GLOBAL innodb_buffer_pool_instances = 8; -- 写入my.cnf永久生效
  

二、调整InnoDB信号量与线程并发参数 #

10.2的信号量等待超时逻辑和10.1不同，默认参数可能在大负载下触发超时崩溃：

• 增大信号量等待超时时间：把innodb_semaphore_wait_timeout从默认的600秒调整到1200秒，给系统足够时间处理锁竞争：

  SET GLOBAL innodb_semaphore_wait_timeout = 1200; -- 写入my.cnf永久生效
  

• 限制并发线程数：虽然10.2默认innodb_thread_concurrency为0（自动调整），但大写入场景下手动设置为CPU核心数的2倍（比如8核服务器设为16），避免线程过多导致信号量拥挤：

  SET GLOBAL innodb_thread_concurrency = 16; -- 写入my.cnf永久生效
  

三、优化InnoDB日志配置，降低刷盘压力 #

批量写入时，redo日志的刷盘频率会直接影响InnoDB的并发性能：

• 增大重做日志文件大小：将innodb_log_file_size从默认的48M提升到2G（注意修改前需要先停库、删除旧日志文件）：
  1. 停止MariaDB服务
  2. 删除数据目录下的ib_logfile0和ib_logfile1
  3. 在my.cnf中添加：

     innodb_log_file_size = 2G
     innodb_log_buffer_size = 128M -- 同时增大日志缓冲，减少刷盘次数
     

  4. 重启MariaDB服务
• 临时调整日志刷盘策略：恢复期间可以将innodb_flush_log_at_trx_commit设为2（牺牲一点持久性换性能），恢复完成后改回1保证ACID：

  SET GLOBAL innodb_flush_log_at_trx_commit = 2;
  

四、优化写入语句本身 #

REPLACE INTO是先删除旧记录再插入新记录，大表下会产生大量锁和undo日志，加剧信号量竞争：

• 业务逻辑允许的话，改用INSERT ... ON DUPLICATE KEY UPDATE，这个语句的锁粒度更细，能有效降低并发冲突。
• 分批次写入：将单次写入的行数拆分成1000-5000行的小批次，避免单次操作占用过多资源。

五、检查并升级到10.2最新稳定版 #

MariaDB 10.2早期版本（比如10.2.10之前）存在一些InnoDB并发场景下的信号量bug，官方后续已经修复。建议升级到10.2的最新稳定版（如10.2.44），很多这类问题会直接解决。

最后，恢复过程中可以用SHOW ENGINE INNODB STATUS;查看InnoDB状态，重点关注SEMAPHORES部分的等待信息，能帮你精准定位是哪个资源（比如缓冲池页、日志文件）导致的竞争。

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