image.png
image.png

所谓小表驱动大表 类似于下,优先选择第一种


image.png
image.png
image.png
image.png
image.png
image.png

order by 总结

image.png

满足最佳左前缀原则

group by

image.png

基本和order by 一致

慢日志(了解)

image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png

showprofile

image.png
image.png
image.png

Mysql锁机制

image.png
image.png
image.png

表锁

演示表锁
1.加读锁


image.png
image.png
image.png
image.png
image.png
image.png

读锁结论: 当前表加上读锁后,就只能对自己读,不能对自己写,也不能对其他表读写其他表能对此加读锁表进行读,但执行写操作时会被阻塞.

2.加写锁


image.png

写锁结论: 写锁更加"自私",只允许自己对加写锁的表做任何操作,但与自己加读锁一样,也他不允许对其他表做任何操作(因为自己欠的帐还没还清,它的记录存放在栈里),而其他的session对已加写锁的表做不了任何操作!

image.png

简而言之,就是读锁会阻塞写,但不会阻塞读,而写锁则会把读和写都阻塞

MyISAM总结口诀:
读锁共享(读)要清账,不可读他写自己(不能写自己),并发可读写阻塞
写锁独占要清账,自己随随便便玩,并发全部都阻塞

image.png

此外,Myisam的读写锁调度是写优先,这也是Myisam不适合做写为主表的引擎.因为写锁后,其他线程不能做任何操作,大量的更新会使查询很难得到锁,从而造成永久阻塞;
---->表锁偏读,行锁偏写
(助记:表的数据量级别大于行的数据量级别,默认为写的细粒度更小于读,所以,写适合范围更小的行)

行锁

image.png
image.png
image.png
image.png

一句话:事物B读到了事物A 已修改但尚未提交的数据 ,还在这个数据基础上做了操作,此时,如果事物A回滚,.那么B读到的数据无效,不符合一致性要求.

image.png
image.png
image.png
image.png
image.png

项目*最隐蔽的错误细节:索引失效会导致行锁变成表锁---->表中的b字段是varchar类型的,并且a,b列都加了索引,所以在查找的时候用单引号包裹b列的字段会用到索引,而在实际操作中没有用到单引号,直接搜编号4000,导致索引失效,因此,另一个session在操作同表的不同行时会被阻塞(由于行锁升级成表锁的缘故)

曾经在项目中遇到过次问题,不难,但是隐藏的特别深----商品表中goods_id用的varchar类型,而在写update SQL的时候没将goods_id这个字段用${}括起来,(后面该用#{}),导致索引失效,从而在并发测试抢购商品的时候会出现(需要实操)问题

引申出mybatis中$和#的区别

间隙锁


image.png
image.png

加锁一行


image.png

行锁总结


image.png
image.png
image.png
image.png

Mysql主从复制

image.png
image.png
image.png
收藏
评论加载中...