为什么索引等相同下,数据量到达一定量级时候， 会听说 mongodb 比 mysql 快.

[cs8814336]

一直没理解为什么当数据量达到一定程度时，mysql 会很慢，mongodb 会更快．以至于我到现在还没理解什么时候用 mongodb，什么时候用 mysql，不清楚两者的优势(底层原理优势).

从开发速度来讲，mysql 现在支持 json 字段，在一定角度来看一个表有了 json 字段就跟 mongodb 文档结构开发起来差不多方便了．

从底层原理看: mysql innodb 使用 b+tree, mongdb 默认使用 wiredtiger 使用 b-tree. b-tree 和 b+tree 有各自的优点，例如 b-tree 查询不一定需要找到叶子节点才能结束所以速度会快，但是 b+tree 能通过不存储数据的节点更快区分数据．

所以我想问大家 mongdb wiredtiger 能有什么 mysql innodb 没有的功能或者优势，底层原理原因又是什么. 就是某种因为底层设计的原因，根本导致了某些功能是别的数据库是不能有的，例如说便捷的文档结构之前 mysql 没有，但是这个可能不是底层设计导致的，只是 mysql 懒了，只要等到某天有人加上了这个功能就可以了.

提前感谢大家的回答．

[cs8814336]

@petelin mongodb 现在也支持事务，mysql 也支持 json 结构了

[cs8814336]

@bumz 感谢回答．这个我是赞成的，自从我陷入这个主题的追索之中我就尝试通过往这个方向想，来跳出这条路

[itskingname]

@jorneyr 在 MongoDB 里面使用 aggregate 配合$lookup 关键字就可以实现联集合查询。

[passerbytiny]

mysql 是关系型数据库，mongodb 是 NoSql 数据库。虽然 NoSql 在早期推广的时候总是提对象数据库要替代关系数据库，但是现在架构师一般同时使用二者。楼主可以结案了。

[cs8814336]

@itskingname 感谢回答，其实现在 mysql 和 mongodb 互相很多功能都有相互实现了，但是楼上很多的回答都只是停留在很久以前的思维．有人会说实现也只是一部分或者速度没那么好，但是是因为该数据库开发者懒而已吗？还是说是因为底层的某些原因导致了他不可能实现得有别人好呢？　更细的没指出

[gnozix]

MongoDB 的需要多表联查的地方直接爆炸，我们涉及多表的地方都使用 pg 了，以查询为主的地方还是 MongoDB 用起来舒服。

[cs8814336]

@passerbytiny 感谢回答．是啊，我以前的公司也是 2 个都使用，而且在同一个场景的 2 套数据一个使用了 mysql 一个使用 mongodb. 具体是没事务的，只是用来存放游戏设备激活数据．　那假如不需要事务，为什么 mongodb 会比 mysql 快呢，我现在暂定看到一个文章只是说了 b-tree 不需要每次遍历到叶子节点，b+tree 则需要．但是这也是有可能，不是平均情况，是很模糊的. 所以到底是什么场景用什么,而为什么不能用另外一个,还是一头雾水

[EPr2hh6LADQWqRVH]

很多人鹦鹉学舌， “ MySQL 是关系型，MongoDB 是非关系型”， 根本没有思考， 手里有个锤子，一切看起来就都像钉子

首先必须明确，这个世界上是没有魔法的，想要实现一定的功能，路径很大程度上是相似的。在数据库这个领域，无非就是各类索引树，缓存这种平淡无奇的东西。

以我的观点，SQL 世界和 MongoDB 的分歧主要是理解数据的方式不一样，SQL 以表的形式理解，而 Mongo 以文档(树)的形式理解。 换句话说 “ MongoDB 是文档型数据库(Document)， 而 MySQL 是表格型数据库(Tabular)”。

SQL 世界对 JSON 的支持普遍来讲都是隔靴搔痒，很多都是直接把 JSON 数据简单存起来，等用到的时候再现场 parse，根本鸡肋，更不用说还要把对 JSON 这种层次树状数据的精细操作按一种蹩脚的方言写成一种扁平的 SQL 形式，简直就是吃屎。就像让你写篇文章，只能用 Excel 表，或者用文字语言描述一个大型表格一样。

