最近五哥和同事争辩起来，MySQL插入是并发还是串行，我记得明明是串行插入，同事非要和我杠，说MySQL可以并发插入。
我要亲自试验一下，打他的脸！
MySQL实验版本8.0
定义表结构首先定义用户信息表usrInfo，其中id为自增，nam具有唯一索引。
验证流程
默认情况下，在命令行中MySQL会自动提交，每个SQL执行会非常快，无法验证同时执行的两个事务之间是否存在阻塞情况，所以需要显示开启事务和提交事务。
验证首先，我们开启两个事务。在事务1中，首先插入一条记录，暂时不提交。然后，在事务2中开启一个新的事务，并插入一条自增记录。
如果MySQL的innodb插入是串行的，那么此时事务2的插入记录将会被阻塞。如果没有被阻塞，那就说明MySQL的innodb插入是并发执行的。
时间序号事务1事务21开启事务STARTTRANSACTION;2主键自增插入记录(ID=1)开启事务STARTTRANSACTION;4主键自增插入记录（ID=2）5提交事务Commit6查询当前用户列表，居然有ID=2的记录7提交事务Commit
实验验证事务2的执行记录
如上图所示，在事务1还未提交，事务2在事务1的间隙中插入一条记录，插入操作立即成功，并且事务2的自增主键ID为2。这说明在MySQL中，当一个事务正在插入记录时，并不会阻塞其他事务的插入。
在MySQL中，多个事务之间的插入操作是并发进行的，而不是串行进行的。
我感觉自己的脸热热的，小丑竟是我自己，赶紧给同事认了错……
我的认知一直是错误的。
但是在底层存储层面，MySQL会对数据页加锁。如果两条记录在同一个数据页，实际写入是串行的，但是事务层面是并发的。
想象一下，库存扣减和新增库存流水在同一个事务中，如果新增库存流水是串行的，那将极大的降低库存事务的并发度啊。
本以为验证结束，打卡下班，结果发现MySQL插入似乎存在幻读问题！
从下图中可以观察到，事务1在插入时似乎确实出现了幻读问题！
事务1的执行记录显示，事务1先于事务2开启，但是事务1期间可以查询到事务2提交的记录。这说明有幻读问题！
为什么出现幻读？所谓幻读，是指在一个事务读取记录时，另一个事务在此时插入或删除了一条记录，导致第一个事务再次读取时发现记录的数量发生了变化。
要想理解出现幻读的原因，需要先了解MySQL是如何解决幻读问题的。
为了解决幻读问题，MySQL采用了间隙锁和多版本并发控制（MVCC）的方法。间隙锁会锁定一段记录的范围，其他事务无法对这些记录进行更新或删除操作。这样，当当前事务再次进行查询时，就不会出现记录数量的新增或减少的情况了。
MySQL插入时加了什么锁？MySQL插入时存在幻读问题，说明MySQL并没有加间隙锁，主要考虑也是为了提高插入时并发度，如果添加间隙锁，势必导致插入并发度降低！MySQL在插入之前会申请插入意向锁，而记录本身不冲突（无唯一键冲突）插入意向锁就不会冲突。
MySQL文档中记录了插入意向锁
插入意向锁（insrtintntionlock）是一种由插入操作在插入行之前设置的锁定类型。这种锁定方式表示插入的意图，使得在相同索引间隙上进行插入的多个事务在插入位置不冲突的情况下不需要互相等待。假设索引记录中存在值为4和7的记录。分别尝试插入值为5和6的两个不同事务，在获得插入行的排他锁之前，它们会先使用插入意向锁锁定位于4和7之间的间隙，并且由于插入行不冲突，它们不会互相阻塞。
插入场景MVCC不生效？除更新场景外，查询场景也有幻读的困恼。如果第一次查询时只有条记录，再次查询则变为4条，实在过于奇幻。
如果给普通的查询语句添加间隙锁，势必极大的降低MySQL的并发度，如果不能使用间隙锁，还有哪些办法解决幻读呢？
MySQL通过引入MVCC解决查询场景的幻读问题。MVCC是多版本并发控制（MultivrsionConcurrncyControl）的缩写，在MVCC中，每个事务可以看到数据库的一个稳定的快照，而不会被其他并发事务的修改所干扰。当一个事务修改数据库时，它会创建一个新的数据版本，而不是直接在原始数据上进行修改。而其他事务仍然可以读取原始数据的旧版本或者已经提交的新版本，这样就避免了读取到未提交的数据或者被其他事务的写操作所阻塞。
MVCC的实现通常涉及对每个数据行或数据块分配一个唯一的标识符，称为"事务ID"。每个事务也有自己的唯一ID。当一个事务读取数据时，系统会检查该数据的事务ID与事务的ID是否兼容，以确定是否允许读取。如果事务的ID大于数据的事务ID，那么说明数据是过期的，事务将无法读取。这种机制保证了事务在读取数据时的隔离性和一致性。
转机出现了当我在苦苦思考，为什么MVCC没有生效时，我随手重新测试发现，如果在insrt语句之前，使用slct查询一下，就不会出现幻读问题。
操作顺序如下
时间序号事务1事务21开启事务STARTTRANSACTION;新增的操作slct*fromusrInfo2主键自增插入记录(ID=1)开启事务STARTTRANSACTION;4主键自增插入记录（ID=2）5提交事务Commit6查询当前用户列表，无ID=2的记录7提交事务Commit
我在事务1，开启事务以后，新增了slct语句查询，而后第六步，就不会再有幻读问题……
这真的实在太奇幻了。一波三折……
由此可见MySQL插入并没有幻读问题，只是我的打开方式不对。我应该先slct一下……，终究还是我错了，但是我想问为什么？我为什么错了？
RadViw是关键！除MVCC外，MySQLInnoDB引擎设计了RadViw（可读视图）的概念。
RadViw判断记录的可见性，RadViw实际上是当前系统中所有活跃事务的列表，主要包含以下组成部分：
m_ids：在生成RadViw时当前系统中活跃的事务ID列表；
min_trx_id：在生成RadViw时当前系统中活跃的事务中最小的事务ID，也就是m_ids中的最小值；
max_trx_id：在生成RadViw时系统中应该分配给下一个事务的ID值；
crator_trx_id：生成RadViw的事务对应的事务ID，也就是当前事务ID。有了这个RadViw之后，在访问某条记录时，只需要按照下边的步骤判断该记录的某个版本是否可见：
如果被访问版本的trx_id属性值与RadViw中的crator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本记录可以被当前事务访问。如果被访问版本的trx_id属性值小于RadViw中的min_trx_id值，表明生成该版本的事务在当前事务生成RadViw前已经提交，所以该版本记录可以被当前事务访问。如果被访问版本的trx_id属性值大于或等于RadViw中的max_trx_id值，表明生成该版本的事务在当前事务生成RadViw后才开启，所以该版本记录不可以被当前事务访问。如果被访问版本的trx_id属性值在RadViw的min_trx_id和max_trx_id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建RadViw时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建RadViw时生成该版本的事务已经被提交，该版本记录可以被访问。如果某个版本的记录对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。总结一下就是：如果当前事务id的生成时间发生在记录的更新之后，那么当前事务就可以看见这个记录，否则看不见！避免幻读问题
那RadViw又是何时生成的呢？在REPEATABLEREAD隔离级别下，每个事务执行第一个SELECT语句时，会将当前系统中的所有的活跃事务拷贝到一个列表生成RadViw，后续所有的SELECT都是复用这个RadViw。
REPEATABLEREAD隔离级别下，只有第一次SELECT才会生成RadViw，后续SELECT都会复用这个RadViw，也就不存在新提交事务对这个RadViw的影响了。
所以当我在事务1新增slct语句，会生成一个RadViw，这个RadViw生成时间要早于事务2的时间，所以事务1的后续所有查询都不会看到事务2的记录，从而避免幻读问题发生。
总结MySQLinnodb插入记录是并发的。MySQLinnodb插入记录不存在幻读问题，MySQL通过mvcc+RadViw解决幻读问题。