MongoDB知识点与技巧总结
1. NoSQL 数据库概念与区别
问题分析：
NoSQL定义：Not Only SQL，强调不限于关系模型
核心区别：
数据模型：RDBMS是结构化表，NoSQL是键值对/文档/图等
扩展方式：RDBMS垂直扩展，NoSQL水平扩展
一致性：RDBMS强一致性，NoSQL最终一致性
深入理解：
使用场景：
适用：大数据、高并发、半结构化数据、快速迭代
不适用：复杂事务、强一致性要求、成熟商业智能
易错点：
误认为NoSQL完全替代SQL，实际是互补关系
忽略NoSQL在不同场景下的适用性差异
2. NoSQL 数据库类型
详细分类：
文档型：MongoDB, CouchDB
键值型：Redis, MemcacheDB
列存储：Cassandra, HBase
图数据库：Neo4j
时序数据库：InfluxDB
特点对比：
文档型：灵活schema，JSON/BSON格式
键值型：高性能缓存，简单数据结构
列存储：大数据分析，高写入吞吐
3. MySQL vs MongoDB 基础差别
核心差异：
| 特性 | MySQL | MongoDB |
|---|---|---|
| 数据模型 | 表+行 | 集合+文档 |
| Schema | 固定 | 动态 |
| 查询语言 | SQL | JSON查询 |
| 事务 | 完整ACID | 4.0+支持多文档事务 |
| 扩展 | 垂直 | 水平分片 |
| 关联 | 外键+JOIN | 内嵌/引用 |
性能考虑：
MongoDB在非结构化数据、高并发读取场景表现更好
MySQL在复杂事务、关联查询场景更优
4. MongoDB vs CouchDB vs CouchBase
详细对比：
| 特性 | MongoDB | CouchDB | CouchBase |
|---|---|---|---|
| 数据模型 | BSON文档 | JSON文档 | JSON文档+键值 |
| 一致性 | 强一致性 | 最终一致性 | 强一致性 |
| 查询 | 丰富查询语言 | MapReduce | N1QL+键值 |
| 复制 | 主从复制 | 多主复制 | 分布式 |
| 适用场景 | 通用用途 | 离线同步 | 高性能缓存 |
5. MongoDB 成为最好 NoSQL 数据库的原因
核心优势：
面向文档：自然的开发模式，映射对象模型
高性能：
内存映射文件
丰富的索引支持
高效的BSON格式
高可用：
自动故障转移
数据冗余复制
易扩展：
透明的分片机制
自动数据均衡
丰富查询语言：
类SQL的聚合管道
地理空间查询
文本搜索
6. 32位系统细微差别
技术细节：
内存映射限制：32位系统地址空间限制约2-3GB
Journaling默认禁用：防止预分配空间耗尽系统资源
实际限制：32位系统最大数据集约2GB
生产建议：
生产环境强烈建议使用64位系统
32位仅适用于开发和测试
7. Journal 回放机制
工作机制：
Journal文件：写操作的预写日志
原子性组：相关操作组成一个完整的journal组
恢复机制：只回放完整的journal组，确保数据一致性
故障恢复：
系统崩溃后，MongoDB通过journal重放恢复数据
不完整的journal组被丢弃，保证数据不损坏
8. 分析器作用
功能详解：
// 开启分析器
db.setProfilingLevel(level, slowms)
// level: 0-关闭, 1-慢查询, 2-所有操作使用场景：
性能调优：识别慢查询
索引优化：确定需要添加的索引
操作监控：了解数据库负载模式
输出分析：
查询时间、扫描文档数、返回文档数
索引使用情况、锁等待时间
9. 名字空间概念
定义：
格式：
数据库名.集合名示例：
blog.posts,users.profiles
内部实现：
每个名字空间对应一个文件系统文件
包含集合的数据和索引信息
10. 属性移除与存储
存储机制：
MongoDB使用BSON格式存储文档
删除属性后，文档被重新保存为新的BSON
存储空间不会立即回收，需要compact操作
空间管理：
删除操作产生存储碎片
定期运行
compact回收空间
11. 日志特征与安全备份
备份策略：
Journaling备份：基于oplog的增量备份
文件系统快照：配合journal的物理备份
mongodump：逻辑备份
恢复流程：
从备份恢复数据文件
应用journal中的操作到最新状态
12. 空值处理
空值规则：
允许：文档字段值为
null不允许：整个文档为
null空对象：可以存储
{}空对象
查询注意：
// 查询空值字段
db.collection.find({field: null})
// 这会匹配字段不存在或值为null的文档13. 更新操作与持久化
写入机制：
延迟写入：默认60秒刷新到磁盘
Journal提交：通常100ms提交到journal文件
手动刷新：使用
fsync或getLastError强制刷新
数据安全：
启用journaling时，即使崩溃也不会丢失数据
写入确认可以通过write concern控制
14. 事务与加锁
锁机制：
粒度：全局锁→数据库锁→集合锁→文档锁(3.0+)
类型：读锁(共享锁)、写锁(排他锁)
事务支持：
4.0版本开始支持多文档事务
但设计理念仍偏向无事务的高性能场景
15. 数据文件庞大原因
预分配机制：
目的：防止文件系统碎片，提高写入性能
策略：文件大小按2倍增长(16MB→32MB→64MB...)
最大文件：单个文件最大2GB
空间回收：
删除数据不会立即释放磁盘空间
需要
repairDatabase或compact回收空间
16. 备份故障恢复时间
故障转移流程：
检测主节点失效(10-30秒)
选举新的主节点
应用所有未完成的写操作
影响范围：
写入操作：完全不可用
强一致性读：不可用
最终一致性读：从节点可用(slaveOk)
17. Master/Primary 概念
角色定义：
Primary：复制集中唯一的可写节点
选举机制：基于Raft协议自动选举
职责：处理所有写操作，记录oplog
故障转移：
自动检测节点失效
从Secondary中选举新的Primary
18. Secondary/Slave 概念
复制机制：
数据同步：从Primary的oplog复制操作
读操作：可以处理读请求(配置依赖)
延迟：可能存在复制延迟
特殊类型：
Hidden：不参与选举，用于备份/报表
Delayed：延迟复制，用于错误恢复
19. getLastError 作用
功能详解：
确认机制：确认写操作是否成功
非必需：不调用不影响写操作执行
安全模式：提供更强的写入确认
Write Concern：
// 不同级别的写入确认
db.collection.insert(doc, {w: 1}) // 确认写入主节点
db.collection.insert(doc, {w: "majority"}) // 确认写入多数节点20. 分片环境选择
分片决策：
非分片：数据量小，开发测试环境
分片：大数据集，高吞吐需求
分片策略：
基于范围：适合范围查询
基于哈希：数据均匀分布
基于标签：手动控制数据分布
21. 分片与复制工作原理
分片架构：
应用 → Mongos → 配置服务器 → 分片集群分片：数据水平分区
块(Chunk)：数据迁移的基本单位
均衡器：自动在分片间迁移块
复制集架构：
Primary：写操作
Secondary：读操作+数据冗余
Arbiter：投票节点，不存储数据
22. 数据扩展时机
分片触发条件：
块数量：至少2个块才会触发迁移
块大小：默认64MB，可配置
均衡阈值：分片间数据量差异达到阈值
迁移过程：
均衡器检测不均衡
选择要迁移的块
在分片间迁移块数据
23. 迁移中更新操作
并发控制：
更新操作在旧分片上立即执行
迁移过程记录所有变更
所有权转移前同步变更到新分片
完成迁移，更新路由信息
数据一致性：
迁移过程中保证数据一致性
应用无感知的数据迁移
24. 分片故障查询行为
查询处理：
停止的分片：
默认返回错误
Partial选项允许返回部分结果
慢响应的分片：等待直到超时
容错配置：
// 允许部分结果
db.collection.find().readPref("secondary").allowPartialResults(true)25. moveChunk 临时文件
文件管理：
位置：
moveChunk目录下的临时文件用途：数据迁移过程中的中间文件
清理：迁移完成后手动清理
风险提示：
迁移过程中不要删除文件
确认迁移完成后再清理
26. 查看连接信息
连接监控：
// 查看连接池统计
db.adminCommand("connPoolStats")// 查看当前连接
db.currentOp(true).inprog.forEach(op => printjson(op.client)
)关键指标：
活跃连接数
连接池使用情况
客户端信息
27. 块移动失败处理
重试机制：
自动重试：失败后自动重试迁移
一致性保证：迁移是原子操作
最终状态：数据只存在于新分片
监控命令：
// 查看分片状态
sh.status()
// 查看迁移状态
db.getSiblingDB("config").chunks.find()28. 混合日志配置
配置灵活性：
不同节点可以有不同的journaling配置
但建议生产环境统一配置
一致性考虑：
有journal的节点恢复更快
无journal的节点需要从其他节点同步数据
29. 迁移中更新操作（重复）
同第23题，强调在数据迁移过程中更新的处理机制。
30. 复合索引顺序
索引匹配规则：
前缀匹配：索引
A:[B,C]支持查询A,A:[B]顺序敏感：不支持
A:[C,B]查询覆盖查询：只使用索引不访问文档
最佳实践：
根据查询模式设计索引顺序
使用
explain()分析索引使用
31. 分片故障查询（重复）
同第24题，强调分片故障时的查询行为和处理选项。
32. 存储过程支持
实现方式：
// 定义存储过程
db.system.js.save({_id: "hello",value: function(name) {return "Hello " + name;}
})// 调用存储过程
db.eval("hello('World')")使用场景：
复杂业务逻辑
减少网络往返
但性能需谨慎评估
33. GridFS 机制
设计原理：
文件分块：大文件分割为255KB的块
元数据存储：
fs.files集合存储文件信息数据存储：
fs.chunks存储文件块
优势：
突破16MB文档大小限制
支持流式读写
文件完整性校验
使用场景：
大文件存储（视频、图片、文档）
CDN替代方案
版本文件管理
总结
覆盖了MongoDB的核心概念，从基础理论到高级特性都有涉及。