MySQL数据库的IO操作

标签: mysql | 发表时间:2012-05-25 17:07 | 作者:admin
出处:http://blog.haohtml.com
导读:
         淘宝丁奇分享的PPT:MySQL数据库的IO操作,详细分享了四块的内容,并且告诉大家如何调整MySQL数据库IO操作相关的参数,给出了详细的选择策略,现替其整理成文章分享与此。
PPT内容提纲:
1.MySQL的文件及简介
2.数据访问流程
3.文件访问模式
4.影响io行为的一些参数和选择策略

1.MySQL的文件及简介

2.数据访问流程

一个简单的查询 select * from t where id>=(  select id from t where k1=100 limit 100000,1) limit 2;

表结构:

CREATE TABLE `t` (

`id` int(11) NOT NULL,

`k1` int(11) DEFAULT NULL,

`data` char(100) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `k1` (`k1`)

) ENGINE=InnoDB DEFAULT CHARSET=gbk;

 

3.数据访问流程

 

4.数据访问流程

一个简单的更新   insert into t values(1, 100, ‘abcd’);

 

5.文件访问模式

1) *.frm

表定义文件。访问特点:极少改动、整体访问–什么模式最适合?

 

2) *ibd

表数据文件。访问特点:大量随机读写–什么模式最适合?

内部什么样?

在传统SAS盘时代,怎么最大化利用磁盘性能?

换了SSD/FUSIONIO 以后呢?

对应的策略带来的数据安全问题—-

3) ib_logfile*

Redolog。 访问方式:顺序读写。

512字节对齐写可以联想到什么?

 

4)MySQL-bin

Binlog。 访问方式:顺序读写。

为什么策略与redolog不同?

 

5)ibdata

数据字典和回滚日志。访问方式:随机读写/顺序写。策略与数据文件类似。

 

6.影响io行为的一些参数和参数对io的影响

以下参数的描述流程:

1>、参数含义

2>、影响哪些流程

3>、对IO的影响和选择策略

 

innodb_file_per_table

innodb_flush_log_at_trx_commit

sync_binlog

innodb_flush_method

binlog_cache_size

innodb_buffer_pool_size

innodb_max_dirty_pages_pct

innodb_read_io_threads/innodb_write_io_threads

………………

 

innodb_file_per_table

1、控制是否每个表数据一个文件

2、推荐配置1的原因?

 

innodb_flush_log_at_trx_commit

1、控制redo log的写盘、刷盘策略

2、安全递增是0 ->2-> 1

3、不同配置的风险和代价

 

sync_binlog

1、控制binlog刷盘策略

2、安全递增是0 ->N -> 1

3、不同配置的风险和代价

4、与上个配置的差别,为什么没有控制写盘策略?

5、 Binlog_cache_use 和 Binlog_cache_disk_use

 

innodb_flush_method

1、控制data或log的刷盘策略

2、可选值

FSYNC O_DSYNC

O_DIRECT

LITTLESYNC NOSYNC

3、一般设置O_DIRECT ,也不够理想 ALL_O_DIRECT

 

binlog_cache_size

1、还没有提交的事务放cache

2、大事务?

3、Binlog_cache_use /Binlog_cache_disk_use

 

innodb_buffer_pool_size

1、InnoDB中最重要的那块内存

2、越大越好,可用内存的80%

3、Insert Buffer最多占一半

 

innodb_max_dirty_pages_pct

1、最大脏页比例

2、什么是脏页

3、脏页更新策略及对性能的影响

 

innodb_read_io_threads/innodb_write_io_threads

1、异步IO线程数

2、不用太大 4/4就够

3、第一次性能测试,请在DBA指导下使用InnoDB_plugin 并作标准配置

 

如果还有时间。。。

作压测时你会碰到的问题和解决思路

1.查询也写盘,原因和方法
2.压测insert的时候那瞬间的抖动,原因和方法

当设备多起来,我们就有更多的选择

1.文件放哪—一个主要思路
2.Ibdata上面的主要更新,矛盾?
您可能也喜欢:

MySQL数据库备份及恢复命令及常用应用举例

MySQL优化篇-查询优化

MYSQL数据库系统的设计架构

mysql数据库大小的限制
无觅

相关 [mysql 数据库 io] 推荐:

MySQL数据库的IO操作

- - haohtml's blog
         淘宝丁奇分享的PPT:MySQL数据库的IO操作,详细分享了四块的内容,并且告诉大家如何调整MySQL数据库IO操作相关的参数,给出了详细的选择策略,现替其整理成文章分享与此. 4.影响io行为的一些参数和选择策略. 一个简单的查询 select * from t where id>=(  select id from t where k1=100 limit 100000,1) limit 2;.