MongoDB 在底层数据是一种叫 BSON 的东西，和字面意思差不多，是 JSON 数据的二进制化，让这种树状数据能够更好地被底层处理，提升效率。在查询语言的角度，也对精细操作 JSON 数据下了很多功夫，这一点其实才是 SQL 数据库难以匹敌和超越的。

对于 JSON 的支持，有一个试金石，看对 JSON 数据的支持是不是走心了，就是看对于 JSON 内部的字段，能不能建索引。

一点理解，希望有用。

[troywinter]

#47 是正解，很多人喷 MongoDB 的联表查询，对不起，喷到这个点说明你在用关系型的方式用 MongoDB，那你可以随意喷。文档型的 Data Modeling 和关系型的 Data Modeling 当然是完全不同的，甚至可以说是两种完全不同的范式，用 MongoDB 处理关系型的 Model 当然效率好不到哪去。

[EKkoGG]

@avastms
想必我就是层主说的鹦鹉学舌的一派了，但我的初衷只是提供一个引子，如果楼主能在搜索引擎查询下关系型与非关系型数据库的区别，应该是能得到与你回复一样的答案的。所以没必要偷偷 DISS 别人，大家都是想给点帮助楼主而已。

[troywinter]

很多人说 PG 和 MySQL 也可以存 json，又要说一声对不起了，这玩意就像 MongoDB 也可以做关系型的 Modeling 和联表查询以及最近加入的事务，有这个东西不是说我有你就应该这么用，有和做的有多好是完全不一样的，MongoDB 的计算引擎在处理 json 方面确实是我见过最完善的，很多人喷都喷不到点子上。

另外，回答下楼主的问题，MySQL 适合结构化数据，MongoDB 适合非结构化数据，就是这么简单，关系型数据库是万能的，非常的灵活，但性能？？？ 对不起，往左 NewSQL，往右各类 NoSQL。

[liprais]

@troywinter 用过 pg 么...........
"GIN indexes can be used to efficiently search for keys or key/value pairs occurring within a large number of jsonb documents (datums). Two GIN "operator classes" are provided, offering different performance and flexibility trade-offs."

https://www.postgresql.org/docs/9.4/datatype-json.html

[karllynn]

@troywinter 你用过 pg 么，就一顿瞎扯

mongo 自带了集群支持，4.0 以后也支持了多文档事务，可以用$lookup 来 join 查询；而关系型这边，pg 的 json 支持已经很成熟了，json 字段可以建立索引。NoSQL 和传统 DBMS 早就开始融合，你们还活在 5 年前么？？？ TIDB 的出现更是直接简化了这些乱七八糟的东西，未来应该选型一个分布式关系型数据库就能解决大部分瓶颈了，只是由于分布式固有的 CPA 问题，仍然不会有银弹。

[troywinter]

@liprais #51 用过，我大学的导师也是当年在贝尔实验室搞数据库的，大学也接触过不少数据库相关的知识，记得没错的话 pg 在 9.2 版本中加入的 json，9.4 加入的 jsonb，有相对完善的 json operator，但我的建议是如果你没有深入的数据库调优经验和文件系统调优经验，pg has poor performance out of box，这种情况下还是 MongoDB 和 MySQL 结合比较适合。

[cs8814336]

@avastms 感谢回答.这是对我很有用的回答,接下来我可能需要看下 bson 是否就是那个关键原因了

[abcbuzhiming]

@cs8814336 别吹 Mongdb 的事务。那和 ACID 这个级别差的远了

[mysunshinedreams]

MongoDB 太吃内存了，优点就是可用性好，适合文档之间不用联合查询，不需要事务的。
如果需要联合查询，那酸爽。。。

[liprais]

@troywinter 功能跟性能是两个不同的概念

[reus]

@avastms PostgreSQL 有个 jsonb，就是和 bson 一样的二进制 json 类型，而且支持建立索引，例如对某个 jsonb 字段 foo，可以建立 foo #> '{key1, key2, key3}' 这样的索引。至少对 json 这种结构的数据的读写、索引都毫无问题，可以完美替代 mongodb。amazon 不提供 mongodb 之后，提供的文档数据库就是用 PostgreSQL 做后端。

[mysunshinedreams]

而且 MongoDB 地理索引做的比较好，文字索引跟 ES 差的很远，分片现在貌似还是不能回滚，不过就是方便，不论是主从还是分片，都是现成的，单表性能也还行。