mysql优化之-系统优化

文章目录

• 一、内存
• 1.1 要确保有足够的内存
• 1.2 选择合适的内存分配算法
• 1.3 禁用Query Cache
• 1.4 使用Thread Pool
• 1.5 合理调整内存
• 1.5.1 减少连接的内存分配
• 1.5.2 使较大的buffer pool
• 1.6 合理选择LOG刷新机制
• 1.6.1 Redo Logs:
• 1.6.2 binlog :
• 1.7 请使用Innodb表
• 1.8 设置较大的Redo log
• 1.9 优化事务隔离级别
• 1.10 避免使用swap交换分区
• 二、cpu
• 2.1 需要更多更快的CPU
• 2.2 配置合理的并发
• 三、操作系统
• 3.1 要选择合适的操作系统
• 3.2 合理的优化系统的参数
• 3.3 选择适合的IO调度
• 3.4 其他
• 四、硬盘
• 4.1 使用更快的存储设备ssd或是固态卡
• 4.2 选择良好的文件系统
• 4.3 优化挂载文件系统的参数
• 4.4 选择合适的Raid卡Cache策略
• 4.5 优化磁盘的IO
• 4.6 使用独立表空间
• 4.7 其他
• 五、监控
• 5.1 注重监控

一、内存

1.1 要确保有足够的内存

数据库能够高效的运行，最关建的因素需要内存足更大了，能缓存住数据，更新也可以在内存先完成。但不同的业务对内存需要强度不一样，一推荐内存要占到数据的15-25%的比例，特别的热的数据，内存基本要达到数据库的80%大小。

拥有足够的物理内存来把整个InnoDB文件加载到内存中——在内存中访问文件时的速度要比在硬盘中访问时快的多。

1.2 选择合适的内存分配算法

默认的内存分配就是c的malloc 现在也出现许多优化的内存分配算法:

jemalloc and tcmalloc

从MySQL 5.5后支持声明内存储方法。

[mysqld_safe]
malloc-lib = tcmalloc

或是直接指到so文件

[mysqld_safe]
malloc-lib=/usr/local/lib/libtcmalloc_minimal.so

1.3 禁用Query Cache

Query Cache在Innodb中有点鸡肋，Innodb的数据本身可以在Innodb buffer pool中缓存，Query Cache属于结果集缓存，如果开启Query Cache更新写入都要去检查query cache反而增加了写入的开销。

在MySQL 5.6中Query cache是被禁掉了。

1.4 使用Thread Pool

现在一个数据对应5个以上App场景比较，但MySQL有个特性随着连接增多的情况下性能反而下降，所以对于连接超过200的以后场景请考虑使用thread pool. 这是一个伟大的发明。

1.5 合理调整内存

1.5.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 …
)

1.5.2 使较大的buffer pool

要把60-80%的内存分给innodb_buffer_pool_size. 这个不要超过数据大小了，另外也不要分配超过80%不然会利用到swap.

1.6 合理选择LOG刷新机制

1.6.1 Redo Logs:

• innodb_flush_log_at_trx_commit = 1 // 最安全
• innodb_flush_log_at_trx_commit = 2 // 较好性能
• innodb_flush_log_at_trx_commit = 0 // 最好的情能

1.6.2 binlog :

binlog_sync = 1 需要group commit支持，如果没这个功能可以考虑binlog_sync=0来获得较佳性能。

数据文件：

innodb_flush_method = O_DIRECT

1.7 请使用Innodb表

可以利用更多资源，在线alter操作有所提高。 目前也支持非中文的full text， 同时支持Memcache API访问。目前也是MySQL最优秀的一个引擎。

如果你还在MyISAM请考虑快速转换。

1.8 设置较大的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大于一小时的量即可。

1.9 优化事务隔离级别

默认是 Repeatable read

推荐使用Read committed binlog格式使用mixed或是Row

较低的隔离级别 = 较好的性能

1.10 避免使用swap交换分区

不惜一切代价避免使用Swap交换分区 – 交换时是从硬盘读取的，它的速度很慢。

二、cpu

2.1 需要更多更快的CPU

MySQL 5.6可以利用到64个核，而MySQL每个query只能运行在一个CPU上，所以要求更多的CPU，更快的CPU会更有利于并发。

使用64位的操作系统 – 对于MySQL，会有更大的内存支持和使用。

2.2 配置合理的并发

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

三、操作系统

3.1 要选择合适的操作系统

