MongoDB文档数据库代码重构：从烂代码到优雅代码

最近接手了一个用MongoDB的项目，代码写得非常烂，查询逻辑混乱，数据模型设计不合理，没有索引，性能很差，维护起来很痛苦。

这个项目，是前几年开发的，当时开发人员对MongoDB不熟悉，把MongoDB当成了关系型数据库来用，数据模型设计得很不合理，查询逻辑也很混乱，到处都是重复代码，没有错误处理，没有日志，没有索引，导致性能很差，一个简单的列表查询，要好几秒，数据量一大，就更慢了，用户投诉很多。

我花了两周的时间，对这个项目的MongoDB相关代码进行了重构，从数据模型设计、到查询优化、到索引优化、到代码结构、到错误处理、到性能监控，全面重构，代码变得优雅了很多，性能也提升了很多，列表查询从好几秒降到了几百毫秒，用户体验好了很多。

今天就来分享一下我的MongoDB代码重构实战经验，从烂代码的特征、到重构的思路和步骤、到数据模型设计最佳实践、到查询优化、到索引优化、到代码结构优化、到错误处理、到性能监控、再到踩坑和经验，详细分享，希望能给大家一些参考。

一、烂代码的特征

接手这个项目之后，我先对代码进行了全面的梳理，发现这个项目的MongoDB相关代码，有很多问题，典型的烂代码特征，主要有以下几个方面：

1. 数据模型设计不合理：

把MongoDB当成关系型数据库来用，数据模型设计得很范式化，拆成了很多小的集合，查询的时候要多次关联，性能很差。
该嵌入的不嵌入，该引用的不引用，比如，用户信息，每次查询文章都要再查一次用户集合，而不是把用户的基本信息嵌入到文章文档里。
字段命名不规范，有的用拼音，有的用英文，有的大小写混乱，维护起来很困难。
字段类型不统一，比如，同一个字段，有的存字符串，有的存数字，有的存布尔值，查询的时候很容易出问题。
没有版本控制，数据模型变更了，旧的数据没有迁移，导致查询的时候出错。

2. 查询逻辑混乱：

查询逻辑到处都是，没有封装，同一个查询，在不同的地方写了好几遍，重复代码很多，修改的时候要改很多地方，很容易漏改。
查询条件拼接混乱，用字符串拼接查询条件，很容易出错，也有注入风险。
没有分页，或者分页逻辑错误，有的用skip+limit，数据量大的时候性能很差。
没有排序，或者排序字段没有索引，性能很差。
查询了很多不需要的字段，每次都查整个文档，浪费带宽和内存。
没有使用聚合管道，复杂的查询，用多次查询+循环处理，性能很差。

3. 没有索引：

几乎没有索引，所有的查询都是全表扫描，数据量一大，性能就很差。
有的有索引，但是索引设计不合理，比如，在低基数字段上建索引，或者建了很多单字段索引，没有建复合索引，导致索引命中率低。
没有分析查询，不知道哪些查询慢，哪些字段需要索引，凭感觉建索引。

4. 代码结构混乱：

没有分层，业务逻辑、数据访问、控制层都混在一起，维护起来很困难。
没有封装MongoDB的操作，到处都是直接调用MongoDB的驱动API，更换驱动或者修改配置的时候，要改很多地方。
没有统一的错误处理，查询失败了，有的地方捕获了异常，有的地方没有，导致程序崩溃，或者错误信息不明确。
没有日志，查询成功失败都没有日志，出了问题很难排查。
没有配置管理，MongoDB的连接地址、数据库名、集合名等，都是硬编码在代码里，修改的时候要改代码，重新部署。

5. 性能问题：

因为没有索引，查询都是全表扫描，性能很差。
因为数据模型设计不合理，查询的时候要多次关联，性能很差。
因为没有分页，一次查询返回很多数据，占用很多内存和带宽，性能很差。
因为没有使用连接池，每次查询都新建连接，性能很差。
因为没有缓存，热点数据每次都查MongoDB，性能很差。

这些问题，导致这个项目的MongoDB相关代码，维护起来很痛苦，性能也很差，必须重构。

二、重构的思路和步骤

