Tuning I/O
1. 影响同步数据到disc和恢复数据，因为涉及到了io，对性能影响非常大，其实是在性能与数据安全性上找一个平衡
2. MyISAM
delay_key_write：延缓index写入disc
OFF：除非table使用LOCK TABLE锁了，每次对key buffer的修改都flush到disc
ON：可以延迟写，需要index建立时声明DELAY_KEY_WRITE
ALL：所有的表都延迟写
延迟写有用，但通常不会特别明显，对数据小，read命中好 write命中差的作用大，缺点：
server崩溃，block未写入disc：index会崩溃
close table速度变慢
同里flush table也会更久
dirty block占据key buffer，新的block要等flush，因此使query受阻
控制MyISAM从崩溃中恢复：myisam_recover
mysql> SHOW VARIABLES LIKE 'myisam_recover_options';
DEFAULT(or no setting):恢复标志为crashed的表
BACKUP：使Mysql将数据文件的备份写入一个.bak文件，
FORCE：即使多于一行的数据丢失，也从.myd文件恢复
QUICK：除非有delete block，跳过；delete block有已删除的数据，但仍然占着空间，将来insert语句可以从用之
可以用多个，如BACKUP，FORCE表示force recovery同时备份
如果表小的话，enable之，一个有怀表的server可能会产生更多的corruption,甚至server崩溃
大表不现实，会导致server在表open的时候check和repaire所有的表，效率很低
3. InnoDB IO
不仅控制recover，还可以flush和open data
InnoDB的recovery process在InnoDB start时自动运行，但是行为可控
除了recovery，而且假定没有crash，也是还有很多需要配置：buffer file保证性能和acid
常用的最重要的是InnoDB的log file size
trasaction log：减少事务提交的cost，每次提交并非将buffer flush到disc，而是log
random io要比sequence io更昂贵
log将random变为sequence
后台程序负责flush到file 可以group write、使data sequential
log file大小innodb_log_file_size innodb_log_files_in_group
logfile的大小需要在常规用户修改量与崩溃后恢复时间要求之间找平衡
log太小需要频繁些，log太大recovery需要很多时间
innodb_log_buffer_size：修改先写入log buffer，在ts commit或每秒 将buffer写入logfile，不该太大1-8M就够，除非大量的blob
show status :Innodb_os_log_written：监视10-100秒，判断log buffer是否合理(每秒100K，那么1M的log就是足够的)
innodb_flush_log_at_trx_commit：where and how log buffer is flushed
0:每秒1次， ts commit不做
1：ts commit buffer写入logfile 并且flush(flush会有disc写，很慢；现在告诉硬盘每秒也只能做几百个disc的事务)
2:每次commit 将buffer写入logfile但是不flush，每秒flush
一般OS buffer to log只是将数据从buffer移到os 的cache，flush是真正持久化
高性能的事务需求的配置是：设置为1 logfile使用RAID(写cache有备份电池)
innodb_flush_method：InnoDB如何与filesys交互，也会影响如何读数据，Windows仅可使用(async_unbuffered, unbuffered, and normal),其他OS默认fdatasync
fdatasync
O_DIRECT：
O_DSYNC：对logfile的open()调用加入O_SYNC参数
配置tablespace：
innodb_data_home_dir = /var/lib/mysql/
innodb_data_file_path = ibdata1:1G;ibdata2:1G;ibdata3:1G
innodb_data_file_path = /disk1/ibdata1:1G;/disk2/ibdata2:1G;不会获得性能提升，mysql填完第一个在填第二个
自增长：ibdata3:1G:autoextend:max:2G
回收的方法：导出数据；关server；删数据文件；修改配置；重启；mysql建新的空文件；导入数据
innodb_file_per_table：每个table一个文件，便于回收(drop table),表跨多个disc也有用处；但是可能浪费空间(每个表至少16K)
4. Tuning Concurrency
MyISAM不支持MVCC，并发insert只有在表尾发生，concurrent_insert:
0：不支持并发insert
1：如果没有hole(标志删除的行)，就可以并发insert
2：5.0后，有hole也在表尾并发insert
InnoDB设计用于高并发，但是并不完美，他的架构还是根源于有限内存、单cpu、单disc，高并发情况下性能下降非常厉害，唯一方法是限制并发
innodb_thread_concurrency：能进入engine内核访问data的thread的数量，如果发生并发问题，这个参数配置最重要
通常的并发数量合理的值：concurrency = Number of CPUs * Number of Disks * 2，实际情况可以小一些，自己benchmark
如果到内核的thread到达上限，首先等待innodb_thread_sleep_delay，再试；还是不行，进入等待队列，通知OS
innodb_concurrency_tickets：已经进入kernel后，thread可以拥有ticket，在进入时不需限制；除非有大量长时间运行的query，他是不需要修改的
innodb_commit_concurrency：在flush时，多少thread可以同时提交，
5. workload-based Tuning
在server压力达到峰值时，查看进程列表，主要受那些query影响，是想tmpTable拷贝数据太多还是排序，这样可以调整对应参数
使用pack 查看mysql log，提供每个query的信息以及workload的详细清况
BLOB and TEXT Workloads
不能使用内存临时表
Show Global status：
Aborted_clients：一直增加的话，没有合理关闭连接
Aborted_connects：接近0，连接问题
Binlog_cache_disk_use/Binlog_cache_use：比值比较大，增加后者；仅减少miss比一定合理，关键是增加后者，观察miss是否减少，miss少到一定程度增加后者也没用了
Bytes_received/Bytes_sent:是否传送了太多的数据
Com_*:保证没有高于预期的值
Connections：尝试连接的数量，每秒增加很快的话，查看连接池和os的networking stack
Created_tmp_disk_tables：高的话 1.使用了blob/text 2.tmp_table_size/max_heap_table_size不够大
Created_tmp_tables：这个值过高的唯一方法是优化query
Handler_read_rnd_next/Handler_read_rnd：全表扫描的平均大小，过大，需要优化schema index query
Key_blocks_used：Key_blocks_used * key_cache_block_size远小于key_buffer_size，那么key_buffer_size就是大于所需，浪费内存
Key_reads：每秒钟的read，与IO系统的比较，是否达到io 的limit
Max_used_connections：如果与max_connections同样大，或者max_connections过小，或者峰值超过了server的配置，但也不能直接增加max_connections，他保护server压力过大，如果是一个陡峭的峰值，查看应用，server配置，schema，不要轻易增加这个值
Open_files：不要接近open_files_limit，否则需要增加open_files_limit
Open_tables/Opened_tables:与table_cache比较，如果每秒Opened_tables过大，那么table_cache不够大；
Qcache_*：
Select_full_join：fullJoin是没有使用index的join，严重影响性能，每分钟有一个也嫌多；
Select_full_range_join：这个值高，说明有大量query使用range查询jointable，会很慢
Select_range_check:high，某些query没有合适的index
Slow_launch_threads：high，sth阻碍的新的thread连接；暗示server出问题了
Sort_merge_passes：high，应该增加sort_buffer_size
Table_locks_waited：多少个表被锁，在server级别(engine row级别的不会增加)导致lock wait;high并且增加 说明有严重的并发瓶颈
Threads_created:large而且增加，需要增加thread_cache_size
6. 连接级别的Tuning
sort_buffer_size：通常应该比较小，为特殊的query设大
SET @@session.sort_buffer_size := ;
-- Execute the query...
SET @@session.sort_buffer_size := DEFAULT;
read_buffer_size
read_rnd_buffer_size
tmp_table_size
myisam_sort_buffer_size
