前言：
这本的标题起的真好
正文：
8.5配置mysql的I/O行为
性能和数据安全间的较量
8.5.1InnoDB I/O配置
控制怎么恢复（启动时自动ing）、打开和刷新数据
InnoDB事务日志：
innodb变更任何数据时，会写条变更记录到内存日志缓存区；缓存满时 事务提交时 或每一s innodb都会刷写缓存区内容到磁盘日志文件
日志条目紧凑，不基于页，不会一次存储整页（浪费空间）
日志缓冲写到日志：简单将数据从InnoDB内存缓冲转移到操作系统的缓存（内存中）无持久化存储；
日志刷新：innodb请求操作系统把数据刷出缓存，且确认写到磁盘（慢），阻塞I/O调用;
1、 减少提交事务时开销，日志记录事务、无须每次提交时刷新脏块到磁盘
2、事务修改的数据和索引映射到表空间随机位置：随机I/O(请求时磁头移到正确位置,读出需要的部分 转到开始位置)
3、日志将随机I/O变几乎顺序的日志文件 数据文件I/O，日志写到磁盘=事务持久化，未写到、可重放日志 恢复已提交事务
4、最后后台线程只能将变更环形写到数据文件（日志大小固定）：写到尾部 跳转开头继续 不覆盖未到数据文件的：清掉已提交的记录
5、日志文件大小受控于innodb_log_file_size和innodb_log_files_in_group，默认共10M，对高性能工作 least *百MB；修改大小 ：完全关闭MySQL、旧文件移到其他地方 重配参数 重启 删除旧文件
大小：权衡正常数据变更开销和崩溃恢复需要的时间，太小 做more检查点 更多日志写 太大崩溃恢复时不得不做大量工作 增加恢复时间
数据大小 访问模式影响恢复时间 较短的行使更多修改 可放在同样日志中 so可能必须在恢复时重放更多修改操作：innodb条目紧凑 不基于页 不费空间存储整页
6、如有大事务，增加日志缓冲区（默认1MB）可减少I/O，变量innodb_log_buffer_size可控制日志缓冲区大小，不需要设得很大，1~8MB除非要写很多大的blob记录
较大的缓存区可减少争用区内空间分配
7、检查show innodb status 的log监控日志 日志缓冲区I/O性能， 通过innodb_os_log_written状态变量查看innodb对日志文件写了多少数据
经验：10~100s间隔的数字 记录峰值 —判断日志缓冲是否设置得正好：日志文件大小应容纳服务器1h活动内容
8、刷新日志缓冲：使用mutex锁住缓冲区 刷新到所需位置 移动剩下条目到缓冲区前 mutex释放时maybe more one 事务准备好刷新日志记录 group commit使一个I/O提交多个事务
缓冲须刷新到持久化存储 确保提交的事务完全被持久化，如更在乎性能 修改innodb_flush_log_at_trx_commit控制日志缓冲刷新频繁程度
0：日志缓冲写到日志文件，每秒钟刷新一次，事务提交不做任何事
1：缓冲写到日志文件，每次事务提交都刷新到持久化存储（默认，最安全）保证不丢失任何已提交的事务，除非磁盘或操作系统是“伪”刷新
2：每次提交时把日志缓冲不刷新写到日志文件，InnoDB每秒做一次刷新；如mysql挂了，2不丢事务，整个服务挂了、断电了，可能会丢失一些事务
9、最佳配置：设置innodb_flush_log_at_trx_commit=1 且日志文件放到有电池保护的写缓存RAID卷中，（=1降低每s可提交的事务数；否 可能导致丢失事务）如不在意持久性，其他值也可以
InnoDB怎样打开和刷新日志以及数据文件
innodb_flush_method配置innodb如何跟文件系统相互作用：读写 日志、数据文件
windows和非windows操作系统对这个选项的值时互斥的
如果使用类UNIX操作系统且RAID控制器带有电池保护的写缓存，建议使用O_DIRECT，否则默认值或O_DIRECT推荐，具体看应用类型
值范围：
1、fdatasync非windows上的默认值 刷新文件数据
- innodb通常用fsync代替fdatasync来刷新数据、日志文件（more I/O）
- fdatasync似fsync但只刷新文件的数据，某些场景下导致数据损坏
- fsync缺：操作系统在self缓存中缓冲些数据（双重缓冲浪费但如让文件系统do更智能I/O调度 批量操作 好处：both系统写合并执行、预读优化）
- innodb_file_per_table导致每个文件独立做fsync：写*表不能合并到一个I/O
2、O_DIRECT：依赖操作系对数据文件做标记或directio函数
- 不影响日志，部分类unix系统有效（gnu linux FreeBSD Solaris55.0），almost系统用fcntl设置文件描述符的这一标记
- fsync刷新文件到磁盘，通知操作系统不缓存数据不预读，读写直接通存储设备
- 需带有写缓存的RAID卡且设置为Write-Back（写入会在RAID上缓存上缓冲：only stay 好性能）
- 可能导致服务器预热时间变长，也可能导致小容量的缓冲池比缓存I/O操作慢
- 不对innodb_file_per_table产生额外损失，当使用该标记不用i_f_p_t，maybe 由于some顺序I/O 性能损失
RAID是一种把多块独立的物理硬盘按不同的方式组合起来形成一个硬盘组（逻辑硬盘），从而提供比单个硬盘更高的存储性能和提供数据备份技术;
3、ALL_O_DIRECT：
percona server、 mariadb用，服务器打开日志文件时也能用标准mysql打开数据文件的方式O_DIRECT
4、O_DSYNC
日志文件调用open时设置O_SYNC标记，使得all写同步，不影响数据文件
O_SYNC：不禁用操作系统层的缓存，在缓存中写数据 发送到磁盘： 操作系统maybe把“使用同步I/O”标记下传给硬件层：tell设备不要使用缓存、把修改过的缓冲数据刷写到设备上，（如果设备支持 接着传递个指令给设备刷新它自己的缓存）每个write pwrite在函数完成前把数据同步到磁盘 阻塞
不用O_SYNC标记的写入调用fsync容许写操作积累在缓存 一次性刷写alll data
O_SYNC：同时同步数据 元数据 O_DSYNC：同步数据
5、async_unbuffered：
Windows默认值，让innodb对almost写 使用无缓冲的I/O
当innodb_flush_log_at_trx_commit=2，对日志文件使用缓冲I/O
在Windows2000 XP 更新版本对数据读写all用操作系统原生异步（重叠）I/O
6、unbuffered
Windows有效，与5类似，不使用原生异步I/O
7、normal：
Windows有效，让innodb不使用原生异步I/O或无缓冲I/O
8、nosync 和littlesync
开发使用，对生产环境来说不安全，不应该使用
InnoDB表空间
数据保存在表空间内：本质一个由一个或多个磁盘文件组成的虚拟文件系统
innodb用表空间存储表 索引 回滚日志 插入缓冲 双写缓冲 其他内部数据结构
配置表空间
innodb_data_file_path定制表空间文件：放在innodb_data_home_dir目录下
回收空间方式：导出数据 关闭mysql 删除all文件 修改配置 重启 创新数据文件 导入数据：如果表空间损坏 innodb拒绝启动 （傲娇一把）
innodb_file_per_table让innodb为每张表使用一个文件：在数据字典存储为“表名.ibd”：删除一张表时回收空间简易
打开该选项，仍需为回滚日志 其他系统创建共享表空间（不把all数据存其中：明知 best关闭自动增长）
更差的drop table性能：某些文件系统慢 删除时锁定、扫描缓冲池（可从percona server的一个修复中获益让服务器慢慢清理掉被删表的页面）
建议：使用innodb_file_per_table且给共享表空间设置大小范围
innodb页16kb，即使表只有1kb的数据
行的旧版本和表空间：
只有改变了数据的事务才创建旧版本的行
没有清理的行版本会对all查询尝试影响，使得表和索引更大，清理现场跟不上、性能显著下降，新版本清理过程显著提升了性能且分离出来了、可建多个
双写缓冲：避免页没写完所导致的数据损坏
是表空间特殊保留区域，本质是最近写回的页面的备份拷贝；
容许日志文件更加高效（不必要包含整页，更像页面二进制变量）
每个页面末尾有校验值，不匹配 损坏 恢复时 innodb需读取缓冲页面且验证校验值，值不对、从它原始位置读取该页面
innodb_doublewrite=0关闭
其他的I/O配置项
1、sync_binlog控制mysql怎么刷新二进制日志到磁盘，默认0：不刷新 操作系统决定何时；比0大 指定两次刷新到磁盘的动作间隔多少二进制日子写操作
不设置1，崩溃后可能导致二进制日志误同步事务数据：导致复制中断，不可能及时恢复，可能比innodb_flush_log_at_trx_commit更损性能
将带有电池保护写缓存的高质量RAID控制器设置为使用写回策略，可支持每秒数千的写入，且保证写到持久化存储，显著提升性能
小结：
innodb I/O配置 内存很多，应该撑得起I/O的分量吧