MySQL优化要点
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL优化要点相关的知识,希望对你有一定的参考价值。
mysql优化要点
硬件选型优化
CPU
主频高,支持多线程
1.2、 磁盘
SAS磁盘(RAID10)或SSD磁盘(RAID1)
1.3、 主板
修改主板配置参数,打开磁盘写缓存,关闭磁盘读缓存,以免影响数据插入速度;尽量使用独立RAID,不用主板集成RAID卡
1.4、 网卡
主机多网卡BOND绑定,保证网络无故障;配备千兆速率以上网卡设备。
1.5、 内存
配备多通道高频内存,容量至少16G以上,最好是数据库数据内存两倍。
部署以及配置参数优化
部署规范
统一软件部署存放路径、编译参数等;数据库数据文件存放路径名称统一规范。
2.2、 数据存储
每个实例需要单独磁盘分区或使用LVM分区亦可。
2.3、 存储引擎
MySQL常用的存储引擎主要有MyISAM和InnoDB
2.3.1MyISAM
不是事务安全的,也不支持外键。如果事物回滚将造成不完全回滚,不具有原子性。如果执行大量的SELECT,MyISAM是更好的选择。MyISAM的索引和数据是分开的,并且索引是有压缩的,内存使用率就对应提高了不少。能加载更多索引。表格可以被压缩,而且它们支持全文搜索。读性能较强。整表锁。对于select count(*) from table 的操作,MyISAM有单独保存表行数,不需读表,可以直接读取。
2.3.2InnoDB
事务安全的、支持外键。你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑,应该使用InnoDB表。Innodb是索引和数据是紧密捆绑的,没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。写性能较强。行级锁。不保存表的具体行数,所以selectcount(*) from table 是全表扫描。但是当count(*)语句包含 where条件时与MyISAM没有区别。
2.4、 配置参数优化
4.1 max_connections
建议值: 3000
说明:MySQL允许最大的进程连接数,如果经常出现Too Many Connections的错误提示,则需要增大此值。
4.2 skip-external-locking
说明:跳过外部锁定; 外部锁定(external-locking)起作用时,每个进程若要访问数据表,则必须等待之前的进程完成操作并解除锁定。由于服务器访问数据表时经常需要等待解锁,因此在单服务器环境下external locking会让MySQL性能下降。所以在很多Linux发行版的源中,MySQL配置文件中默认使用了skip-external-locking来避免external locking。
如果是多服务器环境,希望打开external locking特征,则注释掉这一行即可
#skip-external-locking
如果是单服务器环境,则将其禁用即可,使用如下语句
skip-external-locking
4.3 skip-name-resolve
说明:skip-name-resolve是禁用dns解析,启用后,在mysql的授权表中就不能使用主机名,只能使用IP;如果你有一个很慢的DNS和许多主机,你可以通过用--skip-name-resolve禁用DNS查找或增加HOST_CACHE_SIZE定义(默认值:128)并重新编译mysqld来提高性能。
4.4 max_allowed_packet
建议值:32M
说明:设置在网络传输中一次消息传输量的最大值。系统默认值 为1MB,最大值是1GB,必须设置1024的倍数。
4.5 wait_timeout
建议值:28800
说明:结束回话等待时间
4.6 thread_cache_size
建议值: 64
说明:服务器线程缓存这个值表示可以重新利用保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中,如果线程重新被请求,那么请求将从缓存中读取,如果缓存中是空的或者是新的请求,那么这个线程将被重新创建,如果有很多新的线程,增加这个值可以改善系统性能.通过比较Connections 和Threads_created状态的变量,可以看到这个变量的作用。设置规则如下:1GB 内存配置为8,2GB配置为16,3GB配置为32,4GB或更高内存,可配置更大。
4.7 explicit_defaults_for_timestamp
建议值:true
说明:明确的默认timestamp行为属性;即开启此参数,默认不会为timestamp列强制非NULL,或设置默认当前timestamp属性。
4.8 query_cache_limit
建议值: 4M
说明:指定单个查询能够使用的缓冲区大小,缺省为1M。
4.9 query_cache_min_res_unit
建议值:2k
说明:默认是4KB,设置值大对大数据查询有好处,但如果你的查询都是小数据查询,就容易造成内存碎片和浪费。
查询缓存碎片率 =Qcache_free_blocks / Qcache_total_blocks * 100%;如果查询缓存碎片率超过20%,可以用FLUSHQUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit,如果你的查询都是小数据量的话。
查询缓存利用率 =(query_cache_size–Qcache_free_memory) / query_cache_size * 100%;查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes>50的话说明query_cache_size可能有点小,要不就是碎片太多。
查询缓存命中率=(Qcache_hits–Qcache_inserts) / Qcache_hits * 100%。
4.10 tmp_table_size
建议值:128M
说明:tmp_table_size的默认大小是 32M。如果一张临时表超出该大小,MySQL产生一个 The table tbl_name is full 形式的错误,如果你做很多高级 GROUPBY查询,增加tmp_table_size值。如果超过该值,则会将临时表写入磁盘。
4.11 thread_concurrency
建议值:32
说明:设置thread_concurrency的值的正确与否,对mysql的性能影响很大,在多个cpu(或多核)的情况下,错误设置了thread_concurrency的值,会导致mysql不能 充分利用多cpu(或多核),出现同一时刻只能一个cpu(或核)在工作的情况。 thread_concurrency应设为CPU核数的2倍比如有一个双核的CPU,那么thread_concurrency的应该为4;2个双核的cpu,thread_concurrency的值应为8。
4.12 open_files_limit
建议值:10240
说明:每个客户端的连接也是一个文件句柄。
4.13 back_log
建议值:2048
说明:在MYSQL暂时停止响应新请求之前,短时间内的多少个请求可以被存在堆栈中。如果系统在短时间内有很多连接,则需要增大该参数的值,该参数值指定到来的TCP/IP连接的监听队列的大小。
4.14 innodb_flush_log_at_trx_commit
建议值:1
说明:每多少次commit 日志缓存中的数据刷到磁盘中。为了提高事务安全性,我们建议没提交一次就刷新缓存到磁盘,但这会大量消耗IO,需要在实际运用中去均衡考虑这个参数设置。
4.15 innodb_lock_wait_timeout
建议值:50
说明:InnoDB事务在被回滚之前可以等待一个锁定的超时秒数;InnoDB在它自己的锁定表中自动检测事务死锁并且回滚事务;InnoDB用LOCKTABLES语句注意到锁定设置。默认值是50秒。
4.16 innodb_auto_extend_increment
建议值:64M
说明:Innodb存储引擎表,每次自动扩展空间分配区的大小,加大此值可帮助降低碎片,但可能造成空间浪费。
4.17 innodb_buffer_pool_size
建议值:8192M
说明:这对Innodb表来说非常重要。Innodb相比MyISAM表对缓冲更为敏感。MyISAM可以在默认的key_buffer_size设置下运行的可以,然而Innodb在默认的innodb_buffer_pool_size设置下却跟蜗牛似的。由于Innodb把数据和索引都缓存起来,无需留给操作系统太多的内存,因此如果只需要用Innodb的话则可以设置它高达70-80%的可用内存。一些应用于key_buffer的规则有—如果你的数据量不大,并且不会暴增,那么无需把innodb_buffer_pool_size设置的太大了。
4.18 innodb_log_buffer_size
建议值:16M
说明:此参数确定些日志文件所用的内存大小,以M为单位。缓冲区更大能提高性能,但意外的故障将会丢失数据。
4.19 innodb_buffer_pool_instances
建议值:8
说明:用于优化更高并发的负载。
4.20 innodb_log_file_size
建议值:60M
说明:此参数确定数据日志文件的大小,以M为单位,更大的设置可以提高性能,但也会增加恢复故障数据库所需的时间。
4.21 innodb_log_files_in_group
建议值:3M
说明:为提高性能,MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3M。
4.22 innodb_io_capacity
建议值:400
说明:InnoDB曾经在代码里写死了假设服务器运行在每秒100个I/O操作的单硬盘上。默认值很糟糕。现在可以告诉InnoDB服务器有多大的I/O能力。有时需要把这个值设置得相当高(像SSD这样极快的存储设备上需要设置为上万)才能稳定地刷新脏页。
4.23 innodb_write_io_threads
建议值:4
说明:文件IO的线程数,一般为 4,但是在 Windows 下,可以设置得较大。
4.24 innodb_read_io_threads
建议值:4
说明:文件IO的线程数,一般为 4,但是在 Windows 下,可以设置得较大。
4.25 innodb_thread_concurrency
建议值:8
说明:服务器有几个CPU就设置为几,建议用默认设置,一般为8
4.26 innodb_file_per_table
建议值:ON
说明:其默认值在mysql5.6.6+后为ON。开启此选项后,关于InnoDB表的数据和索引单独存储在自己的表空间中(.ibd结尾的文件)。否则,存储在系统的表空间中(ibdata)。
4.27 innodb_print_all_deadlocks
建议值:1
说明:死锁信息打印到错误日志里。
4.28 innodb_buffer_pool_dump_at_shutdown
建议值:1
说明:在关闭时把热数据dump到本地磁盘。
4.29 innodb_buffer_pool_dump_now
建议值:1
说明:采用手工方式把热数据dump到本地磁盘。
4.30 innodb_buffer_pool_load_at_startup
建议值:1
说明:在启动时把热数据加载到内存。
4.31 innodb_buffer_pool_load_now
建议值:1
说明:采用手工方式把热数据加载到内存。
4.32 table_open_cache
建议值:4096
说明:从官方文档看出在MySQL5.6.8+开始默认值为2000,就能简单的判断出原来默认值是不够的。可以通过观察Opened_tables其值及其一段时间的变化来检查该变量。如果看到Opened_tables的值很大并且又不经常执行FLUSH TABLES (执行其命令强制所有的表重新关闭且打开),那么可能你应该增加该变量的值。
4.33 max_connect_errors
建议值:1000
说明:设置每个主机的连接请求异常中断的最大次数,当超过该次数,MYSQL服务器将禁止host的连接请求,直到mysql服务器重启或通过flushhosts命令清空此host的相关信息。
4.34 expire_logs_days
建议值:7
说明:如果启用了二进制日志,应该打开这个选项,可以让服务器在指定的天数之后清理旧的二进制日志。如果不启用,最终服务器的空间会被耗尽,导致服务器卡住或崩溃。
4.35 sort_buffer_size
建议值:1M
说明:Sort_Buffer_Size是一个connection级参数,在每个connection(session)第一次需要使用这个buffer的时候,一次性分配设置的内存。Sort_Buffer_Size并不 是越大越好,由于是connection级的参数,过大的设置+高并发可能会耗尽系统内存资源。例如:500个连接将会消耗500*sort_buffer_size(8M)=4G内存,Sort_Buffer_Size超过2KB的时候,就会使用mmap()而不是malloc() 来进行内存分配,导致效率降低。
4.36 join_buffer_size
建议值:8M
说明:用于表间关联缓存的大小,和sort_buffer_size一样,该参数对应的分配内存也是每个连接独享。
4.37 read_buffer_size
建议值:1M
说明:MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySql会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁,并且你认为频繁扫描进行得太慢,可以通过增加该变量值以及内存缓冲区大小提高其性能。和sort_buffer_size一样,该参数对应的分配内存也是每个连接独享。
4.38 read_rnd_buffer_size
建议值:16M
说明:MySql的随机读(查询操作)缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySql会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySql会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大。
4.39 myisam_sort_buffer_size
建议值:256M
说明:MyISAM表发生变化时重新排序所需的缓冲。
4.40 bulk_insert_buffer_size
建议值:64M
说明:批量插入数据缓存大小,可以有效提高插入效率,默认为8M。
4.41 key_buffer_size
建议值:1024M
说明:批定用于索引的缓冲区大小,增加它可以得到更好的索引处理性能,对于内存在4GB左右的服务器来说,该参数可设置为256MB或384MB。
4.42 myisam_max_sort_file_size
建议值:10G
说明:MySQL重建索引时所允许的最大临时文件的大小 (当 REPAIR, ALTER TABLE或者 LOAD DATA INFILE)如果文件大小比此值更大,索引会通过键值缓冲创建(更慢)。
#-------------------mysql5.6的主从增加了不少参数,提升了主从同步的安全和效率,以下主从参数详解--------------------#
4.43 server-id
取值:1~n
说明:MySQL服务器标识号,在主从复制架构中用来唯一标识一个服务器,避免多向复制过程中出现混乱。
4.44 binlog-format
建议值:ROW
说明:Binlog记录方式,以前版本是仅支持statement(语句级别),这种模式,易造成跨库(模式)时,数据混乱问题;故后来在5.x版本呢引进ROW模式,这样就针对具体的行来记录,避免复制过程出现数据安全问题。
4.45 log-bin
建议值:master-bin.log
说明:Binlog文件名,建议以标识属于哪个主机或模块的名称,便于识别。
4.46 log-bin-index
建议值:master-bin.index
说明:记录log-bin文件名的索引,便于MySQL服务器复制进程检索,读取log-bin文件。
4.47 log-slave-updates
建议值:true
说明:指导主从复制架构中从服务器,是否要记录从主服务器传递来的数据变更;开启则,可用于多级复制架构;为了避免复制混乱,可通前面几个参数(server_id,log-bin,log-bin-index)结合,来唯一标识事务,并记录binlog,进行级联复制。
4.48 gtid-mode
建议值:on
说明:见2.4.48
4.49 enforce-gtid-consistency
建议值:true
说明:这两个参数是启用mysql5.6中的UUID同步模式,两个参数必须一起打开,否则报错,slave在做同步复制时,无须找到binlog日志和POS点,直接change master tomaster_auto_position=1即可,自动找点同步。
GTID的局限性:(鉴于这些局限性,慎用,因此做了关闭处理)
CREATE TABLE...SELECT语句不支持。因为该语句会被拆分成createtable和insert两个事务,并且这个两个事务被分配了同一个GTID,这会导致insert被 备库忽略掉。
不支持CREATETEMPORARY TABLE、DROP TEMPORARY TABLE 临时表操作。
4.50 master-info-repository
建议值:TABLE
说明:主复制服务器信息记录容器,放表里安全,便捷,效率高。
4.51 relay-log-info-repository
建议值:TABLE
说明:延迟log信息记录容器,放表里安全,便捷,效率高。
4.52 sync-master-info
建议值:1
说明:同步主服务器信息。
4.53 slave-parallel-workers
建议值:2
说明:默认是0,不开启,最大并发数为1024个线程。主从复制启用4个sql线程,提高从服务器吞吐量,减少延迟,使用并发的 SQL 线程对不同数据库并行应用事件。
4.54 binlog-checksum
建议值:CRC32
说明:Binlog文件校验算法。
4.55 master-verify-checksum
建议值:1
说明:主复制服务器验证。
4.56 slave-sql-verify-checksum
建议值:1
说明:从服务器验证。
4.57 binlog-rows-query-log-events
建议值:1
说明:这四个参数是启用binlog/relaylog的校验,防止日志出错。
4.58 sync_binlog
建议值:1
说明:默认情况下,并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃,有可能binlog中最后的语句丢失了。要想防止这种情况,你可以使用sync_binlog全局变量(1是最安全的值,但也是最慢的),使binlog在每N次binlog写入后与硬盘同步。即使sync_binlog设置为1,出现崩溃时,也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表,MySQL服务器处理COMMIT语句,它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃,重启时,事务被InnoDB回滚,但仍然存在binlog中。可以用--innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。(注释:在MySQL5.1中不需要--innodb-safe-binlog;由于引入了XA事务支持,该选项作废了),该选项可以提供更大程度的安全,使每个事务的binlog(sync_binlog=1)和(默认情况为真)InnoDB日志与硬盘同步,该选项的效果是崩溃后重启时,在滚回事务后,MySQL服务器从binlog剪切回滚的InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等,并使从服务器保持与主服务器保持同步(不接收回滚的语句)。
4.59 relay_log_purge
建议值:1
说明:见2.4.59
4.60 relay_log_recovery
建议值:1
说明:这两个是启用relaylog的自动修复功能,避免由于网络之类的外因造成日志损坏,主从停止。
4.61 slave-skip-errors
建议值:1062
说明:从复制服务器可跳过多少错误,而不造成复制中断,有利有弊,跳过可能造成主从数据不一致。
以上是关于MySQL优化要点的主要内容,如果未能解决你的问题,请参考以下文章