innodb 引擎 行锁与表锁
行锁与表锁是基于索引来说的（且索引要生效）
不带索引 （表锁）要全表扫描
1. 执行select @@autocommit; 查看结果 0是不自动提交事务，1是自动提交事务， mysql默认是自动提交
2. set autocommit = 0;设置为不开启自动提交
3. 通过开多个tab窗口模拟不通的session 执行数据库
新建一张person表
窗口1 模拟第一个session
在此窗口先执行设置0，在单独执行update语句
窗口2 模拟第二个session
执行该条语句可以看到 sql一直执行 卡住了，因为它是在等待上一个事务执行完释放表锁
经过一段时间后看到如下结果
这个错跟我们生产上报的错一样，用pinpoint监控的
——————————————————
执行update 和insert 都是一样的结果 在等待表锁，虽然我操作的不是同一行数据。
如果我把窗口1的事务提交则窗口2会从卡的状态成功执行结束
窗口1的commit;
窗口2的session的则立马执行完毕，
这个场景模拟的是表锁，当session1 拿到表锁后，别的事务的session执行（insert，update，delete） 是拿不到锁的会进行锁等待。
通过命令 看到了当前处于等待的语句
把name字段添加索引（行锁）不用全表扫描直接定位到行 ，使用主键也是用的行锁
添加索引，然后通过执行计划查看索引是生效的
在回到之前的问题，窗口1 再次执行相同的sql 不提交事务，此时执行窗口2
窗口2 直接执行完毕，此时行锁生效，我操作的不是同一行，结果生效了
以上是innodb引擎的表锁 和行锁 ，顺便验证一下默认的事务隔离级别（读已提交的）
开一个窗口3 代表session3
事务执行前
删掉刚才的索引 drop index namex_name on person;
窗口1 执行，当前事务下的结果改变了
窗口3验证 窗口1的事务没提交前 别的事务是读不到这个事务的，如果把窗口1的事务提交 怎窗口3能顺利读取， 这同时说明了2个隔离级别 ———–读已提交的 和不可重读
事务的可串行化可参考：https://blog.csdn.net/nangeali/article/details/75578787 事务内的查询都是带锁的（表锁）
表锁与行锁 以上自己通过数据库执行 直观的验证了一遍，可以看如下这边文章的文字描述来抽象这个验证
参考：https://blog.csdn.net/lz710117239/article/details/71762617
https://blog.csdn.net/u014635472/article/details/79712931 或者 https://www.cnblogs.com/wodebudong/articles/7976474.html
总结： 普通的 曾删改 是表锁，加入索引的曾删改 是行锁，执行 查询是不加任何锁的， 不是有些博客所说的 表锁升级为行锁 。