面对这么烂的代码，我没有急于改代码，而是先制定了重构的思路和步骤，分步骤进行，避免一步到位导致风险太大。

重构的思路和步骤，主要有以下几步：

1. 全面梳理和理解：

先全面梳理代码，理解业务逻辑，理解每个查询的用途，理解数据模型的设计。
梳理所有的MongoDB操作，包括查询、插入、更新、删除，统计有多少个操作，分别在什么地方。
分析慢查询，找出性能瓶颈，哪些查询慢，为什么慢。
梳理数据模型，每个集合有哪些字段，字段类型是什么，数据量有多大，关联关系是什么。

这一步很重要，只有全面理解了代码和业务，才能做好重构，避免改出问题。

2. 制定重构计划：

根据梳理的结果，制定重构计划，分模块、分步骤进行，先重构哪个模块，再重构哪个模块，每个模块重构什么内容。
制定数据模型重构计划，哪些集合需要合并，哪些字段需要嵌入，哪些字段需要引用，怎么迁移旧数据。
制定索引优化计划，哪些查询需要建索引，建什么索引，复合索引的字段顺序是什么。
制定代码结构重构计划，怎么分层，怎么封装，怎么统一错误处理和日志。
制定测试计划，重构后怎么测试，怎么验证功能正常，性能提升。
制定回滚计划，如果重构出问题，怎么快速回滚。

3. 先优化数据模型和索引：

先优化数据模型，因为数据模型是基础，数据模型设计好了，查询和代码才能优化好。
然后优化索引，因为索引对性能的影响最大，先把索引加上，性能就能提升很多，也能为后续的代码重构提供基础。
数据模型和索引优化后，要做数据迁移，把旧的数据迁移到新的模型，并且要兼容旧的数据，避免迁移过程中出问题。

4. 再重构代码结构：

数据模型和索引优化好之后，再重构代码结构，分层、封装、统一错误处理和日志。
先封装MongoDB的操作，封装一个数据访问层，所有的MongoDB操作都通过这个层来做，不要直接调用驱动API。
然后把查询逻辑封装到Repository层，每个集合对应一个Repository，封装这个集合的所有查询，业务层调用Repository，不要直接写查询逻辑。
然后统一错误处理和日志，所有的MongoDB操作，都要捕获异常，记录日志，返回统一的错误信息。
最后优化查询逻辑，用聚合管道替代多次查询+循环处理，用投影只查询需要的字段，用正确的分页方式，等等。

5. 测试和验证：

重构过程中，每一步都要测试，验证功能正常，没有引入新的bug。
重构完成后，要做全面的测试，包括功能测试、性能测试、压力测试，验证功能正常，性能提升。
要对比重构前后的性能，看看性能提升了多少，有没有达到预期。
要做灰度发布，先让一部分流量用新的代码，观察一段时间，没有问题，再全量发布。

6. 持续优化：

重构不是一劳永逸的，重构完成后，还要持续优化，监控性能，发现慢查询，及时优化。
要建立代码规范，后续的开发，都要按照规范来，避免又写出烂代码。
要定期review代码，发现问题及时纠正。

三、数据模型设计最佳实践

数据模型设计，是MongoDB性能和可维护性的基础，好的数据模型设计，能让MongoDB发挥最大的性能，也能让代码更易维护。

MongoDB的数据模型设计，和关系型数据库不一样，关系型数据库讲究范式化，尽量减少冗余，而MongoDB是文档数据库，讲究反范式化，适当冗余，减少关联，提高查询性能。

MongoDB数据模型设计的核心，是"嵌入还是引用"的问题，也就是，数据是嵌入到当前文档里，还是用引用关联到其他集合。

嵌入（Embedding）的适用场景：

数据之间是"包含"关系，比如，文章的评论，订单的商品项，用户的地址，这些数据，都是属于主文档的，应该嵌入到主文档里。
数据经常一起查询，比如，查询文章的时候，经常需要查询作者的基本信息，就可以把作者的基本信息嵌入到文章文档里，避免每次都查用户集合。
数据不经常变化，比如，作者的用户名、头像，这些信息不经常变化，嵌入到文章文档里，即使变化了，也可以批量更新，或者接受一定的不一致。
数据量不大，比如，一篇文章的评论，不会太多，嵌入到文章文档里，不会导致文档太大。

