mysql存储引擎优化参数
MySQL 配置参数优化 本文来自道森学习笔记，版权归 http://wubx.net/所有 MyISAM 存储引擎优化 涉及参数如下： Key_buffery_size Concurrent_insert = 2 | WAAYS Bulk_insert_buffer_size=8M Myisam_recover_options=FORCE Myisam_recover_threads=1 Myisam_
MySQL配置参数优化
本文来自道森学习笔记，版权归 http://wubx.net/ 所有
MyISAM存储引擎优化
涉及参数如下：
Key_buffery_size
Concurrent_insert = 2 | WAAYS
Bulk_insert_buffer_size=8M
Myisam_recover_options=FORCE
Myisam_recover_threads=1
Myisam_sort_buffer_size=1G
参数解释：
key_buffery_size
主要用于存放myisam表的索引信息，而且还有专门的IO调度算法，如果搞不定将会将其buffer冲掉
#在mysql 5.6版本默认引擎调整为了innodb，临时表默认引擎也一样，所以myisam引擎基本调整一下key_buffer_size 即可，但是不能禁掉，因为mysql库目前里面大多数都是myisam
只有几张表是innodb，所以这里面很多都是myisam引擎 不能将其禁掉
但是对于5.6版本中key_buffer_size 给8M就可以
bulk_inser_buffer_size = 8M (默认)
在高版本中默认8M，低版本默认还是4M；所以如果小的话可以改大一点，这个值通常来说一般sql为 ：
insert into tb (c1,c2,c3) values(),()....;
如果配置的是1M，那么insert执行了4M的数据，这样的话会报错，默认情况下不用调整，但是如果做数据采集之类的场景，需要将其调大
对于myisam表 可能会出现坏掉了之类的情况，这个里面可以将以下几个参数开打：
Myisam_recover_options=FORCE
Myisam_recover_threads=1
Myisam_sort_buffer_size=1G
这样会自动进行修复，对于myisam表是一种修复
本文来自道森学习笔记，版权归 http://wubx.net/ 所有
但是有缺点，如果使用Myisam_recover_options=FORCE ，很可能会丢失数据，因为myisam表已经不能保证数据一致性，所以丢数据也避免不了，所以，如果业务数据非常重要，对于安全性要求很高，那么尽量不要用myisam
因为5.5之后官方不会对myisam做任何升级和维护；5.6之后默认引擎为innodb。临时表也改为innodb
本文来自道森学习笔记，版权归 http://wubx.net/ 所有
innodb引擎优化
innodb_buffer_pool_size （面试必问）
主要存放热数据，按照page来存放，page为最小单位，甚至是按段来存放
建议值： 如果是专用数据库server 建议分到物理内存的50% -- 75%
如果跑有其他服务，那么建议“2/8的原则”：
比如100G的数据，最少达到10%的活跃数据，那么建议buffer pool分20G
如果是好友关系系统，这样的数据都几乎是热数据，那么建议30%-50%的内存
再比如偷菜游戏，几乎所有都能达到90%的热数据，那么你懂的
innodb_buffer_pool_instances
主要为了方便buffer pool全局的锁，
一般情况下设置为8 ，在5.5版本是分到4 ，到了5.6版本之后要分到8，不能改成其他值，因为这是压测得出的结果，8是可能得到最好的性能
innodb_log_file_size
建议设置为data page的百分比，比如page为15% 那么buffer pool为100G ，那么两边相乘得出结果为15G，其实建议的是与data page配置的相等，有可能都配置不了那么大，那么就将file_size设置为1g
那么如果我们要用多个log file，就会涉及到以下参数 ：
innodb_log_file_in_gourp
可以设置有几个log文件，至于如何计算：
Innodb的redo log 文件大小，总大小为innodb_log_file_size *
Innodb_log_file_ingroup 总大小不要低于600M
一般建议3个log file即可 多了没有必要
本文来自道森学习笔记，版权归 http://wubx.net/ 所有
innodb_file_per_table
是否设置独立表空间
在5.6之前是关闭的， 在5.6之后默认为打开，建议是打开状态
innodb_file_format #建议指定为 Barracuda
innodb_flush_log_at_trx_commit
如果在导数据，可能是2天或者3天也没有导完，那么可能是这个参数设置为1的结果导致
1 为每一次事务进一次刷新到磁盘，安全度高，但是性能最低，经常会导致导数据最慢
0 每秒钟进一下事务的刷新到磁盘
2 一般建议值，大约每秒一次事务的刷新及同步到磁盘，实际只写到操作系统的buffer中，操作系统如果断电会导致失误丢失；#因为导数据都是人为参与的过程所以设置为2，让速度最大化完成，如果出错再手动搞一次即可，建议值
innodb_flush_log_at_timeout (在5.6中被引入）
·该参数用于控制每N秒（1-2700秒之间）刷新一次日志。是对group commit的一个增强功能，默认是1秒，1秒钟刷新一次并由croup commit来处理，实际可以在1-2700秒之间来搞，如果系统对性能要求很高，可以将这个值设置大一些，吞吐率也会更高，因为group commit工作也会更好一点，如果说对同步实时性要求很高，那么就设置低一点，默认值即可
之间是一个相对的关系，如果调大会得到一个很好的性能，但是从库可能会出现延迟
如果调整为3秒，那么这3秒做一次commit，那么在第2秒的时候挂掉了，那么在这2秒的时候数据会丢失
innodb_flush_method
用指定数据实际写到磁盘上的方法，直接使用O_DIRECT即可
O_DIRECT 工作在XFS或EXT4上性能都很不错的
最大问题就是O_DIRECT用来减小系统的VFS级别的cache，节省出来的内存可以提供buffer pool来使用
如果用fsync来做，其会占用vfs级别的cache，会占用大量内存，如果buffer pool很大，那么容易造成oom
所以使用O_DIRECT来做是为了节省内存提供buffer pool更大空间
innodb_flush_neighbors
默认是0 在用这个参数之后会临近extent脏页面进行刷新
比如在进行写入的时间，会将脏也进行check ，这个时间会将脏页面合并成顺序写 就是说将临近的extent也合并进去
再比如第一个extent和第二个extent 是挨着的，那么移到这里之后发现第二个也有，那么顺便将第二个也刷过去
如果是sas sata 盘建议使用1；但是对于ssd是没有寻址延迟，所以不需要脏页面刷新，因为原先就是热数据但是刷新之后又变为冷数据数据又会做一次加载
本文来自道森学习笔记，版权归 http://wubx.net/ 所有
IO相关优化
innodb_io_capacity #重要
该参数为innodb io最大数
一般来说10W iops很正常，后期进行了优化： hdd 150 * 磁盘数 ， ssd 2000-1万
比如 6块盘做了RAID10 那么这样计算的话是 150*3
需要考虑的是6块盘做的RAID 需要考虑多少快盘的IO能力 ；再考虑如果先做RAID 1能否提升IO能力，如果不能提升那么无非是0可以提升IO能力，所以是6块盘的RAID10 只能获得3块盘的IO能力
以下是对capactiy的补充参数
比如这里配置的是3块盘的450个，但是峰值会更高，可能会达到1000个或更多，那么可以对以下参数指定最大值
innodb_io_capacity_max #设置io_capacity 最大值
读写相关：
Innodb_write_io_threads
Innodb_read_io_threads
建议配置值：
保持与CPU的数量一样就可以了，比如是16核心的cpu 那么配置为16即可
如果是8核就配成8 以此类推
配置太高的话会到导致系统很卡 ，所以保持一致即可
Innodb_write_io_threshold
只允许一次prefech多个page到bp中 （0-64）
Innodb_random_read_ahead
Prefech到bp功能是否打开
考虑到一些顺序IO 和数据加载的问题
比如现在read io threshold
比如在一个用户系统中读取了一个用户的信息，那么会将这个page加载到dp中
那么可能需要说是否要将临近的page也加载进来，这里面有个问题 如果是用户系统 那么就在一个page中不需要加载临近的page 直接将其关掉，那么这个参数绝对是0 因为不需要额外的数据
但是如果是好友关系的话，数据读到这个用户 那么通过程序需要将其临近的用户也读取出来并加载那么可以将这个参数设置大一些 让其多读一些 比如3个
这个参数需要根据业务系统进行结合如果把我不住就不要管他