mysql的从头到脚优化之服务器参数的调优
一. 说到mysql的调优,有许多的点可以让我们去做,因此梳理下,一些调优的策略,今天只是总结下服务器参数的调优
其实说到,参数的调优,我的理解就是无非两点:
- 如果是Innodb的数据库,innodb_buffer_pool_size就开的尽可能大点,我一般都是开内存的80%左右
- 如果是MyISAM的数据库,key_buffer_size就尽可能的开的大点。
我觉得这是非常重要的两个参数,下面是重点介绍下,这两个参数的作用:
innodb_buffer_pool_size:
该参数是用来缓存数据索引以及数据块的数据,简单的来说,当我们操作Innodb数据库获取数据的时候,都会在这个内存的区域块中走一遭,获取数据.
Innodb_buffer_pool_size 设置了Innodb存储引擎的内存区域块的大小,直接关系到Innodb的存储引擎性能,因此我们如果有足够大的内存,应该将尽可能多的内存设置,
从而将尽可能多的数据以及索引发到该内存数据块中.
我们可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率,并根据命中率
来调整 innodb_buffer_pool_size 参数大小进行优化
key_buffer_size:
该参数是用来缓存数据的索引的,并不缓存数据块,也就是说,我们应该尽可能多的将SQL的过滤条件都在索引中,从而提高缓存的命中率。
这个参数,也是直接关系到MyIsam的性能的,因此,我们也应该将尽可能多的内存分配给这个参数。以便尽可能高的提高性能。
下面的参数是MySQL的一些常用的参数,可以参考下:
query_cache_size/query_cache_type:
Query cache 作用于整个 MySQL Instance,主要用来缓存 MySQL 中的 ResultSet,也就是一条SQL语句执行的结果集,所以仅仅只能针对select语句。当我们打开了
Query Cache 功能,MySQL在接受到一条select语句的请求后,如果该语句满足Query Cache的要求(未显式说明不允许使用Query Cache,或者已经显式申明需要使用Query
Cache),MySQL 会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash,然后到Query Cache 中直接查找是否已经缓存。也就是说,如果已经在缓
存中,该select请求就会直接将数据返回,从而省略了后面所有的步骤(如 SQL语句的解析,优化器优化以及向存储引擎请求数据等),极大的提高性能。
当然,Query Cache 也有一个致命的缺陷,那就是当某个表的数据有任何任何变化,都会导致所有引用了该表的select语句在Query Cache 中的缓存数据失效。所以,当
我们的数据变化非常频繁的情况下,使用Query Cache 可能会得不偿失。
Query Cache的使用需要多个参数配合,其中最为关键的是 query_cache_size 和 query_cache_type ,前者设置用于缓存 ResultSet 的内存大小,后者设置在何场景
下使用Query Cache。在以往的经验来看,如果不是用来缓存基本不变的数据的MySQL数据库,query_cache_size 一般 256MB 是一个比较合适的大小。当然,这可以通过计算
Query Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))来进行调整。query_cache_type可以设置为0(OFF),1(ON)或者2(DEMOND),分别表示完
全不使用query cache,除显式要求不使用query cache(使用sql_no_cache)之外的所有的select都使用query cache,只有显示要求才使用querycache(sql_cache)。
binlog_cache_size (global)
Binlog Cache 用于在打开了二进制日志(binlog)记录功能的环境,是 MySQL 用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。
一般来说,如果我们的数据库中没有什么大事务,写入也不是特别频繁,2MB~4MB是一个合适的选择。但是如果我们的数据库大事务较多,写入量比较大,可与适当调高
binlog_cache_size。同时,我们可以通过binlog_cache_use 以及 binlog_cache_disk_use来分析设置的binlog_cache_size是否足够,是否有大量的binlog_cache由于内存
大小不够而使用临时文件(binlog_cache_disk_use)来缓存了
innodb_additional_mem_pool_size(global)
这个参数我们平时调整的可能不是太多,很多人都使用了默认值,可能很多人都不是太熟悉这个参数的作用。innodb_additional_mem_pool_size 设置了InnoDB存储
引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小,所以当我们一个MySQL Instance中的数据库对象非常多的时候,是需要适当调整该参数的大小以确保所有数据
都能存放在内存中提高访问效率的。
这个参数大小是否足够还是比较容易知道的,因为当过小的时候,MySQL 会记录 Warning 信息到数据库的 error log 中,这时候你就知道该调整这个参数大小了。
innodb_log_buffer_size (global)
这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer,InnoDB 在写事务日志的时候,为了提高性能,也是先将信息写入 Innofb Log Buffer 中,
当满足 innodb_flush_log_trx_commit 参数所设置的相应条件(或者日志缓冲区写满)之后,才会将日志写到文件(或者同步到磁盘)中。可以通过 innodb_log_buffer_size
参数设置其可以使用的最大内存空间。
注:innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0,1,2,解释如下:
0:log buffer中的数据将以每秒一次的频率写入到log file中,且同时会进行文件系统到磁盘的同步操作,但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者
文件系统到磁盘的刷新操作;
1:在每次事务提交的时候将log buffer 中的数据都会写入到log file,同时也会触发文件系统到磁盘的同步;
2:事务提交会触发log buffer 到log file的刷新,但并不会触发磁盘文件系统到磁盘的同步。此外,每秒会有一次文件系统到磁盘同步操作。
此外,MySQL文档中还提到,这几种设置中的每秒同步一次的机制,可能并不会完全确保非常准确的每秒就一定会发生同步,还取决于进程调度的问题。实际上,InnoDB 能否真
正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制,可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经
完成了磁盘同步。
下面是转载的一些常用参数的设置:
- query_cache_type : 如果全部使用innodb存储引擎,建议为0,如果使用MyISAM 存储引擎,建议为2,同时在SQL语句中显式控制是否使用gquery cache
- query_cache_size: 根据 命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))进行调整,一般不建议太大,256MB可能已经差不多了,大型的配置型静态数据可适当调大
- binlog_cache_size: 一般环境2MB~4MB是一个合适的选择,事务较大且写入频繁的数据库环境可以适当调大,但不建议超过32MB
- key_buffer_size: 如果不使用MyISAM存储引擎,16MB足以,用来缓存一些系统表信息等。如果使用 MyISAM存储引擎,在内存允许的情况下,尽可能将所有索引放入内存,简单来说就是“越大越好”
- bulk_insert_buffer_size: 如果经常性的需要使用批量插入的特殊语句(上面有说明)来插入数据,可以适当调大该参数至16MB~32MB,不建议继续增大,某人8MB
- innodb_buffer_pool_size: 如果不使用InnoDB存储引擎,可以不用调整这个参数,如果需要使用,在内存允许的情况下,尽可能将所有的InnoDB数据文件存放如内存中,同样将但来说也是“越大越好”
- innodb_additional_mem_pool_size: 一般的数据库建议调整到8MB~16MB,如果表特别多,可以调整到32MB,可以根据error log中的信息判断是否需要增大
- innodb_log_buffer_size: 默认是1MB,系的如频繁的系统可适当增大至4MB~8MB。当然如上面介绍所说,这个参数实际上还和另外的flush参数相关。一般来说不建议超过32MB
- innodb_max_dirty_pages_pct: 根据以往的经验,重启恢复的数据如果要超过1GB的话,启动速度会比较慢,几乎难以接受,所以建议不大于 1GB/innodb_buffer_pool_size(GB)*100 这个值。当然,如果你能够忍受启动时间比较长,而且希望尽量减少内存至磁盘的flush,可以将这个值调整到90,但不建议超过90
转载于:https://www.cnblogs.com/shangzekai/p/4381641.html
mysql的从头到脚优化之服务器参数的调优相关推荐
- 性能优化专题 - JVM 性能优化 - 04 - GC算法与调优
目录导航 前言 Garbage Collect(垃圾回收) 如何确定一个对象是垃圾? 引用计数法 可达性分析 垃圾收集算法 标记-清除(Mark-Sweep) 复制(Copying) 标记-整理(Ma ...
- Java性能优化,操作系统内核性能调优,JYM优化,Tomcat调优
文章目录 Java性能优化 尽量在合适的场合使用单例 尽量避免随意使用静态变量 尽量避免过多过常地创建Java对象 尽量使用final修饰符 尽量使用局部变量 尽量处理好包装类型和基本类型两者的使用场 ...
- Linux数据库服务器的性能调优
Linux数据库服务器的性能调优 数据库服务器需要耗用大量系统资源,服务器性能高度依赖于内核管理这些资源的有效程度.这方面的低效率会导致在内核空间中耗费过多时间.另外,某些特定的低效情况会导致锁冲突, ...
- MySQL的常见存储引擎介绍与参数设置调优
MySQL常用存储引擎之MyISAM 特性:1.并发性与锁级别2.表损坏修复check table tablenamerepair table tablename3.MyISAM表支持的索引类型①.全 ...
- MySQL的常见存储引擎介绍与参数设置调优(转载)
原文地址:http://www.cnblogs.com/demon89/p/8490229.html MySQL常用存储引擎之MyISAM 特性:1.并发性与锁级别2.表损坏修复check table ...
- sql优化的方法及思路_合理的sql优化思路--如何缩短SQL调优时间?
概述 当生产环境发生故障或者系统特别慢的时候,这时候你从awr报告拿到有问题的sql,但是优化的时候却优化了很久还没解决,这时候在领导或者客户面前就不太好了...那么我们怎么去缩短sql调优的时间,一 ...
- Android性能优化(31)---虚拟机调优
Android性能优化之虚拟机调优 众所周知,我们的Android App运行在Java虚拟机之上,而Java是一门带GC的语言.在虚拟机进行垃圾回收的时候,要做一件很形象的事叫做STW(stop t ...
- Flink优化02--状态及Checkpoint调优
一.状态简述 Flink的状态分为三种: MemoryStateBackend:默认的方式,即基于JVM的堆内存进行存储,主要适用于本地开发和调试: FsStateBackend:基于文件系统进行存储 ...
- 【MySQL】数据库服务器硬件优化与实战详解(调优篇)(实战篇)(MySQL专栏启动)
最新文章
- L1-044 稳赢 (暴力法)
- python数字字符是什么_大佬们,想问一下Python中特殊字符的代码是什么啊,只知道数字是digits...
- 【Java】 获取当前项目所有的线程
- 如何在Android Studio里关掉instant run
- SQL Server死锁诊断--同一行数据在不同索引操作下引起的死锁
- 支持商用吗_可商用的插画素材 | 美翻了
- python3.6.8安装失败_centos7编译安装Python 3.6.8 后用pip3出现SSL未配置问题(import ssl失败)解决方法...
- Nginx之配置后端服务器组
- MySQL集群之五大常见的MySQL高可用方案(转)
- Java基础知识强化54:经典排序之插入排序(InsertSort)
- 【No.11 默认实参的匹配】
- Fluent批处理及.jou和.scm文件编写的相关操作
- lcd驱动芯片测试软件,LCD Driver IC测试方法及其挑战
- linux 向日葵教程,远程控制工具——Centos7上向日葵安装使用(转)
- 2022-2028年全球与中国手持式按摩器行业市场深度调研及投资预测分析
- ***HDU 3237 - Help Bubu(状压DP)
- 证券交易所--本方最优对手方最优的区别
- 实践▍用大数据扒一扒蔡徐坤的真假流量粉 | Alfred数据室
- 记录一下nginx代理引起的ip失真问题
- AG9311/AG9310 Type-C转HDMI设计方案|替代AG9310/AG9311芯片|GSV2201可完全替代兼容AG9310/AG9311