引用（References）的适用场景：

数据之间是"独立"的关系，比如，用户和文章，用户是独立的，文章也是独立的，应该用引用关联。
数据经常变化，比如，用户的详细信息，经常变化，如果嵌入到文章文档里，每次变化都要更新所有的文章，很麻烦，应该用引用。
数据量很大，比如，一篇文章的评论，如果评论很多，嵌入到文章文档里，会导致文档太大，影响性能，应该用引用，单独存一个评论集合。
数据需要独立查询，比如，用户信息，需要独立查询，不应该嵌入到其他文档里，应该用引用，单独存一个用户集合。

数据模型设计的最佳实践：

根据查询模式设计数据模型： 数据模型设计，要根据查询模式来设计，而不是根据数据的关系来设计。先分析业务的查询模式，哪些数据经常一起查询，哪些数据需要独立查询，然后根据查询模式，决定是嵌入还是引用。

适当冗余，减少关联： MongoDB是文档数据库，要适当冗余，减少关联，提高查询性能。比如，查询文章的时候，经常需要作者的用户名和头像，就可以把用户名和头像冗余到文章文档里，避免每次都查用户集合。冗余的字段，要选择不经常变化的字段，避免频繁更新。

控制文档大小： MongoDB的文档，最大是16MB，虽然很大，但是也不要让文档太大，文档太大，会影响查询性能，占用更多的内存和带宽。如果嵌入的数据量很大，比如评论很多，应该用引用，单独存一个集合。

字段命名规范： 字段命名要规范，统一用英文，小驼峰或者下划线，不要用拼音，不要大小写混乱。字段名要简洁明了，不要太长，因为字段名也会存储在每个文档里，太长会占用更多的存储空间。

字段类型统一： 同一个字段，类型要统一，不要有的存字符串，有的存数字，有的存布尔值，否则查询的时候很容易出问题，也会影响索引的效果。

使用合适的字段类型： 要使用合适的字段类型，比如，时间用Date类型，不要用字符串；ID用ObjectId类型，不要用字符串；数字用Number类型，不要用字符串。合适的字段类型，能提高查询性能，也能减少存储空间。

添加版本字段： 数据模型会变化，建议在文档里添加一个版本字段，比如schemaVersion，标记文档的版本，数据模型变更的时候，可以根据版本字段，迁移旧的数据，避免查询的时候出错。

避免无限增长的数组： 不要在文档里使用无限增长的数组，比如，把所有的评论都嵌入到文章文档里，评论会越来越多，导致文档越来越大，影响性能。如果数组会无限增长，应该用引用，单独存一个集合。

四、查询优化

数据模型设计好之后，就要优化查询逻辑，提高查询性能。

MongoDB查询优化的最佳实践，主要有以下几个方面：

1. 只查询需要的字段（投影Projection）：

不要每次都查整个文档，只查询需要的字段，用投影（Projection）指定需要的字段，减少数据传输和内存使用。
比如，列表页只需要文章的标题、摘要、封面、作者、发布时间，就只查询这些字段，不要查询文章的内容，因为内容很大，会影响性能。
用法：db.collection.find(query, { title: 1, summary: 1, cover: 1, author: 1, createdAt: 1 })

2. 使用正确的分页方式：

不要用skip() + limit()做分页，特别是数据量大的时候，skip()会跳过前面的所有文档，性能很差，数据量越大，性能越差。
推荐用"游标分页"，也就是用上一页最后一条数据的某个字段（比如ID、时间）作为游标，查询下一页，这样可以利用索引，性能很好，数据量再大也不怕。
用法：第一页db.collection.find().sort({ id: 1 }).limit(10)，下一页db.collection.find({ id: { $gt: lastId } }).sort({ _id: 1 }).limit(10)
如果需要跳页，比如直接跳到第100页，那只能用skip()，但是要限制最大跳页数，避免跳得太远导致性能差。

3. 排序字段要有索引：

