在MySQL5.7之前的版本中, InnoDB每次做crash
recovery之前都需要扫描数据目录,打开每个文件并创建内存对象。当目录下文件个数特别多时,会严重影响到崩溃恢复的速度。
为了解决这个问题,MySQL5.7通过结合checkpoint + 标注被修改的文件的方式,从一个check
【mysql】 【innodb】 【crash】 【recovery】 点击查看原文>
Nov
21
2016
Nov
21
2016
Nov
21
2016
Nov
21
2016
Nov
21
2016
Nov
21
2016
Nov
21
2016
做MySQL的都知道,数据库操作里面,DDL操作(比如CREATE,DROP,ALTER等)代价是非常高的,特别是在单表上千万的情况下,加个索引或改个列类型,就有可能堵塞整个表的读写。
然后 mysql 5.6 开始,大家期待的Online DDL出现了,可以实现修改表结构的同时,依然允许DML操...
【mysql】 【Algorithm】 【lock】 【索引】 【session】 【metadata】 …
Nov
21
2016
做MySQL的都知道,数据库操作里面,DDL操作(比如CREATE,DROP,ALTER等)代价是非常高的,特别是在单表上千万的情况下,加个索引或改个列类型,就有可能堵塞整个表的读写。
然后 mysql 5.6 开始,大家期待的Online DDL出现了,可以实现修改表结构的同时,依然允许DML操...
【mysql】 【Algorithm】 【lock】 【索引】 【session】 【metadata】 …
Nov
20
2016
0、导读
有个MySQL服务器的磁盘I/O总有过高报警,怎么回事?
1、问题
我的朋友小明,TA有个MySQL服务器最近总是报告磁盘I/O非常高,想着我这有免费的不用白不用的企业技术服务(TA自己这么想的),就找我帮忙给把把脉。
作为一个经验丰富(踩坑不断)的DBA,出现这种问题,一般来说,磁盘I/O很高无非是下面几个原因引起:
- 磁盘子系统设备性能差,或采用ext2/ext3之类文件系统,或采用cfq之类的io scheduler,所以IOPS提上不去;
- SQL效率不高,比如没有索引,或者一次性读取大量数据,所以需要更多的I/O;
- 可用内存太小,内存中能缓存/缓冲的数据不多,所以需要更多的I/O。
方法论已有,接下来就是动手开始排查了。
2、排查
…
[获取更多]
Nov
20
2016