在官方建议估计最推荐的是Solaris, 从实际生产中看CentOS, REHL都是不错的选择，推荐使用CentOS, REHL 版本为6以后的，当然Oracle Linux也是一个不错的选择。虽然从MySQL 5.5后对Windows做了优化，但也不推荐在高并发环境中使用windows.

3.2 合理的优化系统的参数

更改文件句柄 ulimit -n 默认1024 太小

进程数限制 ulimit -u 不同版本不一样

禁掉NUMA numctl -interleave=all

3.3 选择适合的IO调度

正常请下请使用deadline 默认是noop。在 Linux 系统中, 使用 NOOP 或者 DEADLINE IO 定时调度程序 – 同 NOOP 和 DEADLINE定时调度程序相比，这个 CFQ 和 ANTICIPATORY 定时调度程序 显得非常慢。

echo dealine >/sys/block/{DEV-NAME}/queue/scheduler

3.4 其他

1. 删除服务器上未使用的安装包和守护进程 – 更少的资源占用。
2. 把使用MySQL的host和你的MySQL host放到一个hosts文件中 – 没有DNS查找。
3. 切勿强制杀死一个MySQL进程 – 你会损坏数据库和正在运行备份的程序。
4. 把服务器贡献给MySQL – 后台进程和其他服务能够缩短数据库占用CPU的时间。

四、硬盘

4.1 使用更快的存储设备ssd或是固态卡

存储介质十分影响MySQL的随机读取，写入更新速度。新一代存储设备固态ssd及固态卡的出现也让MySQL 大放异彩，也是淘宝在去IOE中干出了一个漂亮仗。

4.2 选择良好的文件系统

推荐 XFS、Ext4,如果还在使用 ext2、ext3 的同学请尽快升级别。 文件系统强烈推荐 XFS，这个也是今后一段时间Linux会支持一个文件系统。

4.3 优化挂载文件系统的参数

挂载XFS参数：(rw, noatime,nodiratime,nobarrier)

挂载ext4参数：ext4 (rw,noatime,nodiratime,nobarrier,data=ordered)

如果使用SSD或是固态盘需要考虑：

innodb_page_size = 4K
Innodb_flush_neighbors = 0

4.4 选择合适的Raid卡Cache策略

请使用带电的Raid，启用WriteBack， 对于加速redo log ,binary log, data file都有好处。

4.5 优化磁盘的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)

4.6 使用独立表空间

目前来看新的特性都是独立表空间支持:

• truncate table 表空间回收
• 表空间传输
• 较好的去优化碎片等管理性能的增加
• 整体上来看使用独立表空间是没用的

4.7 其他

1. 使用电池供电的RAM（注：RAM即随机存储器）。
2. 使用高级的RAID（注：Redundant Arrays of Inexpensive Disks，即磁盘阵列） – 最好是RAID10或更高。
3. 避免RAID5（注：一种存储性能、数据安全和存储成本兼顾的存储解决方案） – 确保数据库完整性的校验是要付出代价的。
4. 将操作系统和数据分区分开，不仅仅是逻辑上，还包括物理上 – 操作系统的读写操作会影响数据库的性能。
5. 把MySQL临时空间和复制日志与数据放到不同的分区 – 当数据库后台从磁盘进行读写操作时会影响数据库的性能。
6. 更多的磁盘空间等于更快的速度。
7. 更好更快的磁盘。
8. 使用SAS（注： Serial Attached SCSI，即串行连接SCSI）代替SATA（注：SATA，即串口硬盘）。
9. 较小的硬盘 比 较大的硬盘快，尤其是在RAID配置的情况下。
10. 使用电池支持的高速缓存RAID控制器。
11. 避免使用软件磁盘阵列。
12. 考虑为数据分区使用固态IO卡 (不是磁盘驱动器) – 这些卡能够为几乎任何数量的数据支持2GB/s的写入速度。
13. 在Linux中设置swappiness的值为0 – 在数据库服务器中没有理由缓存文件，这是一个服务器或台式机的优势。
14. 如果可以的话，使用 noatime 和 nodirtime 挂载文件系统 – 没有理由更新访问数据库文件的修改时间。
15. 使用 XFS 文件系统 – 一种比ext3更快、更小的文件系统，并且有许多日志选项， 而且ext3 已被证实与MySQL有双缓冲问题。
16. 调整 XFS 文件系统日志和缓冲变量 – 为了最高性能标准。

五、监控

5.1 注重监控

任环境离不开监控，如果少了监控，有可能就会陷入盲人摸象。 推荐zabbix+mpm构建监控。