排序的字段，一定要有索引，否则MongoDB会把所有的查询结果加载到内存中排序，数据量大的时候，性能很差，甚至会因为内存不足而报错。
如果是复合索引，排序字段的顺序，要和索引的顺序一致，或者是索引的前缀，这样才能利用索引排序。
尽量避免在多个字段上排序，除非有对应的复合索引。

4. 使用聚合管道（Aggregation Pipeline）：

复杂的查询，比如分组、统计、多步处理，不要用多次查询+循环处理，要用聚合管道，MongoDB的聚合管道性能很好，能在数据库端完成复杂的处理，减少数据传输和应用端的处理。
聚合管道的阶段，要注意顺序，把能过滤数据的阶段（比如$match、$limit）放在前面，减少后续阶段处理的数据量，提高性能。
$match阶段要尽量利用索引，把$match放在管道的最前面，这样可以利用索引过滤数据。
常用的聚合阶段：$match（过滤）、$project（投影）、$group（分组）、$sort（排序）、$limit（限制数量）、$skip（跳过）、$lookup（关联查询）、$unwind（展开数组）等。

5. 合理使用$lookup：

MongoDB 3.2+支持$lookup，可以做关联查询，类似关系型数据库的JOIN，但是$lookup的性能不是很好，要谨慎使用。
能用嵌入解决的，就不要用$lookup，嵌入的性能比$lookup好很多。
如果必须用$lookup，要注意，$lookup的左集合和右集合，都要有索引，特别是关联字段，要有索引，否则性能很差。
$lookup会把关联的数据嵌入到结果文档里，要注意结果文档的大小，不要超过16MB。

6. 避免全表扫描：

查询条件，要尽量利用索引，避免全表扫描。可以用explain()分析查询，看看是不是用了索引，扫描了多少文档，返回了多少文档。
如果查询条件里有$or，要注意，$or的每个条件，都要有索引，否则会全表扫描。
如果查询条件里有$ne、$not、$exists、$type等，这些操作符通常不能利用索引，会导致全表扫描，要尽量避免，或者用其他方式替代。
如果查询条件里有正则表达式$regex，要注意，只有前缀匹配的正则（比如/^abc/）才能利用索引，其他的正则都会全表扫描，要尽量避免，或者用全文索引替代。

7. 控制返回的数据量：

