mysql什么时候锁表

(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.youkuaiyun.com/topics/392028926

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

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

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

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


<think>嗯,用户想了解MySQL的时机以及唯一约束对索引的影响。首先,我需要回忆一下MySQL机制。通常发生在数据修改时,比如INSERT、UPDATE、DELETE操作,这时候可能会加行或者,具体取决于存储引擎。InnoDB一般是行,但如果没有合适的索引,可能会升级为。另外,唯一约束和索引的关系,唯一约束会自动创建唯一索引,所以当插入或更新数据时,唯一索引会检查重复值,这时候可能会加,比如使用next-key来防止幻读。然后,用户提到的引用内容里有关于唯一索引失效的情况,比如设置unique_checks=0的时候,可能导致唯一约束被绕过,但重启后可能又生效。这可能涉及到唯一索引的检查机制,需要解释在插入数据时,唯一索引如何影响的申请,比如在检查唯一性时,是否需要加,以及加什么级别的。 还有用户之前的问题可能涉及主键和唯一索引的区别,引用3里提到主键冲突的例子,这时候主键作为特殊的唯一索引,在并发插入时如何加。需要说明唯一约束对索引的影响,比如唯一索引的存在会增加的冲突概率,因为每次插入都要检查唯一性,可能导致间隙或者记录的时机可能包括DDL操作,比如ALTER TABLE添加唯一约束时会,或者当执行大批量更新且没有索引时,InnoDB可能升级为。此外,事务中长时间未提交的修改也可能导致保持,影响其他操作。 需要将的时机分点说明,比如自动加的情况,显式加的情况,以及不同存储引擎的区别。然后,唯一约束对索引的影响,包括唯一索引的创建、唯一性检查时的机制,以及可能引起的性能问题,比如高并发下的竞争。 另外,用户可能关心如何避免带来的性能问题,比如合理设计索引,使用合适的隔离级别,或者调整事务大小。同时,唯一索引的使用场景和注意事项,比如在插入大量数据时暂时禁用唯一检查以提高速度,但要注意数据一致性。最后,生成相关问题需要考虑用户可能进一步想了解的内容,比如如何监控的情况,如何优化唯一索引的性能,或者不同隔离级别下的行为差异。需要确保问题覆盖用户可能感兴趣的方面,帮助用户深入理解MySQL和索引机制。</think>### MySQL时机与唯一约束对索引的影响分析 #### 一、MySQL的主要时机 1. **自动加场景** - **数据修改操作**:在执行`INSERT`、`UPDATE`、`DELETE`时,MySQL会根据存储引擎类型自动加。 - **InnoDB**:默认使用行级(记录、间隙、next-key),但若**未命中索引**,可能退化为[^1]。 - **MyISAM**:直接加。 - **事务未提交**:若事务长时间未提交,持有的会持续阻塞其他操作。 - **DDL操作**:如`ALTER TABLE`添加唯一约束时,会触发[^2]。 2. **显式加场景** - 通过`LOCK TABLES ... WRITE/READ`手动。 - 使用`SELECT ... FOR UPDATE`或`SELECT ... LOCK IN SHARE MODE`加行。 $$ \text{升级条件:当行冲突超过阈值(由innodb_lock_wait_threshold控制),InnoDB自动升级为} $$ --- #### 二、唯一约束对索引的影响 1. **唯一索引的创建** - 唯一约束会**自动创建唯一索引**,例如: ```sql ALTER TABLE t_1 ADD UNIQUE(student_id, course_id); ``` 此时会生成名为`student_id`和`course_id`的组合唯一索引[^3]。 2. **唯一性检查的机制** - **插入/更新时的**: - 检查唯一性时,InnoDB会加**间隙(Gap Lock)**或**next-key**,防止其他事务插入冲突值。 - 若设置`unique_checks=0`,会跳过唯一性检查(仅用于批量导入优化),但可能破坏数据一致性[^1]。 3. **性能影响** - **竞争加剧**:高并发场景下,唯一索引的频繁检查可能导致等待(如`Lock wait timeout`)。 - **索引维护成本**:唯一索引要求更高的写入开销(需实时维护唯一性)。 --- #### 三、优化建议 1. **避免退化** - 为高频过滤字段添加索引,确保行生效。 - 使用短事务或`SET autocommit=1`减少持有时间。 2. **唯一索引的合理使用** - 批量插入前可临时禁用唯一检查: ```sql SET unique_checks=0; -- 执行插入 SET unique_checks=1; ``` - 若业务允许重复,优先用普通索引替代唯一索引。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值