mysql的innodb 引擎表锁与行锁

2024-08-30 19:31:21

　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

　　

总结：普通的曾删改是表锁，加入索引的曾删改是行锁，执行查询是不加任何锁的，不是有些博客所说的表锁升级为行锁。

最新文章

热门文章