一次查询，不要返回太多的数据，要用limit()限制返回的数量，避免占用太多的内存和带宽。
如果需要处理大量的数据，比如批量更新、批量导出，要用游标（Cursor）分批处理，不要一次把所有数据都加载到内存里，否则会内存溢出。
用法：const cursor = db.collection.find(query); while (cursor.hasNext()) { const doc = cursor.next(); // 处理 }

8. 使用全文索引做文本搜索：

如果需要做文本搜索，比如搜索文章的标题和内容，不要用正则表达式，要用全文索引（Text Index），全文索引的性能比正则好很多，还支持分词、权重、排序等功能。
用法：创建全文索引db.collection.createIndex({ title: "text", content: "text" })，查询db.collection.find({ $text: { $search: "关键词" } })

五、索引优化

索引是MongoDB性能优化的关键，好的索引设计，能让查询性能提升几个数量级。

MongoDB索引优化的最佳实践，主要有以下几个方面：

1. 为常用查询建索引：

分析常用的查询，为查询条件、排序字段、聚合管道的$match字段，建立合适的索引。
不要凭感觉建索引，要用explain()分析查询，看看哪些查询慢，哪些查询是全表扫描，然后针对性地建索引。
也可以开启MongoDB的慢查询日志，记录慢查询，然后分析慢查询，建索引。

2. 复合索引的字段顺序：

复合索引的字段顺序，非常重要，要遵循"等值过滤在前，范围过滤在后，排序字段最后"的原则。
等值过滤的字段（比如{ status: "published" }），放在前面，因为等值过滤可以利用索引快速定位。
范围过滤的字段（比如{ createdAt: { $gte: start } }），放在中间，因为范围过滤会影响后面字段的索引使用。
排序字段（比如sort({ createdAt: -1 })），放在最后，并且排序方向要和索引方向一致（或者相反，因为MongoDB可以反向遍历索引）。
比如，查询{ status: "published", createdAt: { $gte: start } }，排序{ createdAt: -1 }，复合索引应该是{ status: 1, createdAt: -1 }。

3. 索引选择性：

索引的选择性，是指索引字段的不同值的比例，不同值越多，选择性越高，索引效果越好。
要在高选择性的字段上建索引，比如用户ID、文章ID、用户名、邮箱等，这些字段的不同值很多，选择性高，索引效果好。
不要在低选择性的字段上建索引，比如性别、状态、类型等，这些字段的不同值很少，选择性低，索引效果不好，甚至不如全表扫描。
如果低选择性的字段，经常和其他高选择性的字段一起查询，可以建复合索引，把低选择性的字段放在前面，高选择性的字段放在后面。

4. 覆盖索引（Covered Index）：

如果一个索引，包含了查询需要的所有字段，包括查询条件、投影字段、排序字段，那么这个索引就是覆盖索引，查询可以直接从索引中获取所有数据，不需要回表（访问文档），性能非常好。
要尽量设计覆盖索引，让查询只需要访问索引，不需要回表，提高性能。
可以用explain()查看查询是不是覆盖索引，如果totalDocsExamined是0，说明是覆盖索引。

5. 避免太多索引：

索引不是越多越好，索引会占用存储空间，也会降低写入的性能，因为插入、更新、删除的时候，要同时更新所有的索引。
要合理控制索引的数量，只在需要的字段上建索引，删除不必要的索引、重复的索引、很少使用的索引。
可以用$indexStats查看索引的使用情况，找出很少使用的索引，删除它们。

6. 数组字段的索引：

如果在数组字段上建索引，MongoDB会为数组中的每个元素，创建一个索引条目，这叫多键索引（Multikey Index）。
多键索引会占用更多的存储空间，也会降低写入的性能，要谨慎使用。
一个复合索引，最多只能有一个数组字段，否则索引条目会爆炸式增长。
如果数组很大，不建议在数组字段上建索引，性能不好。

7. TTL索引：

如果有需要自动过期的数据，比如日志、验证码、临时数据等，可以用TTL索引（Time-To-Live Index），MongoDB会自动删除过期的数据，不需要手动清理。
用法：在Date字段上建TTL索引，指定过期时间，比如db.collection.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 })，表示createdAt之后3600秒（1小时）过期。

8. 唯一索引：

如果字段的值是唯一的，比如用户名、邮箱、手机号等，可以建唯一索引（Unique Index），保证字段的值不重复，也能提高查询性能。
用法：db.collection.createIndex({ username: 1 }, { unique: true })
注意，唯一索引的字段，不能有多个null值，因为MongoDB认为null也是一个值，多个null会重复。如果字段可能为null，要用稀疏索引（Sparse Index），或者部分索引（Partial Index）。

六、代码结构优化

数据模型和索引优化好之后，就要重构代码结构，让代码更优雅、更易维护。

MongoDB代码结构优化的最佳实践，主要有以下几个方面：

1. 分层架构：

采用分层架构，把代码分成控制层（Controller）、业务层（Service）、数据访问层（Repository/DAO），每层职责明确，解耦。
控制层：负责接收请求，参数校验，调用业务层，返回响应。
业务层：负责业务逻辑，事务控制，调用数据访问层。
数据访问层：负责MongoDB的操作，封装查询、插入、更新、删除，业务层调用数据访问层，不要直接写MongoDB操作。
分层架构的好处是，职责明确，易维护，易测试，更换数据库或者驱动的时候，只需要改数据访问层，不需要改业务层和控制层。

2. 封装MongoDB连接：

封装MongoDB的连接管理，用单例模式，只创建一次MongoClient，复用连接，不要每次查询都新建连接。
封装连接配置，从配置文件读取连接地址、数据库名、用户名、密码等，不要硬编码在代码里。
配置连接池，设置合适的连接池大小，根据并发量调整，避免连接数不够或者太多。
监听连接事件，连接失败、重连、超时等，记录日志，及时告警。

3. 封装Repository层：