sysbench测试MySQL服务器性能(cpu,io,内存,mysql等)

- - CSDN博客数据库推荐文章
Sysbench的安装请参考http://blog.csdn.net/mchdba/article/details/8951289. sysbench采用寻找最大素数的方式来测试CPU的性能. 首先生成需要的测试文件,文件总大小1000M,16个并发线程,随机读写模式. 执行完后会在当前目录下生成一堆小文件.

淘宝海量数据库之六-克服随机IO难题

- William - 阳振坤的博客
与传统磁盘相比,SSD固态盘提供了非常好的随机读性能,单盘可达35000IOPS (4KB)甚至更高,并提供512MB/s或以上的读出带宽. 但通常SSD盘的随机写性能甚至比一般磁盘更差,这是因为,尽管SSD的读和写都以4KB页(page)为单位,但SSD写入前需要先擦除已有内容,而擦除以块(block)为单位,一个块(block)通常是128个连续的页(page),即512KB.

MySQL数据库的修复

- Xin - 博客园-首页原创精华区
找到mysql的安装目录的bin/myisamchk工具,在命令行中输入:. 然后myisamchk 工具会帮助你恢复数据表的索引. 好象也不用重新启动mysql,问题就解决了. 当你试图修复一个被破坏的表的问题时,有三种修复类型. 如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的.

Fio模拟Mysql服务器IO压力脚本

- 狗尾草 - Erlang非业余研究
原创文章,转载请注明: 转载自Erlang非业余研究. 本文链接地址: Fio模拟Mysql服务器IO压力脚本. fio是个非常好用的io压力模拟工具,功能非常齐全, 有兴趣的同学参看 这里. 这里我用fio模拟我们线上mysql服务器的压力来为厂家送来的pci-ssd卡做压力测试,底下是脚本(已经测试正确),也许有的同学有用.

修改numa和io调度优化mysql性能

- 高春辉 - C1G军火库
单机单实例,建议关闭NUMA,关闭的方法有三种:. 1.硬件层,在BIOS中设置关闭;. 2.OS内核,启动时设置numa=off;. 3.可以用numactl命令将内存分配策略修改为interleave(交叉). 修改mysql.server 330行加上numactl. numastat 查看内存分配.

转:数据库如何抵抗随机IO:问题、方法与现实

- {ZuiZui} - 唐福林-博客雨
随机IO几乎是令所有DBA谈虎色变的一个问题,这个问题,往往在数据量小的时候不出现,在数据量超过内存大小时,才陡然出现,令没有经验的DBA促不及防,也令有经验的DBA寝食难安. 传统的数据库架构对随机IO几乎没有还手之力. 传统数据库的核心通常是页级缓存、B+树、堆或索引组织表,这些机制,对随机IO的抵抗能力,都无一例外的可悲的差.

数据库如何抵抗随机IO:问题、方法与现实

- crystal - 风轻扬
随机IO几乎是令所有DBA谈虎色变的一个问题,这个问题,往往在数据量小的时候不出现,在数据量超过内存大小时,才陡然出现,令没有经验的DBA促不及防,也令有经验的DBA寝食难安. 传统的数据库架构对随机IO几乎没有还手之力. 传统数据库的核心通常是页级缓存、B+树、堆或索引组织表,这些机制,对随机IO的抵抗能力,都无一例外的可悲的差.

一次IO利用率100%,数据库大量全表扫描问题

- - CSDN博客推荐文章
 1, 具体什么业务受到影响不清楚,但从系统测看,主机IO资源比较紧张(HPUX 11.31 +oracle 9i). glance看IO已接近100%. 2,数据库侧看,大量db file scattered read IO相关等待事件. 3,等待的sql具体如下,主要原因是对ai.RM_A_x全表扫描,该表72GB大小.

当内存512遇上Access数据库600M,IO磁盘受伤了

- - 博客园_首页
服务器内存就512M,Access数据库(文章库)600多M,结果竟然就是IO受伤了. 秋色园技术原理解析 系列,园里不少看过的帅歌,应该有点印象,从开始到现在,还是铁打的Access数据库. 虽然本人目前对Access恨入之骨,皆因囊中羞涩,暂时不得不与之同流合污. 忙碌 微博粉丝精灵几个月来, 秋色园一直运行正常,除了远程界面都变的很卡之外,基本上也没发现什么异常.