@Wisho 恩，所以到现在我的问题还是没解决.看来源码...

@janxin 什么场景 mongdb 会比 mysql 快

@baojiweicn2 两个数据库都是有索引的

@hilbertz 你的回答让我认为 mysql 是完美取代 mongdb 的

@ke1e 这个 innodb 也会有 innodb pool buffer

@514146235 其实我也是看到新版的发展，才越来越发现我对这 2 个数据库应用的地点越来越模糊，所以特来此请教一下

@514146235 任何事情都有优缺点的，你在说不能类比的时候，暗中其实也说了，mongdb 是用在不支持事务的场景的，而 mysql 可以用在. 目的在于讨论是不是某一方可以完全替代另外一方，假如不是说下底层技术理由．

@Wisho 我跟你的想法应该是类似的，但是同样对这个有点疑惑

@Wisho
@lxy42

innodb 的行锁都是在 index record 操作的，这个 index record 我可以理解为 b+树的非叶子节点吗？　假如是的话，gap=3 for update 理论上锁定的是整个 gap=3 的 index,　这样的话 gap=3 的新记录应该也是属于在 gap=3 的 index 下面的，假如只有 record lock 应该还是会锁住 gap=3 的

Record Locks

A record lock is a lock on an index record. For example, SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; prevents any other transaction from inserting, updating, or deleting rows where the value of t.c1 is 10.

Record locks always lock index records, even if a table is defined with no indexes. For such cases, InnoDB creates a hidden clustered index and uses this index for record locking. See Section 15.6.2.1, “ Clustered and Secondary Indexes ”.

Transaction data for a record lock appears similar to the following in SHOW ENGINE INNODB STATUS and InnoDB monitor output:

@kaid97 的确从这个方向想是有一点道理. 那其实指的是锁住索引节点之间的空隙. 并不能单纯地想着锁住某个值. 但是假如这样想的话为什么会有 record lock 呢，既然有 record lock 的话他的确是能做到精确锁住某个值的，就是锁住了 b+树的非叶子节点的某个部分.(但是介绍说又说好像只能锁住 index record,除非 b+树的非叶子节点只有一种 value 的记录？)

官网文档有说 next-key-locks 是 record+gap: 的确是的. 但是官网也是说 next-key-locks 和 gap lock 是并列的

For locking reads (SELECT with FOR UPDATE or FOR SHARE), UPDATE, and DELETE statements, the locks that are taken depend on whether the statement uses a unique index with a unique search condition, or a range-type search condition.

For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it.

For other search conditions, and for non-unique indexes, InnoDB locks the index range scanned, using gap locks or next-key locks to block insertions by other sessions into the gaps covered by the range. For information about gap locks and next-key locks, see Section 15.7.1, “ InnoDB Locking ”.[原文]( https://dev.mysql.com/doc/refman/8.0/en/innodb-locks-set.html)

为什么这种 next-key locking 能解决幻读问题: 就是说　 select * from `ttt` where `gap`=3 for update; 锁定了[1,5] 范围，假如他降级为行锁（就是辅助索引只锁 3，聚集索引还是会锁 11113 ）会出现什么幻读问题？

mysql 技术内幕 innodb 存储引擎是在微信读书看的

@feihuxiongdi 什么意思.你那个是 json 结构吗 _"_123_"_ ?