MySQL优化---DBA对MySQL优化的一些总结
http://blog.163.com/li_hx/blog/static/183991413201572522214601/
1. 要确保有足够的内存
数据库能够高效的运行，最关建的因素需要内存足更大了，能缓存住数据，更新也可以在内存先完成。但不同的业务对内存需要强度不一样，一推荐内存要占到数据的15-25%的比例，特别的热的数据，内存基本要达到数据库的80%大小。
2. 需要更多更快的CPU
MySQL 5.6可以利用到64个核，而MySQL每个query只能运行在一个CPU上，所以要求更多的CPU，更快的CPU会更有利于并发。
3. 要选择合适的操作系统
在官方建议估计最推荐的是Solaris, 从实际生产中看CentOS, REHL都是不错的选择，推荐使用CentOS, REHL 版本为6以后的，当然Oracle Linux也是一个不错的选择。虽然从MySQL 5.5后对Windows做了优化，但也不推荐在高并发环境中使用windows.
4. 合理的优化系统的参数
更改文件句柄 ulimit –n 默认1024 太小
进程数限制 ulimit –u 不同版本不一样
禁掉NUMA numactl --interleave=all mysqld & 启动mysql时候关闭numa特性
5. 选择合适的内存分配算法
默认的内存分配就是c的malloc 现在也出现许多优化的内存分配算法:
jemalloc and tcmalloc
从MySQL 5.5后支持声明内存分配方法。
[mysqld_safe]
malloc-lib = tcmalloc
优化内存碎片率是世界性难题，tcmalloc/jemalloc 都不能做到完美，可能要优化确实很困难）。
https://mongoing.com/archives/34751
或是直接指到so文件
[mysqld_safe]
malloc-lib=/usr/local/lib/libtcmalloc_minimal.so
6. 使用更快的存储设备ssd或是固态卡
存储介质十分影响MySQL的随机读取，写入更新速度。新一代存储设备固态ssd及固态卡的出现也让MySQL 大放异彩，也是淘宝在去IOE中干出了一个漂亮仗。
7. 选择良好的文件系统
推荐XFS, Ext4,如果还在使用ext2,ext3的同学请尽快升级。 推荐XFS，这个也是今后一段时间Linux会支持一个文件系统。
文件系统强烈推荐: XFS
8. 优化挂载文件系统的参数
挂载XFS参数：
(rw, noatime,nodiratime,nobarrier)
挂载ext4参数：
ext4 (rw,noatime,nodiratime,nobarrier,data=ordered)
如果使用SSD或是固态盘需要考虑：
? innodb_page_size = 4K
? Innodb_flush_neighbors = 0
9. 选择适合的IO调度
正常请下请使用deadline 或者noop
echo dealine >/sys/block/{DEV-NAME}/queue/scheduler
10. 选择合适的Raid卡Cache策略
请使用带电的Raid，启用WriteBack， 对于加速redo log ,binary log, data file都有好处。
11. 禁用Query Cache
QueryCache在Innodb中有点鸡肋，Innodb的数据本身可以在Innodb buffer pool中缓存，Query Cache属于结果集缓存，如果开启Query Cache更新写入都要去检查query cache反而增加了写入的开销。
在MySQL5.6中Querycache是被禁掉了。
12. 使用Thread Pool
现在一个数据对应5个以上App场景比较，但MySQL有个特性随着连接增多的情况下性能反而下降，所以对于连接超过200的以后场景请考虑使用thread pool. 这是一个伟大的发明。
13. 合理调整内存
13.1 减少连接的内存分配
连接可以用thread_cache_size缓存，观查属于比较属不如thread pool给力。数据库在连上分配的内存如下：
max_used_connections * (
read_buffer_size +
read_rnd_buffer_size +
join_buffer_size +
sort_buffer_size +
binlog_cache_size +
thread_stack +
2 * net_buffer_length …
)
13.2 使较大的buffer pool
要把60-80%的内存分给innodb_buffer_pool_size. 这个不要超过数据大小了，另外也不要分配超过80%不然会利用到swap.
14. 合理选择LOG刷新机制
Redo Logs:
– innodb_flush_log_at_trx_commit = 1 // 最安全 最差性能 每次提交事务都fsync到磁盘
– innodb_flush_log_at_trx_commit = 2 // 较好性能 每次提交事务都写入到文件系统缓存，但不fsync到磁盘
– innodb_flush_log_at_trx_commit = 0 // 最好的性能 master 线程每隔1秒进行一次redo log的fsync动作
binlog :
binlog_sync = 1 需要group commit支持，如果没这个功能可以考虑binlog_sync=0来获得较佳性能。
数据文件：
innodb_flush_method = O_DIRECT （O_DIRECT 不经过/写入文件系统缓存，直接写入磁盘）
15. 请使用Innodb表
可以利用更多资源，在线alter操作有所提高。 目前也支持非中文的full text， 同时支持Memcache API访问。目前也是MySQL最优秀的一个引擎。
如果你还在MyISAM请考虑快速转换。
16. 设置较大的Redo log
以前Percona 5.5和官方MySQL 5.5比拼性能时，胜出的一个Tips就是分配了超过4G的Redo log ,而官方MySQL5.5 redo log不能超过4G. 从 MySQL 5.6后可以超过4G了，通常建Redo log加起来要超过500M。 可以通过观查redo log产生量，分配Redo log大于一小时的量即可。
17. 优化磁盘的IO
innodb_io_capactiy 在sas 15000转的下配置800就可以了，在ssd下面配置2000以上。
在MySQL 5.6:
innodb_lru_scan_depth = innodb_io_capacity / innodb_buffer_pool_instances
innodb_io_capacity_max = min(2000, 2 * innodb_io_capacity)
18. 使用独立表空间
目前来看新的特性都是独立表空间支持:
truncate table 表空间回收
表空间传输
19. 配置合理的并发
innodb_thread_concurrency =并发这个参数在Innodb中变化也是最频繁的一个参数。不同的版本，有可能不同的小版本也有变动。一般推荐：
在使用thread pool 的情况下：
innodb_thread_concurrency = 0 就可以了。
如果在没有thread pool的情况下：
5.5 推荐：innodb_thread_concurrency =16 – 32
5.6 推荐innodb_thread_concurrency = 36
20. 优化事务隔离级别
默认是 Repeatable read
推荐使用Read committed binlog格式使用Row
较低的隔离级别 = 较好的性能
21. 注重监控
任环境离不开监控，如果少了监控，有可能就会陷入盲人摸象。 推荐zabbix+mpm构建监控。
内存分配器：glibc，tcmalloc，jemalloc
redis开发与运维 P203
内存分配器为了更好地管理和重复利用内存，分配内存策略一般采用固定范围的内存块进行分配，例如jemalloc在64位系统中
将内存空间划分为：小，大，巨大三个范围，每个范围内又划分为多个小的内存块单位，如下所示
小：8byte，16byte，32byte，48byte。。。128byte，192byte，256byte，512byte，768byte，1024byte，3840byte
大：4kb，8kb，12kb，4072kb
巨大：4mb，8mb，12mb
比如当保存5kb对象时jemalloc可能会采用8kb的块存储，而剩下的3kb空间变为内存碎片不能再分配给其他对象存储。
内存碎片问题虽然是所有内存服务的通病，但是jemalloc针对碎片问题专门做了优化，一般不会存在过度碎片的问题，正常的碎片率
在1.03左右mem_fragmentation_ratio，但是当存储的数据长短差异较大时，以下场景容易出现高内存碎片问题：
1、频繁做更新操作，例如频繁对已存在的键执行append，setrange等更新操作
2、大量过期键删除，键对象过期删除后，释放的空间无法得到充分利用，导致碎片率上升
碎片问题常见解决方法：
1、数据对齐：在条件允许情况下尽量做数据对齐，比如数据尽量用数字类型或固定长度字符串等
2、安全重启：重启redis可以做到内存碎片重新整理，可以利用高可用架构，sentinel或cluster，切换主从，安全重启