锁的分类
按照锁的类型来分:
- 读锁(共享锁):针对同一份数据,多个读的操作可以同时进行而不会产生其他的影响
- 写锁(排他锁):当前的写操作没有完成之前,会阻断其他写锁和读锁
按照锁的粒度来分:
- 表锁--MyISAM使用,开销小,加锁快,无死锁,锁的粒度大,发生锁冲突概率最高,并发度最低
- 行锁--InnoDB使用,开销大,加锁慢,会出现死锁,锁粒度小,发生锁冲突的概率最低,并发度也最高
- 页锁
操作锁的语句
查看是否有锁
show open tables加锁语句,book表上一个写锁,mylock表上读锁
lock table mylock read,book write解锁(全部解锁)
unlock tables表锁场景
现在有两张表mylock和book,两个会话1和2,会话1在mylock上加了一把读锁会导致的事:
- 会话1可以读mylock,但是不可以写mylock,也不能读写book
- 会话2可以读mylock和book,但是不可以写mylock(状态表现为阻塞),在会话1解锁之后,马上就能写了
另起一个场景,会话1现在在mylock表上加的是写锁:
- 会话1可以去写或者读mylock,不可以去读写book
- 会话2可以去读或者写book,但是不能读或者写mylock(状态表现为阻塞),会话1解锁之后,马上就能读或者写
总结起来就是读锁不会阻塞其他进程对同一表的读请求,但是会阻塞写请求,写锁会阻塞其他进程的读和写请求,并且在一个锁没有解开之前,该进程不允许操作其他的表
分析表锁状态
通过两个变量table_locks_waited和table_locks_immediate,通过命令show status like 'table%'就可以查看
- table_locks_waited:产生表级锁定的次数,表示可以立即获取锁的查询次数,每次获取锁,值就+1
- table_locks_immediate:出现表级锁定争用而发生的等待的次数(不能立即获取锁的次数,每等待一次,数值就+1),如果此值比较高说明存在比较严重的表级锁争用情况
MyISAM的读写锁调度是写优先,这也是MyISAM不适合做写为主表的引擎,因为写锁后,其他线程不能做任何操作,大量的更新会导致很难拿到锁,造成长久阻塞.InnoDB和MyISAM最大的不同有两点:一是InnoDB支持事务,二是它采用了行级锁
行锁场景
行锁需要回顾的问题:acid?事务的隔离级别?脏读?不可重复读?幻读?
会话1设置自动提交为false:set autocommit=0,会话1操作表更改了一行数据:
- 会话1查询该行发现已经更改,但是会话2查询该行发现并未更改,在会话1手动commit后,会话2再去查询才会发现更改的字段
- 会话1还没有提交数据的时候,如果会话2去更改该行的数据(更改其他行不会阻塞)会导致会话2阻塞,直到会话1手动commit,会话2才会更改成功
索引失效:索引失效以后,会导致行锁转换为表锁,比如建立了索引的列a,本来是varchar,但是在查询的时候没有加''导致自动类型转换,索引失效,这时行锁就会自动转换成表锁
间隙锁的危害:当我们使用范围条件而不是相当条件检索数据,并且请求共享或者排他锁的时候,InnoDB会给复合条件的已有数据记录的索引项加锁,对于键值在条件范围内但是不存在的记录,我们称之为间隙,InnoDB也会对这个间隙加锁,这就是间隙锁(表的情况为1-9但是没有2,会话1操作大于等于1小于等于9的值,会话2新插入2会导致会话2进入阻塞)
读的时候如何锁定一行: select * from table where a=1 for update,通过for update这个语句就在读的时候也加上了锁
分析行锁状态
?通过检查InnoDB_row_lock状态变量来不分析系统上行锁的争夺情况.查询语句:show status like 'InnoDB_row_lock'
InnoDB_row_lock_current_waits:当前正在等待锁定的数量
InnoDB_row_lock_waits:系统启动后到现在总共等待的次数
InnoDB_row_lock_time_avg:等待的平均时长
InnoDB_row_lock_time:等待的总时长
优化建议
- 尽可能让所有数据检索都通过索引来完成,避免吴索引行锁升级为表锁,避免间隙锁
- 合理设计索引,尽量缩小锁的范围
- 尽量控制事务的大小,减少锁定资源量和时间长度,尽可能使用低的事务隔离级别
主从复制
?步骤分为三步:
- master将改变记录到二进制日志(binary-log),这些记录过程叫做二进制日志事件binary log events
- slave将master的binary log events拷贝到他的中继日志(relay log)
- slave重做中继日志中的事件,将改变应用到自己的数据库中,mysql复制是异步并且串行化的
基本的原则:
每个slave只有一个master,每个slave只能有一个唯一的服务器ID,每个master可以有多个slave
一主一从常见配置: