2dsphere索引比2d更适合真实地理坐标，因其基于球面几何计算大圆距离（米），支持跨本初子午线查询，而2d将地球视为平面导致大范围偏差；需用point格式（经度在前）、校验坐标范围，并显式创建"2dsphere"索引。
为什么2dsphere索引比2d更适合真实地理坐标？
因为2d索引把地球当平面，用欧氏距离算“直线”，在经纬度跨度大时偏差严重，甚至返回错误结果；2dsphere基于球面几何，直接支持$geoWithin、$near等操作，计算的是真实大圆距离（单位：米），且能正确处理本初子午线、国际日期变更线附近的跨区查询。
常见错误现象：db.places.find({loc: {$near: [116.4, 39.9]}}) 在2d索引下可能漏掉北京西边的点——不是性能问题，是数学模型错了。
- 必须确保地理字段是
{type: "Point", coordinates: [lon, lat]}格式（注意：先经度后纬度） - 插入前不校验坐标范围，会静默失败：经度必须∈[−180, 180]，纬度∈[−90, 90]
- 索引创建命令必须显式指定
"2dsphere"类型：db.places.createIndex({"loc": "2dsphere"})，不能省略引号或写成2dsphere（无引号会被当作变量）
如何让$near查询真正快起来？
$near本身强制走2dsphere索引，但速度慢往往是因为没加限制或字段设计不合理。
- 永远带上
$maxDistance（单位：米）：{loc: {$near: {$geometry: {type: "Point", coordinates: [116.4, 39.9]}, $maxDistance: 5000}}。不设上限时，MongoDB可能扫描大量远距离文档再排序，I/O暴涨 - 避免在
$near查询中混用非地理条件（如{"status": "active"}）却不建复合索引——单靠2dsphere索引无法加速状态过滤，得建db.places.createIndex({"loc": "2dsphere", "status": 1}) - 如果只查“附近有哪些”，用
$geoWithin+$centerSphere比$near更轻量：{loc: {$geoWithin: {$centerSphere: [[116.4, 39.9], 5/6371]}}（5公里半径，注意单位是弧度）
聚合管道里做地理筛选，为什么$geoNear必须放第一阶段？
$geoNear是唯一能利用2dsphere索引并输出距离字段的聚合阶段，但它有硬性限制：必须是$pipeline的第一个$stage，且只能出现一次。
错误示例：[{$match: {type: "cafe"}}, {$geoNear: {...}}] → 直接报错"geoNear must be the first stage"。
- 正确写法：把过滤条件挪进
$geoNear的query字段：{$geoNear: {near: {...}, distanceField: "dist", query: {type: "cafe"}, maxDistance: 1000}} - 若需后续按距离分页，必须用
$limit而非skip——$geoNear已按距离排好序，$skip会丢弃大量已计算距离的文档，浪费CPU -
distanceField生成的字段单位是米，但精度受球面模型和索引粒度影响，
数据量大时，2dsphere索引体积和构建时间怎么控？
2dsphere索引比普通B-tree大得多，因为它把每个点转成多个GeoHash格网（默认精度26级），100万点索引常达500MB+，重建耗时明显。
- 上线前用
db.collection.stats()检查indexDetails里的size和count，预估增长趋势 - 不要在业务高峰期运行
createIndex，加{background: true}参数可避免锁表，但构建时间延长30%~50% - 如果只需城市级粗略搜索（比如“上海周边50km”），可降精度：
db.places.createIndex({"loc": "2dsphere"}, {"2dsphereIndexVersion": 2, "2dsphereIndexMaxPrecision": 22})，体积减少约40%，但最短可分辨距离从~1米退化到~20米
真正卡住性能的，往往不是索引类型选错，而是忘了$maxDistance或把地理字段存成[lat, lon]顺序——MongoDB认死理，顺序错就找不到任何点。
