无Schema修改时MongoDB出现高SchemaLock与慢查询的原因及解决方案咨询

一、未修改Schema却出现高SchemaLock等待的原因 #

• 内部元数据后台操作：MongoDB会自动执行集合统计信息更新、索引后台维护（比如碎片整理、统计刷新）这类元数据操作，这些操作都需要申请SchemaLock。在你每秒10k次IO的高并发场景下，这类后台操作的锁竞争会被放大，导致查询请求长时间等待SchemaLock。
• 查询计划缓存频繁重建：即便没有修改Schema，若查询的参数、过滤条件频繁变化，或者集合数据分布出现较大波动，MongoDB会频繁重建查询计划，这个过程会涉及SchemaLock的申请。你的查询里用到了$exists、$ne这类容易导致计划不稳定的操作，再叠加高并发，会进一步加剧锁竞争。
• 并发连接与会话的额外开销：大量并发连接（日志里的conn4409说明连接数不低）的创建、销毁，或是会话的频繁切换，可能间接触发Schema相关的锁操作。如果驱动配置不当，比如每次请求都新建连接，会大幅增加SchemaLock的竞争概率。
• IO压力导致后台任务延迟：WiredTiger的checkpoint、日志刷写等后台任务本身不直接申请SchemaLock，但当系统IO压力过载（每秒10k次IO）时，这些后台任务的执行会被延迟，进而让持有SchemaLock的操作占用锁的时间变长，查询请求的等待时间也随之增加。

二、可行的解决方案 #

• 调整后台统计信息收集频率：修改collectionScanDelayMillis参数，延长集合统计信息自动收集的间隔，减少后台操作对SchemaLock的竞争。执行以下命令调整：

  db.adminCommand({setParameter: 1, collectionScanDelayMillis: 3600000})
  

  （示例设置为1小时，可根据业务情况调整）
• 优化查询计划稳定性：
  • 对高频查询使用hint()强制指定索引，避免MongoDB频繁尝试不同查询计划，减少计划缓存重建带来的SchemaLock竞争。比如你的查询可以修改为：

    db.users.find({_id:1, status:{$exists:true, $ne:9}}).hint({_id:1}).limit(1).projection({status:1})
    

  • 清理无效的计划缓存，针对特定集合执行：

    db.users.getPlanCache().clear()
    

    避免旧的无效计划导致频繁重建。
• 优化连接池配置：
  • 调整驱动连接池大小，结合384GB内存的配置，将连接池上限设置在200-500的合理范围，减少连接创建销毁的额外开销。
  • 启用连接复用，确保应用端使用长连接，避免每次请求都新建连接。
• 缓解系统IO压力：
  • 确保所有查询都命中索引，检查并清理冗余索引，降低索引维护的IO开销。
  • 调高WiredTiger缓存大小，默认是内存的50%，你可以将wiredTigerCacheSizeGB设置为256GB左右，让更多数据和索引缓存在内存中，减少磁盘IO。
  • 更换为SSD存储，提升磁盘IO性能，缩短后台任务的执行时间，减少SchemaLock的持有时长。
• 监控排查锁竞争源头：
  • 使用db.currentOp()查看当前持有SchemaLock的操作，定位具体的后台任务：

    db.currentOp({locks: {"Schema": {$exists: true}}})
    

  • 开启MongoDB详细日志，跟踪SchemaLock的申请和释放情况，精准定位锁竞争的原因。
• 升级MongoDB版本：MongoDB 4.4之后的5.0、6.0版本对SchemaLock的实现做了优化，减少了锁竞争场景，升级到更高版本可以从根源上缓解这类问题。

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