而且，通过 [设置锁的颗粒度] 、 [读写锁] 等方式优化，也能解决悲观锁并发受限制的问题。
那为什么要用乐观锁呢？
比如，这篇博客中举的 [在线文档] 的例子，
https://xiaolincoding.com/os/4_process/pessim_and_optimi_lock.html#乐观锁与悲观锁
这里举一个场景例子：在线文档。
我们都知道在线文档可以同时多人编辑的，如果使用了悲观锁，那么只要有一个用户正在编辑文档，此时其他用户就无法打开相同的文档了，这用户体验当然不好了。
那实现多人同时编辑，实际上是用了乐观锁，它允许多个用户打开同一个文档进行编辑，编辑完提交之后才验证修改的内容是否有冲突。
[疑问]
像 MySQL 那样用行级别的锁（或者更小的粒度，一个单元格一把锁），不是和使用 [乐观锁] 的效果一样，都能支持 [多用户并发写入] 吗？
一个用户写入单元格，另一个用户不能读的问题，不是也可以通过 [读写锁] 的方式来解决吗？
那么为什么这个场景用乐观锁？
我能想到的解释只有：因为用颗粒度小的悲观锁，需要锁监视器监视大量的锁，导致使用悲观锁的成本太高？
还有其它的解释吗？
