在MongoDB的日常使用中，一个高频问题是：明明存进去的是数字，查出来却查不到？或者金额字段用了Double，计算结果出现0.30000000000000004这种诡异的尾数？这些问题的根源大多不在查询语句，而在于数据类型的选择和使用方式。MongoDB基于BSON文档格式存储数据，类型系统比关系数据库灵活得多，但灵活性带来的代价就是类型混乱的坑也更多。这篇文章把MongoDB的常用数据类型、选型思路和常见坑一次说清楚，建议收藏备用。
一、MongoDB支持哪些数据类型
MongoDB底层使用BSON（Binary JSON）作为文档存储格式，BSON在JSON的基础上扩展了类型系统。用db.collection.insertOne()插入文档时，每个字段的类型由写入时的值自动决定，MongoDB不会预先定义表结构，这也是它和传统关系型数据库最大的区别之一。
常用的BSON类型包括：字符串String、整数Int32、长整数Int64、双精度浮点数Double、高精度小数Decimal128、布尔Boolean、日期Date、对象ID ObjectId、数组Array、内嵌文档Object、二进制BinData、正则表达式Regex、空值Null、时间戳Timestamp等。可以在mongo shell中用typeof快速查看字段类型：
// 查看字段类型
db.users.findOne().name // 返回值本身
typeof db.users.findOne().name // 返回 "string"
typeof db.users.findOne().age // 返回 "number"
// 查看BSON真实类型（注意是大写的$type）
db.users.aggregate([
{ $project: { ageType: { $type: "$age" } } }
])
// 可能返回 "int"、"double"、"long" 等需要特别注意的是，JavaScript的number只有一种双精度浮点类型，所以在旧版mongo shell中直接写db.users.insertOne({age: 25})，age存进去很可能是double而不是int。新版mongosh以及各语言的驱动程序会根据数值大小和语言类型自动选择Int32、Int64或Double，但旧shell的这个行为坑过不少人，排查类型问题时一定要用$type确认真实存储类型。
二、数值类型怎么选：Double、Int还是Decimal128
数值类型是选型错误的重灾区。三种常用数值类型各有适用场景：Int32适合状态码、计数、ID等整数值，范围约正负21亿；Int64适合更大的整数，比如时间戳毫秒值、雪花算法ID；Double适合科学计算、评分等对精度不敏感的场景；Decimal128则是专门为金融金额场景准备的，提供34位十进制有效数字精度。
金额字段用Double是最典型的错误。Double是二进制浮点数，0.1和0.2都无法精确表示，相加结果自然带尾巴：
// Double的问题
db.orders.insertOne({ price: NumberDouble(0.1), count: NumberDouble(0.2) })
db.orders.aggregate([
{ $project: { total: { $add: ["$price", "$count"] } } }
])
// total = 0.30000000000000004，金额对不上账
// 正确做法：金额用Decimal128
db.orders.insertOne({ price: NumberDecimal("0.1"), count: NumberDecimal("0.2") })
db.orders.aggregate([
{ $project: { total: { $add: ["$price", "$count"] } } }
])
// total = NumberDecimal("0.3")，精确无误注意NumberDecimal("0.1")必须传字符串参数。如果写成NumberDecimal(0.1)，0.1会先被JavaScript转成有误差的double再包装，精度损失已经发生，等于白用。另外还有一条常见的工程建议：如果不想引入Decimal128，也可以把金额以"分"为单位存成Int64，彻底避开小数问题，但要注意读写两端的换算一致性。
还有一个隐秘的坑：Double和Int在比较时可以隐式转换，db.users.find({age: 25})既能匹配int的25也能匹配double的25.0，所以查询一般不出问题。但类型不同会导致索引统计不准确、分片键哈希分布异常等问题，尽量保证同一字段在所有文档中类型一致。
三、日期、ObjectId与内嵌结构的注意事项
Date类型在MongoDB中存储为64位整数，表示Unix纪元以来的毫秒数，且永远是UTC时区。写入时如果直接传字符串或者用ISODate()，存储的都是UTC时间。坑在于：应用端在东八区，写入"2024-06-01 00:00:00"本地时间，如果没做时区转换，实际存的是UTC的8点还是0点完全取决于驱动层怎么处理。查询某一天的数据时范围边界就容易差8小时。建议统一约定：所有Date字段一律由应用层先转成UTC或统一用毫秒时间戳存储，展示时再转本地时区。
// 日期查询的正确姿势：明确时区
db.logs.find({
createTime: {
$gte: ISODate("2024-06-01T00:00:00Z"),
$lt: ISODate("2024-06-02T00:00:00Z")
}
})
// 聚合时指定时区做按天分组
db.logs.aggregate([
{
$group: {
_id: { $dateToString: { format: "%Y-%m-%d", date: "$createTime", timezone: "+08:00" } },
count: { $sum: 1 }
}
}
])ObjectId是MongoDB默认的主键类型，12字节由4字节时间戳、5字节随机值、3字节递增计数器组成，天然按时间递增，做范围查询和排序时比UUID友好。但要注意它的尾部计数器只在单进程内递增，多实例并发写入时并非严格有序。如果业务对排序要求极高，还是应该显式增加业务时间字段。另外不要手动构造ObjectId来"还原"创建时间，跨秒精度场景下误差不可控。
数组和内嵌文档是MongoDB的招牌能力，但数组字段上只要建了索引就会自动变成多键索引，查询时如果一个数组的元素个数达到几十万，这个文档的索引条目会爆炸式增长，严重影响写入性能。数组适合存少量标签、少量商品项；数据量大、更新频繁的场景应该拆成独立集合。内嵌文档查询时要注意点号路径"address.city"必须加引号，写成{address.city: "北京"}在多数驱动里直接报语法错误。
四、类型混乱的排查与避坑清单
MongoDB是弱Schema的，同一个字段在不同文档里可以是不同类型，这在排查线上问题时极其痛苦。比如age字段有的文档存int，有的存字符串"25"，那么find({age: {$gt: 20}})只会匹配数值类型，字符串类型的文档会静默漏掉，不报任何错。这类问题通常来自接口入参没有做类型校验，前端传了字符串就直接落库。
排查手段是用$type统计字段类型分布：
// 查看某字段都存了哪些类型
db.users.aggregate([
{ $group: { _id: { $type: "$age" }, count: { $sum: 1 } } }
])
// 如果返回 missing、string、int、double 多种，说明类型已经混乱
// 批量把字符串数字转回数值（先备份再执行）
db.users.updateMany(
{ age: { $type: "string" } },
[ { $set: { age: { $toInt: "$age" } } } ]
)最后整理一份避坑清单：第一，金额一律Decimal128或整数分值，绝不用Double直接存钱；第二，同一业务字段全库统一类型，写入前在应用层做强校验；第三，日期统一UTC，查询时显式带时区；第四，大数组不要建索引，考虑拆集合；第五，旧版mongo shell写入的数值要确认真实类型；第六，上线前用$type聚合扫一遍核心字段的类型分布，把混乱扼杀在早期。如果需要在写入层面强制约束结构，可以配合MongoDB 3.6以上的JSON Schema校验功能，给集合加上$jsonSchema验证器，从源头堵住类型不一致的问题。把这些规则落实到位，MongoDB的灵活性才会真正成为优势而不是负担。
MongoDB数据类型BSON类型MongoDB ObjectId修改时间：2026-09-14 09:57:07