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 并作标准配置
如果还有时间。。。
作压测时你会碰到的问题和解决思路
当设备多起来,我们就有更多的选择
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
现在就InnoDB一部分可以改善性能的参数列举
1. innodb_additional_mem_pool_size
除了缓存表数据和索引外,可以为操作所需的其他内部项分配缓存来提升InnoDB的性能。这些内存就可以通过此参数来分配。推荐此参数至少设置为2MB,实际上,是需要根据项目的InnoDB表的数目相应地增加
2.innodb_data_pool_size
此参数类似于MySQL的key_buffer参数,但特定用于InnoDB表.这个参数确定了要预留多少内存来缓存表数据和索引。与key_buffer一样,更高的设置会提升性能,可以是服务器的内存70-80%
3.innodb_data_file_path
参数的名字和实际的用途有点出入,它不仅指定了所有InnoDB数据文件的路径,还指定了初始大小分配,最大分配以及超出起始分配界线时是否应当增加文件的大小。此参数的一般格式如下:
path-to-datafile:size-allocation[:autoextend[:max-size-allocation]]
例如,假设希望创建一个数据文件sales,初始大小为100MB,并希望在每次达到当前大小限制时,自动增加8MB(8MB是指定autoextend时的默认扩展大小).但是,不希望此文件超过1GB,可以使用如下配置:
innodb_data_home_dir =
innodb_data_file_path = /data/sales:100M:autoextend:8M: max:1GB
如果此文件增加到预定的1G的限制,可以再增加另外一个数据文件,如下:
innodb_data_file_path = /data/sales:100M:autoextend:8M: max:1GB;innodb_data_file_path = /data2/sales2:100M:autoextend:8M: max:2GB
要注意的是,在这些示例中,inndb_data_home_dir参数开始设置为空,因为最终数据文件位于单独的位置(/data/和/data2/).如果希望所有 InnoDB数据文件都位于相同的位置,就可以使用innodb_data_home_dir来指定共同位置,然后在通过 inndo_data_file_path来指定文件名即可。如果没有定义这些值,将在datadir中创建一个sales。
4 innodb_data_home_dir
此参数指定创建InnoDB表空间的路径的公共部分,默认情况下,这是MySQL的默认数据,由MySQL参数datadir指定
5. innodb_file_io_threads
此参数指定InnoDB表可用的文件I/O线程数,MySQL开发人员建议在非Windows平台中这个参数设置为4
6. innodb_flush_log_at_trx_commit
如果将此参数设置为1,将在每次提交事务后将日志写入磁盘。为提供性能,可以设置为0或2,但要承担在发生故障时丢失数据的风险。设置为0表示事务日志写入日志文件,而日志文件每秒刷新到磁盘一次。设置为2表示事务日志将在提交时写入日志,但日志文件每次刷新到磁盘一次。
7.innodb_log_archive
因为MySQL目前使用自己的日志文件恢复InnoDB表,此参数可设置为0
8.innodb_log_arch_dir
MySQL目前忽略此参数,但会在未来的版本中使用。目前,应当将其设置为与innodb_log_group_home_dir相同的值
9.innodb_log_buffer_size
此参数确定些日志文件所用的内存大小,以M为单位。缓冲区更大能提高性能,但意外的故障将会丢失数据.MySQL开发人员建议设置为1-8M之间
10. innodb_log_file_size
此参数确定数据日志文件的大小,以M为单位,更大的设置可以提高性能,但也会增加恢复故障数据库所需的时间
11.innodb_log_files_in_group
为提高性能,MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3M
12. innodb_log_group_home_dir
此参数确定日志文件组中的文件的位置,日志组中文件的个数由innodb_log_files_in_group确定,此位置设置默认为MySQL的datadir
13.innodb_lock_wait_timeout
InnoDB 有其内置的死锁检测机制,能导致未完成的事务回滚。但是,如果结合InnoDB使用MyISAM的lock tables 语句或第三方事务引擎,则InnoDB无法识别死锁。为消除这种可能性,可以将innodb_lock_wait_timeout设置为一个整数值,指示 MySQL在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)
14.skip-innodb
启用此参数能防止夹杂InnoDB表驱动程序,不使用InnoDB表时推荐此设置