MYSQL调优课题

1,343 阅读4分钟

1 msyql的执行过程

image.png

mysql缓存

a. 查看缓存的配置项 SHOW VARIABLES LIKE '%query_cache%';

image.png

query_cache_type | OFF 关闭缓存

MySQL缓存是默认关闭的,也就是说不推荐使用缓存,并且在MySQL8.0 版本已经将查询缓存的整块功能删掉了。这主要是它的使用场景限制造成的: 先说下缓存中数据存储格式:key(sql语句)- value(数据值),所以如果SQL语句(key)只要存在一点不同之处就会直接进行数据库查询了; 由于表中的数据不是一成不变的,大多数是经常变化的,而当数据库中的数据变化了,那么相应的与此表相关的缓存数据就需要移除掉;

b. sql解析器 sql解析器报错 image.png

c. 查询优化器

select * from province inner join city on city.fid = province.id where province.id = 1; 先查哪一个表由优化器指定

2 查询排序

explain select * from s1 where id > 100 order by id limit 1000;

image.png

Extra 字段中是包含 Using filesort 说明sql需要再排序

image.png

3 连表查询

Index Nested-Loop JoinSimple Nested-Loop JoinBlock Nested-Loop Join

a. Index Nested-Loop Join 翻译过来的意思是:索引循环嵌套链接,简称 INLJ。它是基于索引的链接算法

explain
SELECT * FROM test_joinv1 STRAIGHT_JOIN test_joinv2 ON (test_joinv1.m = test_joinv2.m)

image.png

image.png

image.png

这是使用索引的情况下,如果不使用索引查询就会很慢了,因为要扫描全表,但是真的扫描全表了吗?继续看

b. Simple Nested-Loop Join 简单嵌套循环链接,简称 SNLJ。这个算法没有做任何优化,每一次查询都会扫描链接的所有表,性能低下

SELECT * FROM test_joinv1 STRAIGHT_JOIN test_joinv2 ON (test_joinv1.m = test_joinv2.n)

image.png

执行计划里面显示使用了Block Nested Loop

Block Nested Loop 缓存块嵌套循环链接,简称 BNLJ。这种算法是使用缓存块将所有的数据在内存中进行比较(主要是内存的速度非常快),其核心是利用内存的空间换取时间 也即是在内容中计算,如果内存不足就循环扫描表加入内存,扫描次数增加查询也会变慢,所以大数据量还是会慢

4 索引

使用or,关于组合索引,我的以往工作中使用过一次组合索引,在一个很奇葩的现象中

explain select * from test_joinv1 where m =12 or id =0

image.png

唯一索引和普通索引的区别 在B+树里面,普通索引会一直找,唯一索引找到了就返回了

5 事务

redo日志是物理日志,undo日志是逻辑日志 image.png

6 锁

全局锁 flush tables with read lock;数据迁移时使用

表锁 lock tables [tableName] read/write

行锁

共享锁 lock in share mode 共享锁的使用场景是保证数据库中数据与数据之间的关系

共享锁的主要功能是:在某个事务中某条数据只要加上了共享锁,那么对于其他的事务来说该条数据将可读但是无法修改 场景主要用于后面插入的数据以来前面的数据

select * from test_joinv1 where id =1 lock in share mode

image.png 这时候在另一个会话中查询时没有问题的,但是删除和修改时不行的

image.png 加上共享锁后,另一个会话执行删除,那么他就要等待,这个等待时间mysql时可以修改的,语句SET GLOBAL innodb_lock_wait_timeout=100,有时候方法执行缓慢的原因很可能就是由于锁导致的

排他锁 for update

在一个事务中一个更新的操作会自动添加排他锁

begin; update test_joinv1 set m=192199433 where id = 3; commit

image.png

行锁升级为表锁

begin; update test_joinv1 set m=192199433 where n = 3;

image.png

行锁锁的其实时索引,更新的条件没有家索引,那么行锁就变成了表锁,影响了性能

死锁

image.png

查询一条数据有时慢有时快的原因 正常我们把数据放入buffer pool如果buffer pool满了就要进行写入磁盘io,就会依赖磁盘的io速度,可以通过调整 innodb_io_capacity 参数的方式来避免

7 事务隔离级别

幻读

update test set b = 11 where b = 10; update test set b = 10 where b = 80; insert into test values (100,100,10); 间隙锁 锁定某一个范围,这个范围中的数据全部都归该锁控制,以至于其他事务无法操作相关范围的数据 MySQL 不仅会锁定b=10的相关数据,还会锁定相关的 7 区间,此时如果你想修改相关数据和新增相关的数据时,都是阻塞状态。 (-∞, 10]、(10, 20]、(10, 30]、(10, 40]、(10, 50]、(10, 60] 以及 (60, +∞)

8 主从复制

show slave status 查看是否开启主从

image.png

image.png