(0)





不为什么,数据库的事务机制就是这样,insert时全表锁,因为要生成主键字段、索引等等,update是行级锁。同时对一张表进行读写操作,会产生‘脏’数据,导致读、写两端的数据不一致。当然了,这是要在绝对意义上的‘同时’情况下才会发生。我建议你读数据用视图吧。


http://www.iteye.com/problems/119113







(一)https://segmentfault.com/q/1010000010389243


  • myisam,锁表

  • innodb, 成功使用索引时锁行,否则锁表



表级锁 开销小,吞吐量会减小 
行级锁 消耗大,吞吐量也大
MyISAM只支持表级锁;InnoDB支持行级锁(分为共享锁与排它锁),可以使用表锁;
当前读(除显式in share外,包括update都是拍他锁)


加锁和并发没什么关系,innodb一般情况下走索引或者主键更新都是锁行,其余都是锁表,在并发的时候可以加select for update手工锁




(二)http://www.cnblogs.com/chenqionghe/p/4845693.html

对于 InnoDB表,主要有以下几点
    (1)InnoDB的行销是 基于索引 实现的,如果不通过索引访问数据,InnoDB会使用表锁。
    (2)InnoDB 间隙锁机制 ,以及InnoDB使用间隙锁的原因。
     (3) 在不同的隔离级别下, InnoDB的锁机制和 一致性 读策略不同。
    (4) MySQL的恢复和复制对InnoDB锁机制和一致性读策略也有较大影响。
    (5)锁冲突甚至死锁很难完全避免。
    在了解InnoDB的锁特性后,用户可以通过设计和SQL调整等措施减少锁冲突和死锁,包括:
  • 尽量使用较低的隔离级别
  • 精心设计索引,并尽量使用索引访问数据,使加锁更精确,从而减少锁冲突的机会细粒度
  • 选择合理的事务大小,小事务发生锁冲突的几率也更小。
  • 给记录集显示加锁时,最好一次性请求足够级别的锁。比如要修改数据的话,最好直接申请排他锁,而不是先申请共享锁,修改时再请求排他锁,这样容易产生死锁。
  • 不同的程序访问一组表时,应尽量约定以相同的顺序访问各表,对一个表而言,尽可能以固定的顺序存取表中的行。这样可以大减少死锁的机会。
  • 尽量用相等条件访问数据,这样可以避免间隙锁对并发插入的影响。
  • 不要申请超过实际需要的锁级别;除非必须,查询时不要显示加锁。
  • 对于一些特定的事务,可以使用表锁来提高处理速度或减少死锁的可能。

(三)https://bbs.csdn.net/topics/392028926

要修改数据,首先要找到数据,而如果没有索引,就会直接锁住表的数据,就会锁住其他的会话。

所以,如果你看innodb的最佳实践里,一定会要你创建主键索引,如果你没有主键,可以用一个代理键,也就是自增列实现。

(四)http://blog.sina.com.cn/s/blog_79c0eb870102wmyn.html

InnoDB行锁是通过给索引上的索引项加锁来实现的


Logo

更多推荐