cookqq-优快云博客

原创 mongodb源代码分析createCollection命令由create.idl变成create_gen.cpp过程

buildscripts/idl/idl/generator.py把create.idl转成create_gen.cpp和create_gen.h，再编译成create_gen.obj，CreateCommand对象封装命令createCollection。

2025-07-21 09:27:41 545

原创 MongoDB源码分析向客户端asyncSinkMessage返回执行结果DbResponse

MongoDB请求处理流程分析：状态机从Created依次转变为Source、SourceWait、Process、SinkWait等状态。核心_processMessage方法负责处理客户端请求，主要逻辑包括：1) 解压缩消息；2) 通过handleRequest执行数据库操作获取DbResponse；3) 构建响应消息头；4) 处理getMore特殊逻辑；5) 通过_sinkMessage异步发送响应。网络层通过session_asio的asyncSinkMessage将响应写入Socket。

2025-07-15 09:28:22 749

原创 mongod源代码Find的QueryPlanner::plan评分最高计划put到cache流程分析

b.user.find({age:28}).sort({wages:1})的缓存键为eqage~awages<1>，其中eqage表示过滤条件，awages表示排序字段，<1>表示索引是否起作用。通过这种机制，MongoDB能够有效减少重复查询的优化时间，提升整体性能。

2025-07-07 10:01:55 874

原创 mongod源代码Find的QueryPlanner::plan多个执行计划评分最高计划exec流程分析

在执行db.user.find({age:28}).sort({wages:1})命令时，MongoDB通过FindCmd的run方法解析命令并生成执行计划。重点分析了getExecutorFind()方法，该方法通过QueryPlanner::plan()生成执行计划。根据命令参数，生成了两个执行计划：方案1使用age索引进行扫描，方案2使用wages索引进行扫描。经过评分，方案1的评分更高，因此被选为最终执行计划。方案1的执行流程为：IXSCAN（读取age索引范围内的数据）→ FETCH → SORT

2025-07-03 09:24:42 1060

原创 mongod源代码Find的QueryPlanner::plan解析出来1个执行计划exec流程分析

在MongoDB中，执行db.user.find({age:28})查询时，系统会调用FindCmd的run方法，经过解析命令、生成执行计划和运行执行计划三个步骤。本文重点分析了生成执行计划的过程，特别是通过getExecutorFind()方法生成执行计划的流程。执行计划通常包括IXSCAN（索引扫描）和FETCH（数据获取）两个阶段。IXSCAN负责根据索引查找数据，而FETCH则根据索引结果获取实际文档。执行计划的生成过程涉及解析查询参数、选择合适的索引，并最终生成一个执行计划树。日志记录显示，系统首

2025-06-30 09:34:59 710

原创 mongodb源代码Find命令QueryPlanner::plan生成多个执行计划指定hint一个索引方案

在MongoDB中，执行计划的生成受到多个因素的影响，包括过滤器中的字段、索引、排序、投影等。对于查询db.user.find({age:28}).sort({wages:1})，MongoDB会通过QueryPlanner::plan生成执行计划。如果age是索引字段，执行计划会先进行索引扫描（IXSCAN），然后进行数据获取（FETCH），最后进行排序（SORT）。如果wages是索引字段，执行计划会直接使用索引扫描（IXSCAN）并获取数据（FETCH）。MongoDB会根据评分选择最优的执行计划。如

2025-06-24 09:32:50 1104

原创 mongod源代码Find的QueryPlanner::plan多个执行计划选择pickBestPlan高评分策略

MongoDB查询优化器选择执行计划的过程分析：对于查询db.user.find({age:28}).sort({wages:1})，系统生成两个候选方案：方案1使用age索引进行过滤后排序（IXSCAN>FETCH>SORT_KEY_GENERATOR>SORT），方案2直接使用wages索引（IXSCAN>FETCH）。通过MultiPlanStage的评估机制，系统运行两个计划各10000次（numWorks）或直到返回101条结果（numResults）。评分机制综合考虑：基

2025-06-20 09:46:21 1226

原创 mongod源代码Find的QueryPlanner::plan解析出来2个执行计划案例流程分析

FindCmd命令生成执行计划的影响因素包括：过滤器中是否有_id字段、是否有索引字段、是否有空间索引字段、是否有TEXT索引字段、命令中是否有sort、是否有projection字段以及是否进行全表扫描。例如，在user表中，字段age和wages建立了索引。对于命令db.user.find({age:28}).sort({wages:1})，由于age是索引字段，生成执行计划IXSCAN（索引age=1）>FETCH。此外，由于wages也是索引字段，生成了排序执行计划。其他条件不符合，未生成其他

2025-06-17 09:35:59 855

原创 mongod源代码Find的QueryPlanner::plan解析出来1个执行计划案例流程分析

db.user.find({age:2});调用FindCmd的run方法，1、解析命令（过滤器、排序、返回字段）2、根据命令参数生成执行计划 3、运行执行计划。下面重点分析2、根据命令参数生成执行计划getExecutorFind()

2025-06-12 09:32:47 1019

原创 mongod源码分析session执行handleRequest命令find过程

mongo/transport/service_state_machine.cpp已经分析startSession创建ASIOSession过程，并且验证connection是否超过限制ASIOSession和connection是循环接受客户端命令，状态转变流程是：State::Created 》 State::Source 》State::SourceWait 》 State::Process 》 State::SinkWait 》 State::Source 》State::SourceWait。

2025-06-09 09:33:09 932

原创 mongod源码分析session异步接受asyncSourceMessage()客户端流变Message对象

