管理器:
接受请求
创建线程(线程是否回收?放到线程池重用)
认证用户
建立安全连接(是否使用加密传输,默认明文传输)
缓存
是否应该缓存(数据的有效性)
权限(哪些可以查看这些缓存)
缓存带来的性能影响
…
并发控制 (例如同时访问一个文件或数据)
MVCC:多版本并发控制
基本原理:
在事务中保存数据的快照,这意味着在一个事物里能够看到数据一致的视图,而不用担心这个事务运行多长时间,同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。
MVCC的基本特征:
每行数据都存在一个版本,每次数据更新时都更新该版本
修改时Copy出当前版本随意修改,个事务之间无干扰
保存时比较版本号,如果成功(commit),则覆盖原记录;失败则放弃copy(rollback)
读锁:共享锁
写锁:独占锁
LOCK TABLES tb_name {READ|WRITE}
UNLOCK TABLES
锁粒度: 从大到小,MySQL服务器仅支持表级锁,行锁需要由存储引擎完成
表锁
页锁
行锁
例如:
1 | mysql>LOCK TABLES xueyuan READ; |
RDBMS: 要支持事务,必须满足ACID;
原子性(Autmic):事务在执行性,要做到“要么不做,要么全做!”,就是说不允许事务部分执行。即使因为故障而使事务不能完成,在rollback时也要消除对数据库的影响!
一致性(Consistency):事务的操作应该使数据库从一个一致状态转变到另一个一致的状态!就拿网上购物来说吧,你只有即让商品出库,又让商品进入顾客的购物篮才能构成事务!
隔离性(Isolation):如果多个事务并发执行,应像各个事务独立执行一样!
持久性(Durability):一个成功执行得事务对数据库的作用是持久的,即使数据库因故障出错,也应该能够恢复!
而关系型数据库要根据事务日志来保证ACID。
事务日志:
重做日志
redo log : 就算崩溃,也可根据日志无限的进行重做;
撤销日志
undo log:把原来的状态记录下来,以后可进行撤销到原来的状态;
所有的事务操作,都会先写入到事务日志中(内存),然后再写入到数据文件(硬盘)上;
几乎在所有事务引擎上的操作,都会执行两遍,日志中一次,数据文件中一次;
日志中的操作仅是操作过程,所以叫做redo。然后事务日志提交写入到数据文件中,所以在整个操作过程中,数据文件的操作慢于日志操作。
事务–>事务日志–>同步到硬盘上
但是,比如说:
一个事务有4个语句,并且已经提交到日志中,如果硬盘突然崩溃了,就会要根据日志重做这些语句;
如果在执行这些语句时,突然崩溃了,语句还没有完整写入到日志组中,这个事物就会撤销;
日志文件一般不需要太大,例如5M,当这个日志文件已经满的时候,就会提交到硬盘上,但是不应该只有一个日志文件,这个叫做日志组(轮流写入到硬盘)
当然日志的大小应该根据事物的大小进行定义;
事务日志不应该和数据文件存放到同一个物理设备上;
隔离性:
隔离级别 从小到大
READ-UNCOMMITTED 读未提交 读别人尚未提交的数据,这边一修改,就能看到
READ-COMMITTED 读提交 提交以后才能看到,读提交后的数据,但是会出现“幻读”;
REPEATABLE- READ 可重读(default) 无论提不提交,和我这次事务没有影响,但是仍会出现“幻读”;
SERIALIZABLE 可串行
隔离级别越高,并发能力越低。
应根据业务进行调整,有时会是飞跃性的;
SHOW GLOBAL VARIABLES LIKE ‘%iso%’ ; 可查看默认隔离级别;
服务器变量:
全局变量:
修改后不影响当前会话,只对新建的会话有效
会话变量:
仅对当前会话有效,立即生效
永久有效:
修改配置文件
1 |
|
MVCC的介绍:
http://www.cnblogs.com/wenfeng762/archive/2011/11/06/2238108.html
http://www.cnblogs.com/dongqingswt/p/3460440.html
事务日志:
http://www.cnblogs.com/wangkongming/p/3684950.html
隔离级别: 建议多读这个。。。
http://xm-king.iteye.com/blog/770721