MongoDB实战技巧：解决count错误与数字类型问题

"MongoDB使用小结，包括对count统计错误的处理、数字类型转换问题、restore数据时的索引创建注意事项以及namespace数量过多导致的问题及其解决方案。" 在使用MongoDB时，可能会遇到一些不常见的问题，这篇小结分享了四个关键点： 1. **count统计结果错误**：在MongoDB的分布式集群环境中，由于数据迁移，`count`命令可能返回不准确的结果，特别是在有孤儿文档或数据块迁移进行时。此时，应使用`aggregate`管道来正确地统计文档数量。例如，以下命令可以实现这个功能： ``` db.collection.aggregate([{$group: {_id: null, count: {$sum: 1}} }]) ``` 这是因为在分片集群中，`count`命令可能无法考虑到所有节点的状态。 2. **数字类型转换**：MongoDB Shell中的数字默认被视为双精度浮点数。因此，当你从数据库中读取一个32位整数并尝试更新后保存，即使数值不变，该整数也会被转换成浮点数。为了避免这种行为，可以在应用程序层面确保数据类型的一致性。 3. **restore数据到新DB时的索引处理**：在使用`mongorestore`恢复数据到新的数据库时，应避免预先创建索引。`mongorestore`工具会自动根据备份文件中的索引信息重建索引，这比先创建索引再恢复数据的效率要高得多。如果需要更改索引，应在数据恢复完成后执行。 4. **DB中的namespace数量过多**：当数据库（DB）中的集合（collection）数量达到一定限制时，可能会遇到无法创建新集合的问题，错误信息可能类似于“error: hashtablenamespaceindexmaxchainreached:1335”。这通常是由于DB内的collection个数过多导致的。根据实践经验，每个collection大约占用8KB空间，256MB的dbname.ns文件能支持大约36000个collection。可以使用`db.system.namespaces.count()`命令查看当前DB的collection数量。如果需要增加collection数量，可以通过调整`nssize`参数来增大dbname.ns文件的大小。 这些经验分享对于MongoDB的日常管理和问题排查非常有用，可以帮助用户避免一些常见的陷阱并提高操作效率。