作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO
联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬
学习必须往深处挖,挖的越深,基础越扎实!
阶段1、深入多线程
阶段2、深入多线程设计模式
阶段3、深入juc源码解析
码哥源码部分
码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】
码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】
码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作?】
码哥讲源码【谁再说Spring不支持多线程事务,你给我抽他!】
打脸系列【020-3小时讲解MESI协议和volatile之间的关系,那些将x86下的验证结果当作最终结果的水货们请闭嘴】
4-3-3-3、避免死锁的建议
上一篇文章我们主要介绍了MySQL数据库中锁的基本原理、工作过程和产生死锁的原因。通过上一篇文章的介绍,可以确定我们需要业务系统中尽可能避免死锁的出现。这里为各位读者介绍一些在InnoDB引擎使用过程中减少死锁的建议。
- 正确使用读操作语句
经过之前文章介绍,我们知道一般的快照读是不会给数据表任何锁的。那么这些快照读操作也就不涉及到参与任何锁等待的情况。那么对于类似insert…select这样需要做当前读操作的语句(但又不是必须进行当前读的操作),笔者的建议是尽可能避免使用它们,如果非要进行也最好放到数据库操作的非高峰期进行(例如晚间)。
- 基于索引进行写操作,避免基于表扫描(聚集索引扫描)进行写操作
基于索引进行写操作的目的是保证一个写操作性质的事务中,被锁住的索引和需要请求的锁定资源被控制在最小范围内。而避免使用表锁的原因是保证一个写操作性质的事务中,不会额外锁住完全不需要的索引资源或者抢占完全不需要的索引资源。表锁虽然不会直接导致死锁,但是由于表锁的工作方式,导致它成为死锁原因的几率增大了。
- 避免索引失效
使用索引一定要注意索引字段的类型,例如当字段是一个varchar类型,赋值却是一个int类型,就会导致索引失效。如下所示:
explain select * from myuser where user_name = 1
# user_name 字段的类型是varchar,该字段建立了一个非唯一键索引
# 但是以上语句在使用字段进行检索时,却使用了一个int作为条件值。
# 通过MySQL的执行计划可以看到,InnoDB引擎在执行查询时并未使用索引,而是走的全表扫描
+----+-------------+-------+------+---------------+-----+------+-------------+
| id | select_type | table | type | possible_keys | key | rows | Extra |
+----+-------------+-------+------+---------------+-----+------+-------------+
| 1 | SIMPLE | myuser| ALL | name_index | | 13 | Using where |
+----+-------------+-

最低0.47元/天 解锁文章
639

被折叠的 条评论
为什么被折叠?



