【MySQL】行级锁的验证(第一篇)（正常的并发读写）
知识储备那么久，该来点有深度的【原创】了！
深思了一会发现MySQL的行级锁一两篇竟然本渣竟然讲不明白个所以然
所以分多篇讲述：本篇主要说明
正常简单系统并发预估是1K上下的QPS。普通的4C8G独立MySQL数据库，经测试可能承受2K-3K的并发读写，测试中也有很多因素影响，
服务器硬盘是机械或者SSD，linux系统的IO调度算法，最大文件句柄数，Buffer Pool调优，数据库中的表，行溢出......各种因素
最终假设为2K并发上下的样子。
好像.......和行级锁没啥关系？其实是说的是MySQL会出现并发情况，而上面是影响MySQL的并发情况。
而研发一个涉及到MySQL的系统，主要瓶颈都会在数据库上，如果所有操作都是串行那系统根本算得上是无法使用的。
并发情况下：MySQL对同一行操作(都把他们延时了)：结果
用时间线：
直接得出结论：
MySQL的更新、插入、删除操作，都会对操作的那一行数据加行级锁(独占锁或叫排他锁)！
而查询，并不会加锁，他是（基于undo log多版本链条+ReadView机制来实现的）
所以他们的在更新期间就算加锁了，对查询语句是毫无影响，查询语句查的是（"快照"数据）。
代码证明：
上面是核心代码。其他流程代码、单元测试和数据库都在上面的项目中。
所以本篇主要是说：
并发数据库中，正常的更新语句和查询语句完全不会冲突，MySQL的设计大大增加他的查询并发能力！
题外：上面提到的：undo log多版本链，ReadView机制一时半会说不清，后续会逐步解释透彻
