所谓小表驱动大表 类似于下,优先选择第一种
order by 总结
满足最佳左前缀原则
group by
基本和order by 一致
慢日志(了解)
showprofile
Mysql锁机制
表锁
演示表锁
1.加读锁
读锁结论: 当前表加上读锁后,就只能对自己读,不能对自己写,也不能对其他表读写其他表能对此加读锁表进行读,但执行写操作时会被阻塞.
2.加写锁
写锁结论: 写锁更加"自私",只允许自己对加写锁的表做任何操作,但与自己加读锁一样,也他不允许对其他表做任何操作(因为自己欠的帐还没还清,它的记录存放在栈里),而其他的session对已加写锁的表做不了任何操作!
简而言之,就是读锁会阻塞写,但不会阻塞读,而写锁则会把读和写都阻塞
MyISAM总结口诀:
读锁共享(读)要清账,不可读他写自己(不能写自己),并发可读写阻塞
写锁独占要清账,自己随随便便玩,并发全部都阻塞
此外,Myisam的读写锁调度是写优先,这也是Myisam不适合做写为主表的引擎.因为写锁后,其他线程不能做任何操作,大量的更新会使查询很难得到锁,从而造成永久阻塞;
---->表锁偏读,行锁偏写
(助记:表的数据量级别大于行的数据量级别,默认为写的细粒度更小于读,所以,写适合范围更小的行)
行锁
一句话:事物B读到了事物A 已修改但尚未提交的数据 ,还在这个数据基础上做了操作,此时,如果事物A回滚,.那么B读到的数据无效,不符合一致性要求.
项目*最隐蔽的错误细节:索引失效会导致行锁变成表锁---->表中的b字段是varchar类型的,并且a,b列都加了索引,所以在查找的时候用单引号包裹b列的字段会用到索引,而在实际操作中没有用到单引号,直接搜编号4000,导致索引失效,因此,另一个session在操作同表的不同行时会被阻塞(由于行锁升级成表锁的缘故)
曾经在项目中遇到过次问题,不难,但是隐藏的特别深----商品表中goods_id用的varchar类型,而在写update SQL的时候没将goods_id这个字段用${}括起来,(后面该用#{}),导致索引失效,从而在并发测试抢购商品的时候会出现(需要实操)问题
间隙锁
加锁一行
行锁总结
Mysql主从复制