本文分析了MongoDB服务状态机中消息接收过程的关键实现。主要流程包括：1) ASIOSession从Created到Source等状态转换；2) 异步接收客户端消息的调用链，涉及_sourceMessage、asyncSourceMessage等方法；3) 消息格式解析，包含标准MsgHeader和特定数据；4) 两种线程模型（adaptive和synchronous）的处理差异；5) 底层opportunisticRead实现异步数据读取。重点剖析了动态线程模式下异步获取消息的完整流程，从网络层读取、

2025-06-05 18:13:56 1169

原创 mysql的表怎么手动迁移到MongoDB数据库

为了将MySQL中的department和user表迁移到MongoDB并进行关联join性能测试，可以采用以下步骤：首先，从MySQL导出数据为CSV文件，确保使用逗号作为分隔符，并添加标题行，将id字段改为_id。然后，使用MongoDB的mongoimport工具将CSV文件导入到MongoDB中，指定数据库、集合名称，并使用--headerline参数确保CSV的第一行作为字段名。这种方法避免了编写代码进行数据迁移，简化了迁移过程。

2025-06-03 09:55:28 445

原创 mongod源码分析session接受find命令-执行命令-返回数据给客户端-概要流程

mongo第一条命令状态转变流程是：State::Created 》 State::Source 》State::SourceWait 》 State::Process 》 State::SinkWait 》 State::Source 》State::SourceWait。session等待connection请求，状态转变流程：State::Created 》 State::Source 》State::SourceWait，最后调用_sinkMessage，将mongodb结果数据发送给客户端。

2025-05-29 09:18:45 1213

原创 mongodb语法$vlookup性能分析

在MongoDB中，查询level下有多少用户时，使用user表$vlookup department表的方法比department表$vlookup user表的方法更快。原因在于user表的_id字段有索引，而department_id字段没有索引。user表$vlookup department表的方法首先读取user表的department_id值，然后通过department表的_id字段进行关联，由于_id字段有索引，查询速度更快。而department表$vlookup user表的方法需要遍

2025-05-24 17:55:55 611

原创 mongod源码分析startSession()接受客户端connection连接过程

scheduleNextWithGuard()接口最核心的作用就是调用service_executor服务运行子模块(线程模型子模块)的schedule()接口来把状态机调度任务入队到ASIO网络库的一个全局队列(adaptive动态线程模型)，如果是一个链接一个线程模型，则任务入队到线程级私有队列。和ctx->setServiceExecutor(std::make_unique<ServiceExecutorAdaptive>(ctx, std::move(reactor)));创建异步模型执行器。

2025-05-20 09:37:16 1162

原创 mongod源码分析WiredTiger存储引擎内存计算逻辑

例如，在总 RAM 为 4GB 的系统上，WiredTiger 缓存使用 1.5GB RAM (0.5 * (4 GB - 1 GB) = 1.5 GB)。相反，在总 RAM 为 1.25GB 的系统上，WiredTiger 为 WiredTiger 缓存分配了 256 MB，因为这大于总 RAM 的一半减去 1 GB (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB)。WiredTiger 内部缓存中的集合数据未压缩，并使用与磁盘上格式不同的表示形式。

2025-05-15 09:27:47 685

原创 mongod源码分析WiredTigere存储引擎StorageEngin实例化流程

当mongod 启动时，初始化存储引擎在src/mongo/db/storage/storage_engine_init.cpp中的 initializeStorageEngine() 函数里。mongodb启动之后，数据data文件夹有几个重要文件：mongod.lock，storage.bson，WiredTiger.lock，WiredTiger，WiredTiger.wt，sizeStorer，journal等

2025-05-12 09:30:05 1329

原创 mongod4.0.7源码入口全局上下文ServiceContext分析

同步线程模式也就是一个链接一个线程模型，线程数的多少和链接数的多少成正比，链接数越多则线程数也越大。当服务端接收到客户端新连接事件通知后，会触发执行acceptCb()回调，该回调中底层ASIO库通过epol wait获取到所有的accept事件，每获取到一个accept事件就代表一个新的客户端链接，然后调用ServiceEntryPointlmp.::startSession()接口处理这个新的链接ASIOSession，整个过程递归执行，保证一次可以处理所有的客户端accept请求信息。

2025-05-09 09:39:16 957

原创 mongodb源代码分析sql用到数据例子

mongo显示隐藏字段showRecordId()，mongo系统默认字段，自增，用于索引和记录对应关系。mongo查看数据库列表命令：show databases。mongo查看集合列表show collections。mongo查看索引getIndexes()mongo分析sql命令explain()mongo插入单条文档insert()mongo查看数据列表find()mongo切换数据库use db。客户端连接mongod服务。mongo删除一条数据。mongo修改一条数据。

2025-05-07 17:05:34 264

原创 mongod4.0.7源码分析加载mongod.conf流程

mongo配置文件是mongod.conf，如果是linux系统apt安装，默认的路径是/etc/mongod.conf。mongod启动命令手动指定路径mongod --config /etc/mongod.conf。mongod.conf配置文件常见的配置参数有net.port: 27017，storage.dbPath: /var/lib/mongodb，storage.engine: wiredTiger。

2025-05-05 16:33:35 1996

原创 mongodb 分析 explain () 源码基础入门

db.user.explain().count({"_id" : ObjectId("67ed4c116e8444c140bf255f"),name:"conca"}) 执行策略是：IXSCAN > FETCH > COUNT。db.user.explain().find({"_id" : ObjectId("67ed4c116e8444c140bf255f"),name:"conca"}) 执行策略是：IXSCAN > FETCH。explain()方法是一个非常有用的工具，可用于分析查询的执行情况。

2025-05-01 19:40:27 1003

calmkey的专栏