每个集合对应一个Repository类，封装这个集合的所有操作，包括查询、插入、更新、删除，业务层调用Repository，不要直接写MongoDB操作。
Repository类里，封装常用的操作，比如根据ID查询、分页查询、条件查询、插入、更新、删除等，避免重复代码。
复杂的查询，也封装在Repository里，业务层只需要调用方法，传参数，不需要关心查询怎么写。
Repository层，要统一错误处理，捕获MongoDB的异常，记录日志，抛出统一的业务异常，不要把MongoDB的异常直接抛给业务层。

4. 统一错误处理：

所有的MongoDB操作，都要捕获异常，不要让异常直接抛到最上层，导致程序崩溃。
定义统一的业务异常，比如DatabaseException、NotFoundException、DuplicateKeyException等，把MongoDB的异常，转换成业务异常，抛给上层。
错误信息要友好，不要把MongoDB的原始错误信息直接返回给用户，避免泄露敏感信息，也避免用户看不懂。
记录详细的错误日志，包括错误信息、堆栈、查询条件、参数等，方便排查问题。

5. 统一日志：

所有的MongoDB操作，都要记录日志，包括查询条件、参数、耗时、结果数量、错误信息等，方便排查问题和性能分析。
慢查询要单独记录，或者告警，超过一定时间的查询，记录警告日志，及时优化。
日志级别要合理，正常的查询用debug级别，慢查询用warn级别，错误用error级别，避免日志太多，也避免重要信息被淹没。

6. 配置管理：

MongoDB的配置，比如连接地址、数据库名、用户名、密码、连接池大小、超时时间等，都要放在配置文件里，不要硬编码在代码里。
不同的环境（开发、测试、生产），用不同的配置文件，不要混在一起。
敏感信息，比如用户名、密码，要加密存储，不要明文放在配置文件里。

7. 数据访问层的代码规范：

查询条件，要用对象构造，不要用字符串拼接，避免出错和注入风险。
变量命名要规范，有意义，不要用a、b、c这种无意义的名字。
函数要单一职责，一个函数只做一件事，不要写太长的函数。
注释要清晰，复杂的查询，要加注释，说明查询的用途和逻辑。
统一代码风格，比如缩进、空格、换行，保持一致，易读易维护。

七、性能监控和持续优化

重构完成后，还要做好性能监控和持续优化，保证MongoDB的性能稳定。

1. 开启慢查询日志：

开启MongoDB的慢查询日志（Profiler），记录慢查询，分析慢查询，及时优化。
可以设置慢查询的阈值，比如超过100ms的查询，记录下来，定期分析。
用法：db.setProfilingLevel(1, { slowms: 100 })，表示记录超过100ms的查询。

2. 监控MongoDB的性能指标：

监控MongoDB的性能指标，比如查询QPS、响应时间、连接数、内存使用、磁盘IO、索引命中率、慢查询数量等，及时发现性能问题。
可以用MongoDB自带的监控工具，比如mongostat、mongotop，也可以用第三方监控工具，比如Prometheus + Grafana，Zabbix等。
设置告警阈值，指标异常的时候，及时告警，通知开发人员处理。

3. 定期分析查询：

定期分析查询，用explain()分析慢查询，看看是不是用了索引，扫描了多少文档，返回了多少文档，有没有优化空间。
定期查看索引的使用情况，用$indexStats查看每个索引的使用次数，找出很少使用的索引，删除它们，减少存储空间和写入开销。
定期查看数据量的增长，数据量增长很快的集合，要提前优化，避免性能下降。

4. 定期维护：

定期做数据清理，删除不需要的数据，比如过期的日志、临时数据，避免数据量越来越大，影响性能。
定期做索引重建，索引用久了，可能会有碎片，重建索引可以提高索引的性能，减少存储空间。
定期做数据备份，保证数据安全，出了问题可以恢复。

5. 建立代码规范：

建立MongoDB的代码规范，包括数据模型设计规范、查询规范、索引规范、代码结构规范等，后续的开发，都要按照规范来，避免又写出烂代码。
定期review代码，发现问题及时纠正，保证代码质量。
团队培训，让团队成员都了解MongoDB的最佳实践，提高团队的技术能力。

