neverend的日志

不记录,终将被遗忘。 一万年太久,只争朝夕。 他们用数字构建了整个世界。

  BlogJava :: 首页 :: 联系 :: 聚合  :: 管理
  62 Posts :: 1 Stories :: 17 Comments :: 0 Trackbacks

2012年3月13日 #

在事务隔离级别设定为repeatable read的情况下,一般的select语句采取的是一致性非阻塞读的方式。
一致性是指在事务的范围内读取的数据是可重现的,不会出现不可重复读的情况。非阻塞是指这种读取数据的模式不会对数据上任何一种锁,其它操作全都不会被阻塞。
在这种模式下,事务执行读取语句后,相关的数据会有一套副本出现,并会为这个数据副本附加一个时间戳,其它事务在这个时间戳之后执行的写操作都不会反映到这个副本中,这种机制被称之为多版本并发控制。
如果用select …… lock in share mode,则不是一致性非阻塞读,该语句会等待其它事务的写语句提交或回滚之后再读取数据;如果事务隔离级别设置为read committed,也不是一致性非阻塞读,该语句会读取其它事务提交的数据。
posted @ 2012-04-05 11:25 neverend 阅读(1856) | 评论 (0)编辑 收藏

介绍下对于Mysql锁机制的理解
从基本概念开始:
共享锁
共享锁的代号是S,是Share的缩写,共享锁的锁粒度是行或者元组(多个行)。一个事务获取了共享锁之后,可以对锁定范围内的数据执行读操作。

排它锁
排它锁的代号是X,是eXclusive的缩写,排它锁的粒度与共享锁相同,也是行或者元组。一个事务获取了排它锁之后,可以对锁定范围内的数据执行写操作。

假设有两个事务t1和t2
如果事务t1获取了一个元组的共享锁,事务t2还可以立即获取这个元组的共享锁,但不能立即获取这个元组的排它锁(必须等到t1释放共享锁之后)。
如果事务t1获取了一个元组的排它锁,事务t2不能立即获取这个元组的排共享锁,也不能立即获取这个元组的排它锁(必须等到t1释放排它锁之后)。
 
意向锁
意向锁是一种表锁,锁定的粒度是整张表,分为意向共享锁(IS)和意向排它锁(IX)两类。意向共享锁表示一个事务有意对数据上共享锁或者排它锁。“有意”这两个字表达的意思比较微妙,说的明白点就是指事务想干这个事但还没真去干。举例说明下意向共享锁,比如一个事务t执行了这样一个语句:select * from table lock in share model ,如果这个语句执行成功,就对表table上了一个意向共享锁。lock in share model就是说事务t1在接下来要执行的语句中要获取S锁。如果t1的select * from table lock in share model执行成功,那么接下来t1应该可以畅通无阻的去执行只需要共享锁的语句了。意向排它锁的含义同理可知,上例中要获取意向排它锁,可以使用select * from table for update

lock in share model 和 for update这两个东西在数据率理论中还有个学名叫悲观锁,与悲观锁相对的当然还有乐观锁。大家可以看到各种锁都是成双成对出现的。关于悲观锁和乐观锁的问题暂且不表,下文再来详述。

锁的互斥与兼容关系
锁和锁之间的关系,要么是相容的,要么是互斥的。
锁a和锁b相容是指:操作同样一组数据时,如果事务t1获取了锁a,另一个事务t2还可以获取锁b;
锁a和锁b互斥是指:操作同样一组数据时,如果事务t1获取了锁a,另一个事务t2在t1释放锁a之前无法获取锁b。

上面提到的共享锁、排它锁、意向共享锁、意向排它锁相互之前都是有兼容/互斥关系的,可以用一个兼容性矩阵表示(y表示兼容,n表示不兼容):
    X    S    IX    IS
X  n     n    n     n
S  n     y    n     y
IX n     n    y     y
IS n     y    y     y 

兼容性矩阵为什么是这个样子的?
X和S的相互关系在上文中解释过了,IX和IS的相互关系全部是兼容,这也很好理解,因为它们都只是“有意”,还处于YY阶段,没有真干,所以是可以兼容的;
剩下的就是X和IX,X和IS, S和IX, S和IS的关系了,我们可以由X和S的关系推导出这四组关系。
简单的说:X和IX的=X和X的关系。为什么呢?因为事务在获取IX锁后,接下来就有权利获取X锁。如果X和IX兼容的话,就会出现两个事务都获取了X锁的情况,这与我们已知的X与X互斥是矛盾的,所以X与IX只能是互斥关系。其余的三组关系同理,可用同样的方式推导出来。

一致性非阻塞读

select... lock in share mode和select ... for update的区别

索引记录锁
间隙锁
后码锁

各种语句对应的锁类型
在有索引的情况下是以后码锁为基础的行级锁,在固定索引键查找的情况下是索引记录锁,在没有可用索引的情况下上升到表锁
有索引的情况:
select ... from 一致性非阻塞读,不上锁。在serializable隔离级别下例外,在这个隔离级别下上共享后码锁
select ... from ... lock in share mode  共享后码锁
select ... from ... for update 排它后码锁
update .... where  排它后码锁
delete from .... where 排它后码锁
insert ... 排它索引记录锁,如果发生键值唯一性冲突则转成共享锁
insert ... on duplicate key update ,一直都是排它锁
replace ... 一直都是排它锁


死锁情境分析

MVCC的理论与实现
posted @ 2012-03-31 14:53 neverend| 编辑 收藏

1. 优化更需要优化的SQL
高并发低消耗 > 低并发高消耗

2. 定位性能瓶颈
profiling

3. 明确的优化目标

4. 从explain入手
y
5. 小结果集驱动大结果集??
Join操作

6. 在索引中完成排序

7. 只取出自己需要的columns
MySQL有两种排序算法,尽可能使用只访问一次数据的算法。

8. 仅仅使用最有效的过滤条件
索引键长度?

9. 避免复杂的join和子查询

充分利用EXPLAIN和profiling
profiling的使用:
1.set profiling = 1;
2.执行SQL;
3.show profile;
4.show profile [cpu, block io] for query [id];

mysqlslap 测试sql性能
mysqlslap --concurrency=5 --iterations=500 --query="selec
t * from hbe_hotel" --create-schema=phoenix -uroot -p

合理设计并使用索引
Mysql支持的索引类型:
1. B-tree索引 除了Archive的存储引擎都支持
2. Hash索引  memory和NDB支持
3. Full-text索引 MyISAM,分词后建立B-tree索引
4. R-tree索引 MyISAM ,GIS系统使用

索引的利弊
利:提高数据检索效率和排序、分组效率
弊:加大更新操作的资源消耗,增加存储空间的消耗

如何判断是否需要使用索引
1. 使用较频繁的字段应该创建索引
2. 唯一性太差的字段不建索引 经验值:15%
3. 更新非常频繁的字段不建索引
4. where子句中不出现的字段不建索引

单键索引还是组合索引?
多方考虑,平衡优劣

技术人员如何证明一个需求是否合理?
1. 每次PD提出新需求的时候,要求给出该项目预期收益的量化指标。
2. 在项目进行中,详细记录所有资源投入,包括人力、硬件等。
3. 项目上线后收集数据统计实际收益值。
4. 相关部门尽可能设计出项目投入/产出比率的计算规则,将投入/产出比公布给参与项目的所有人员。
5. 比较实际的投入/产出比与预期值,以判定项目做的是否值得。

posted @ 2012-03-13 07:48 neverend 阅读(345) | 评论 (0)编辑 收藏