八、踩坑经验

在重构的过程中，我也踩了一些坑，在这里分享一下，希望大家能避免。

1. 数据迁移的坑：

数据模型变更后，需要迁移旧的数据，我一开始写了迁移脚本，但是没有考虑到数据量很大，迁移脚本跑了很久，而且中途失败了，导致数据不一致。
后来，我把迁移脚本改成了分批迁移，每次迁移1000条，记录迁移进度，失败了可以从断点继续，而且迁移过程中，兼容旧的数据模型，新老代码都能跑，迁移完成后，再切换到新的代码。
经验：数据迁移要分批，记录进度，支持断点续传，迁移过程中要兼容旧数据，避免数据不一致。

2. 索引的坑：

我一开始加了很多索引，觉得索引越多越好，结果发现写入性能下降了很多，而且很多索引根本没用上。
后来，我用$indexStats查看索引的使用情况，删除了很少使用的索引，只保留常用的索引，写入性能就恢复了。
经验：索引不是越多越好，要合理控制索引数量，定期查看索引使用情况，删除没用的索引。

3. 分页的坑：

我一开始用skip() + limit()做分页，数据量小的时候没问题，数据量一大，第几十页、几百页的时候，查询就很慢，甚至超时。
后来，我改成了游标分页，用上一页最后一条的ID作为游标，查询下一页，性能就很好了，数据量再大也不怕。
经验：数据量大的时候，不要用skip()分页，要用游标分页，性能好很多。

4. 文档大小的坑：

我一开始把评论都嵌入到文章文档里，觉得这样查询快，结果评论越来越多，有的文章文档超过了几MB，查询的时候很慢，占用很多内存。
后来，我把评论拆出来，单独存一个评论集合，用文章ID关联，文章文档里只存评论数量，性能就好了很多。
经验：不要在文档里嵌入无限增长的数组，数据量大了会导致文档太大，影响性能，应该用引用，单独存集合。

5. 连接池的坑：

我一开始没有配置连接池，每次查询都新建连接，性能很差，而且连接数很快就满了，导致查询排队，甚至超时。
后来，我配置了连接池，设置合适的连接池大小，复用连接，性能就好了很多，连接数也稳定了。
经验：一定要用连接池，配置合适的连接池大小，复用连接，提高性能，避免连接数满。

6. 错误处理的坑：

我一开始没有做统一的错误处理，有的地方捕获了异常，有的地方没有，导致查询失败的时候，程序直接崩溃，或者错误信息不明确，很难排查。
后来，我做了统一的错误处理，所有的MongoDB操作都捕获异常，记录日志，抛出统一的业务异常，程序就稳定了，出了问题也很好排查。
经验：一定要做统一的错误处理，捕获异常，记录日志，避免程序崩溃，也方便排查问题。

写在最后

MongoDB文档数据库代码重构：从烂代码到优雅代码。

经过两周的重构，这个项目的MongoDB相关代码，从烂代码变成了优雅代码，性能也提升了很多，列表查询从好几秒降到了几百毫秒，用户体验好了很多，维护起来也轻松了很多。

这次重构，我最大的体会是，MongoDB是一个灵活的文档数据库，但是灵活不代表可以随便设计，好的数据模型和代码结构，能让MongoDB发挥最大的性能，也能让代码更易维护。很多人用MongoDB性能差，不是MongoDB的问题，而是数据模型设计不合理，查询写得不好，没有索引，代码结构混乱。

重构不是一件容易的事，需要耐心，需要细心，需要分步骤进行，不能急于求成。但是，只要方法对，步骤对，就能把烂代码重构成优雅代码，提升性能，提升可维护性。

希望我的经验，能给大家一些参考，让大家在使用MongoDB的时候，少踩坑，写出优雅的代码，发挥MongoDB的最大性能。

最后，用一句话结尾：

"代码是写给人看的，顺便给机器执行。好的代码，不仅要能跑，还要易读、易维护、性能好。重构烂代码，是每个程序员的必修课，也是提升代码质量和技术能力的重要途径。"

祝大家都能写出优雅的代码，构建高性能、易维护的系统！