Mysql数据库之优化系列
1.独白
对于一个网站来说,在运行很长一段时间后,数据库瓶颈问题会越来越暴露出来。作为运维人员,对数据库做必要的优化十分重要!
下面总结以往查阅到的以及自己工作中的一些优化操作经验,并根据OSI七层模型从下往上进行优化MySQL数据库记录。
2.服务器物理硬件的优化
1、cpu:2-16个 2*4双四核,L1L2越大越好 2、内存:越大越好 3、磁盘:SAS或者固态 300G*12磁盘越多IO越高 raid 0>10>5>1 4、网卡:千兆 5、slave的配置最好大于等于master
3.系统配置
##如下,配置系统内核参数/etc/sysctl.conf(配置后,使用sysctl -p使之生效) net.ipv4.tcp_fin_timeout = 2 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_keepalive_time =600 net.ipv4.ip_local_port_range = 4000 65000 net.ipv4.tcp_max_syn_backlog = 16384 net.ipv4.tcp_max_tw_buckets = 36000 net.ipv4.route.gc_timeout = 100 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_synack_retries = 1 net.core.somaxconn = 16384 net.core.netdev_max_backlog = 16384 net.ipv4.tcp_max_orphans = 16384 vm.swappiness=0 ##//尽量不使用swap vm.dirty_backgroud_ratio 5-10 vm.dirty_ratio ##//上面的值的两倍 将操作系统的脏数据刷到磁盘
4.MySQL的安装
MySQL数据库的线上环境安装,建议采取编译安装的方式,这样性能会有较大的提升。服务器系统则建议CentOS6.7 X86_64,源码包的编译参数会默认以Debug模式生成二进制代码,而Debug模式给MySQL带来的性能损失是比较大的,所以当我们编译准备安装的产品代码时,一定不要忘记使用–without-debug参数禁止Debug模式。如果把–with-mysqld-ldflags和–with-client-ld-flags两个编译参数设置为–all-static的话,可以告诉编译器以静态的方式编译,编译结果将得到最高的性能。使用静态编译和使用动态编译的代码相比,性能差距可能会达到5%至10%之多。在后面我会跟大家分享我们线上MySQL数据库的编译参数,大家可以参考下,然后根据自己的线上环境自行修改内容。
1.安装MySQL需要的依赖包和编译软件
安装MySQL之前,需要安装MySQL需要的依赖包,不然会有报错,命令如下
[root@node ~]# yum install -y ncurses-devel libaio-devel [root@node ~]# rpm -qa ncurses-devel libaio-devel ncurses-devel-5.9-14.20130511.el7_4.x86_64 libaio-devel-0.3.109-13.el7.x86_64
安装编译MySQL需要的软件
[root@node ~]# yum install -y cmake ##开始编译安装 [root@node ~]# useradd mysql -s /sbin/nologin -M [root@node ~]# id mysql uid=1001(mysql) gid=1001(mysql) groups=1001(mysql) ##上传源码包 [root@node ~]# mkdir -p /home/chengzi/tools [root@node ~]# cd /home/chengzi/tools [root@node tools]# rz mysql-5.5.32.tar.gz #没有rz命令 yum install -y lrzsz 进行安装 百度云MySQL源码包链接:https://pan.baidu.com/s/18VuKEejrZiPwxh_6da4j_g 密码:8f37 [root@node tools]# tar xf mysql-5.5.32.tar.gz [root@node tools]# cd mysql-5.5.32/ ##进行编辑
编译参数
[root@node mysql-5.5.32]# cmake . -DCMAKE_INSTALL_PREFIX=/application/mysql-5.5.32 -DMYSQL_DATADIR=/application/mysql-5.5.32/data -DMYSQL_UNIX_ADDR=/application/mysql-5.5.32/mysql.sock -DDEFAULT_CHARSET=utf8 -DDEFAULT_COLLATION=utf8_general_ci -DEXTRA_CHARSETS=gbk,gb2312,utf8,ascii -DENABLED_LOCAL_INFILE=ON -DWITH_INNOBASE_STORAGE_ENGINE=1 -DWITH_FEDERATED_STORAGE_ENGINE=1 -DWITH_BLACKHOLE_STORAGE_ENGINE=1 -DWITHOUT_EXAMPLE_STORAGE_ENGINE=1 -DWITHOUT_PARTITION_STORAGE_ENGINE=1 -DWITH_FAST_MUTEXES=1 -DWITH_ZLIB=bundled -DENABLED_LOCAL_INFILE=1 -DWITH_READLINE=1 -DWITH_EMBEDDED_SERVER=1 -DWITH_DEBUG=0 ================================================================================================================ 此处做注释说明,复制需复制上部分参数,不然会有格式错误 [root@node mysql-5.5.32]# cmake . -DCMAKE_INSTALL_PREFIX=/application/mysql-5.5.32 \ 指定MySQL的安装路径 -DMYSQL_DATADIR=/application/mysql-5.5.32/data \ 指定存放MySQL的数据目录 -DMYSQL_UNIX_ADDR=/application/mysql-5.5.32/mysql.sock \ Unix的socket文件,默认/tmp/mysql.sock -DDEFAULT_CHARSET=utf8 \ 指定字符集编码 -DDEFAULT_COLLATION=utf8_general_ci \ 校验字符 -DEXTRA_CHARSETS=gbk,gb2312,utf8,ascii \ 扩展字符集 -DWITH_INNOBASE_STORAGE_ENGINE=1 \ 安装 innodb 存储引擎 -DWITH_FEDERATED_STORAGE_ENGINE=1 \ 安装 federated 存储引擎 -DWITH_BLACKHOLE_STORAGE_ENGINE=1 \ 安装 blackhole 存储引擎 -DWITHOUT_EXAMPLE_STORAGE_ENGINE=1 \ 安装 example 存储引擎 -DWITHOUT_PARTITION_STORAGE_ENGINE=1 \ 安装数据库分区 -DWITH_FAST_MUTEXES=1 \ 快速编译 -DWITH_ZLIB=bundled \ 是否支持Zlib -DENABLED_LOCAL_INFILE=1 \ 是否启用本地 LOAD DATA INFILE -DWITH_READLINE=1 \ 快捷键功能 -DWITH_EMBEDDED_SERVER=1 \ 是否要建立嵌入式服务器 -DWITH_DEBUG=0 是否包括调试支持 ================================================================================================================ [root@node mysql-5.5.32]# make && make install
设置不带版本号的软连接,如下
[root@node mysql-5.5.32]# ln -s /application/mysql-5.5.32/ /application/mysql [root@node mysql-5.5.32]# ls /application/mysql bin data include lib mysql-test scripts sql-bench COPYING docs INSTALL-BINARY man README share support-files
下面是对MySQL服务配置文件my.cnf的详解:
[client] ##客户端模块 port = 3306 ##客户端连接时的默认端口号 socket = /application/mysql-5.5.32/mysql.sock [mysqld] ##服务端配置模块有MySQL的目录和文件,通信、网络、信息安全,内存管理、优化、查询缓存区,还有MySQL日志设置等 port = 3306 ##mysql服务器监听的默认端口 socket = /application/mysql-5.5.32/mysql.sock ##socket文件是在Linux/Unix环境下特有的,用户在Linux/Unix环境下客户端连接可以不通过TCP/IP网络而直接使用unix socket连接mysql back_log = 50 ##该参数值指定到来的TCP/IP连接监听队列的连接数量,即在MySQL连接管理器线程处理他们之前的连接数量 ##back_log设置高于操作系统的限制将是无效的,其默认值为50.对于Linux系统而言,推荐设置小于512的整数 max_connections = 100 ##设置MySQL允许的并发会话的最大数量 max_connect_errors = 10 ##设置每个主机的连接请求异常中断的最大次数,当超过该次数,MySQL服务器将禁止host的连接请求,直到MySQL服务器重启或通过flush hosts命令 清空此host的相关信息 table_open_cache = 2048 ##文件描述符的大小 ##设置表告诉缓存的数目。每个连接进行,都会至少打开一个表缓存。因此,table_cache的大小英语max_connections的设置有关 max_allowed_packet = 16M ##服务器一次能处理的最大的查询包的值,也是服务器程序能够处理的最大查询 binlog_cache_size = 1M ##在一个事务中,二进制日志能够处理SQL语句的缓存的最大数字 ##在一个事务中binlog为了记录sql状态所持有的cache大小,如果你经常使用大的,多声明的事务,可以增加此值来获取更大的性能,所有 从事务来的状态都被缓冲在binlog缓冲中,然后再提交后一次性写入到binlog中,如果事务比此值大,会使用磁盘上的临时文件来替代,此 缓冲在每个链接的事务第一次更新状态时被创建 max_heap_table_size = 64M ##独立的内存表所允许的最大容量 read_buffer_size = 2M ##MySql读入缓冲区大小 ##读查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每个链接独享 read_rnd_buffer_size = 16M ##MySql的随机读缓冲区大小 ##设置进行随机读的时候使用的缓冲区。此参数和read_buffer_size所设置的Buffer相反,一个是顺序读的时候使用,一个是随机读的时 候使用。但是两者都是针对线程的设置,每个线程都可以产生两种Buffer中的任何一个。默认值是256KB,最大值4GB sort_buffer_size = 8M ##设置查询排序时所能使用的缓冲区大小,系统默认大小为8MB ## 排序缓冲被用来处理类似ORDER BY以及GROUP BY队列所引起的排序 注意:该参数对应的分配内存是每个连接独占的,如果有100个链接,那么实际分配的总排序缓冲区大小为100*6=600MB,所以对于在4GB左 右的服务器来说,推荐将其设置为6MB~8MB join_buffer_size = 8M ##联合查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每个连接独享 ##此缓冲被使用来优化全联合(full JOINs 不带索引的联合) thread_cache_size = 8 ##我们在cache中保留多少线程用于重用 #设置Thread Cache池中可以缓存的连接线程最大数量,可设置0~16384,默认为8,这个值表示可以重新利用保存在缓存中线程的数量,当 断开连接时如果缓存中还有空间,那么客户端的线程江北放到缓存中;如果线程重新被请求,那么请从缓存中读取,如果缓存中是空的或者是 新的请求,那么这个线程将被重新创建,如果有很多线程,增加这个值可以改善系统性能。通过比较Connections和Threads_created状态 的变量,可以看到这个变量的作用。1GB内存我们配置为8,2GB内存我们配置为16,3GB内存我们配置32,4GB或4GB以上我们给此值为64或更大 的值 thread_concurrency = 8 ##此允许应用程序给予线程系统一个提示在同一时间给予渴望被运行的线程的数量 ##该参数取值为服务器逻辑CPU数量x2,在本例中,服务器有两个物理CPU,而每个物理CPU又支持H.T超线程,所以实际取值为4 x 2 = 8.这 也是双核主流服务器的配置 query_cache_size = 64M ##查询缓冲的大小。查询缓冲常被用来缓冲 SELECT 的结果并且在下一次同样查询的时候不再执行直接返回结果. ##指定MySQL查询缓冲区的大小,可以通过MySQL控制台观察,如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲区不够的情况, 如果Qcache_hits的值非常大,则表明查询缓冲区使用得非常频繁。另外如果改值较小反而会影响效率,那么可以考虑不用查询缓冲,对于 Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多。 query_cache_limit = 2M ##只有小于此设定值的结果才会被缓冲 query_cache_min_res_unit = 2k ##设置查询缓存分配内存的最小单位,要适当第设置此参数,可以做到为减少内存快的申请和分配次数, 但是设置过大可能导致内存碎片数值上升。默认值为2K,建议设置为1K~16K ft_min_word_len = 4 ## 被全文检索索引的最小的字长 ##如果是英文默认值是比较合理的,但是中文绝大部分都是2个字符,这就导致小于4个字的词不能被索引,全文索引功能就形同虚设了 default-storage-engine = MYISAM ##如果在创建表的语句中没有指定,当创建一个新表时所使用的默认表类型 thread_stack = 192K ##线程使用的堆大小. 此容量的内存在每次连接时被预留 ##设置MySQL每个线程的堆栈大小,默认值足够大,可满足普通操作。可设置范围为128KB至4GB,默认为192kb transaction_isolation = REPEATABLE-READ ##数据库隔离级别 READ UNCOMMITTED==>读取未提交内容 READ COMMITTED==>读取提交内容 REPEATABLE READ==>可重读 SERIALIZABLE==>可串行化 tmp_table_size = 64M ##内部(内存中)临时表的最大大小 log-bin=mysql-bin ##打开二进制日志功能,开启binlog文件 binlog_format=mixed ##设定记录二进制日志的格式,有三种格式,基于语句 statement、 基于行 row、 混合方式 mixed slow_query_log ##记录慢查询 long_query_time = 2 ##所有的超过这个参数时间的请求将被作为慢查询 server-id = 1 ##唯一服务器标识号,如果是主从或多实例ID号不能相同 ##这个值在主服务器和从服务器是被要求设置的。他的默认参数是1,如果是主机不需要设置,但是如果忽略此选项,MySQL不会作为master生效. key_buffer_size = 32M ##关键词缓冲的大小, 一般用来缓冲MyISAM表的索引块. ##指定用于索引的缓冲区大小,增加它可以得到更好的索引处理性能。对于内存在4GB左右的服务器来说,此参数可以设置256MGB或384MB bulk_insert_buffer_size = 64M ##如果经常性的需要使用批量插入的特殊语语句来插入数据,可以适当调整参数至16MB~32MB,建议8M,设置0则禁用该优化 ##MyISAM 使用特殊的类似树的cache来使得突发插入,(这些插入是,INSERT … SELECT, INSERT … VALUES (…), (…), …, 以及 LOAD DATA INFILE) 更快. 此变量限制每个进程中缓冲树的字节数. myisam_sort_buffer_size = 128M ##当需要对于执行REPAIR, OPTIMIZE, ALTER 语句重建索引时,MySQL会分配这个缓存, 以及LOADDATA INFILE会加载到一个新表,它会根据最大的配置认真的分配的每个线程。 myisam_max_sort_file_size = 10G ##当重新建索引(REPAIR,ALTER,TABLE,或者LOAD,DATA,TNFILE)时,MySQL被允许使用 临时文件的最大值。 myisam_repair_threads = 1 ##如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复他们. myisam_recover ##自动检查和修复没有适当关闭的 MyISAM 表. innodb_additional_mem_pool_size = 16M ##附加的内存池被InnoDB用来保存 metadata 信息 #用来设置InnoDB存储的数据目录信息和其他内部数据结构的内存池大小,应用程序里的表越多,你需要在这里分配越多的内存。对于一个 相对稳定的应用,这个参数的大小也是相对应的。如果InnoDB用光了这个池内的内存,InnoDB开始从操作系统分配内存,并且往MySQL错误 日志写警告信息。当发现错误日志中已经有相关的警告信息时,就应该适当的增加该参数的大小。 innodb_buffer_pool_size = 2G ##InnoDB使用一个缓冲池来保存索引和原始数据 innodb_data_file_path = ibdata1:10M:autoextend ##InnoDB 将数据保存在一个或者多个数据文件中成为表空间. innodb_write_io_threads = 8 ##用来同步IO操作的IO线程的数量. innodb_read_io_threads = 8 innodb_thread_concurrency = 16 ##使用InnoDB引擎,内核被允许的线程数,这个最佳值取决于应用程序,硬件还有操作系统的调度程 序。太高的值肯定会导致线程抖动 innodb_flush_log_at_trx_commit = 1 ##如果设置为1 ,InnoDB会在每次提交后刷新(fsync)事务日志到磁盘上 innodb_log_buffer_size = 8M ##用来缓冲日志数据的缓冲区的大小. innodb_log_file_size = 256M ##在日志组中每个日志文件的大小, innodb_log_files_in_group = 3 ##在日志组中文件的总量,通常2-3就足够了 innodb_max_dirty_pages_pct = 90 ##在InnoDB缓冲池中最大允许的脏页面的比例. ##InnoDB缓冲池中允许的脏页面的最大百分比,如果它达到了,InnoDB将开始积极清理,以免消耗完所有的干净页面,这是一个软限制, 不保证能够一直保持。 innodb_lock_wait_timeout = 120 ##在被回滚前,一个InnoDB的事务应该等待一个锁被批准多久 #InnoDB事务被回滚之前可以等待一个锁定的超时描述,InnoDB在它自己的锁定表中自动检测事务死锁并且回滚事务。 InnoDB用local tables语句注意到锁表设置 [mysqldump] ##备份模块 quick max_allowed_packet = 16M ##设定在网络传输中一次消息量的最大值,最大值是1GB,必须设置为1024的倍数,单位为字节。 [mysql] no-auto-rehash ##只允许使用键值的updates和delete [myisamchk] key_buffer_size = 512M ##指定用于索引的缓冲区大小,增加它可以更好的索引处理性能,对于内存4GB左右的服务器来说,该 参数可以设置为256MB或384MB sort_buffer_size = 512M ##设置查询排序时所能使用的缓冲区大小. read_buffer = 8M ##读取缓冲区大小 write_buffer = 8M ##写入缓冲去大小 [mysqlhotcopy] interactive-timeout ##交互的时间 [mysqld_safe] open-files-limit = 8192 ##增加每次处理所允许打开的文件数量,确保你已经设置全局系统限制足够高。对于一个大数量的打开表,高值是必须的
注意:
具体参数需要根据业务进行设置,请操作前进行备份!
特殊说明:
- 强烈建议不要武断地将InnoDB的Buffer Pool值配置为物理内存的50%~80%,应根据具体环境而定。
- 如果key_reads太大,则应该把my.cnf中的key_buffer_size变大,保持key_reads/key_read_re-quests至少在1/100以上,越小越好。
- 如果qcache_lowmem_prunes很大,就要增加query_cache_size的值。
- 不过很多时候需要具体情况具体分析,其他参数的变更我们可以等MySQL上线稳定一段时间后在根据status值进行调整。
企业及MySQL数据库的优化配置文件(服务器为DELL R710、16GB内存、RAID10)可以根据实际情况而定
[client] port = 3306 socket = /data/3306/mysql.sock default-character-set = utf8 [mysqld] user = mysql port = 3306 character-set-server = utf8 socket = /data/3306/mysql.sock basedir = /application/mysql datadir = /data/3306/data log-error=/data/3306/mysql_err.log pid-file=/data/3306/mysql.pid log_slave_updates = 1 log-bin = /data/3306/mysql-bin binlog_format = mixed binlog_cache_size = 4M max_binlog_cache_size = 8M max_binlog_size = 1G expire_logs_days = 90 binlog-ignore - db = mysql binlog-ignore - db = information_schema key_buffer_size = 384M sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 16M join_buffer_size = 2M thread_cache_size = 8 query_cache_size = 32M query_cache_limit = 2M query_cache_min_res_unit = 2k thread_concurrency = 32 table_cache = 614 table_open_cache = 512 open_files_limit = 10240 back_log = 600 max_connections = 5000 max_connect_errors = 6000 external-locking = FALSE max_allowed_packet =16M thread_stack = 192K transaction_isolation = READ-COMMITTED tmp_table_size = 256M max_heap_table_size = 512M bulk_insert_buffer_size = 64M myisam_sort_buffer_size = 64M myisam_max_sort_file_size = 10G myisam_repair_threads = 1 myisam_recover long_query_time = 2 slow_query_log slow_query_log_file = /data/3306/slow.log skip-name-resolv skip-locking skip-networking server-id = 1 innodb_additional_mem_pool_size = 16M innodb_buffer_pool_size = 512M innodb_data_file_path = ibdata1:256M:autoextend innodb_file_io_threads = 4 innodb_thread_concurrency = 8 innodb_flush_log_at_trx_commit = 2 innodb_log_buffer_size = 16M innodb_log_file_size = 128M innodb_log_files_in_group = 3 innodb_max_dirty_pages_pct = 90 innodb_lock_wait_timeout = 120 innodb_file_per_table = 0 [mysqldump] quick max_allowed_packet = 64M [mysql] no – auto - rehash
5.存储引擎的选择
Mysql有两种存储引擎:InnoDB与Myisam
MyISAM | InnoDB | |
构成上的区别: |
每个MyISAM在磁盘上存储成三个文件。第一个 文件的名字以表的名字开始,扩展名指出文件类型。 .frm文件存储表定义。 数据文件的扩 展名为.MYD (MYData)。 索引文件的扩 展名是.MYI (MYIndex)。 |
基于磁盘的资源是InnoDB表空间数据文件和它的日志文件,InnoDB 表的 大小只受限于操作系统文件的大小,一般为 2GB |
事务处理上方面: | MyISAM类型的表强调的是性能,其执行数 度比InnoDB类型更快,但是不提供事务支持 | InnoDB提供事务支持事务,外部键等高级 数据库功能 |
|
如果执行大量的SELECT,MyISAM是更好的选择 | 1.如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑,应该使用InnoDB表 2.DELETE FROM table时,InnoDB不会重新建立表,而是一行一行的 删除。 3.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的,解决方法是首先把InnoDB表改成MyISAM表,导入数据后再改成InnoDB表,但是对于使用的额外的InnoDB特性(例如外键)的表不适用 |
对AUTO_INCREMENT的 操作
|
每表一个AUTO_INCREMEN列的内部处理。 MyISAM为INSERT和UPDATE操 作自动更新这一列。这使得AUTO_INCREMENT列更快(至少10%)。在序列顶的值被删除之后就不 能再利用。(当AUTO_INCREMENT列被定义为多列索引的最后一列, 可以出现重使用从序列顶部删除的值的情况)。 AUTO_INCREMENT值可用ALTER TABLE或myisamch来重置对于AUTO_INCREMENT类型的字段,InnoDB中必须包含只有该字段的索引,但 是在MyISAM表中,可以和其他字段一起建立联 合索引更好和更快的auto_increment处理 |
如果你为一个表指定AUTO_INCREMENT列,在数据词典里的InnoDB表句柄包含一个名为自动增长计数 器的计数器,它被用在为该列赋新值。
自动增长计数 器仅被存储在主内存中,而不是存在磁盘上 关于该计算器 的算法实现,请参考 AUTO_INCREMENT列 在InnoDB里 如何工作 |
表的具体行数
|
select count(*) from table,MyISAM只要简单的读出保存好的行数,注意的是,当count(*)语句包含 where条件时,两种表的操作是一样的 | InnoDB 中不 保存表的具体行数,也就是说,执行select count(*) from table时,InnoDB要扫描一遍整个表来计算有多少行 |
锁
|
表锁
|
提供行锁(locking on row level),提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs),另外,InnoDB表的行锁也不是绝对的,如果在执 行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表,例如update table set num=1 where name like “%aaa%” |
虽然MySQL里的存储引擎不只是MyISAM与InnoDB这两个,但常用的就是两个。
两种存储引擎的大致区别表现在:
1)InnoDB支持事务,MyISAM不支持,这一点是非常之重要。事务是一种高级的处理方式,如在一些列增删改中只要哪个出错还可以回滚还原,而MyISAM就不可以了。
2)MyISAM适合查询以及插入为主的应用,InnoDB适合频繁修改以及涉及到安全性较高的应用
3)InnoDB支持外键,MyISAM不支持
4)从MySQL5.5.5以后,InnoDB是默认引擎
5)InnoDB不支持FULLTEXT类型的索引
6)InnoDB中不保存表的行数,如select count(*) from table时,InnoDB需要扫描一遍整个表来计算有多少行,但是MyISAM只要简单的读出保存好的行数即可。注意的是,当count(*)语句包含where条件时MyISAM也需要扫描整个表
7)对于自增长的字段,InnoDB中必须包含只有该字段的索引,但是在MyISAM表中可以和其他字段一起建立联合索引
8)清空整个表时,InnoDB是一行一行的删除,效率非常慢。MyISAM则会重建表
9)InnoDB支持行锁(某些情况下还是锁整表,如 update table set a=1 where user like ‘%lee%’
MyISAM与InnoDB选择使用:
1)如果你的应用程序一定要使用事务,毫无疑问你要选择INNODB引擎。但要注意,INNODB的行级锁是有条件的。在where条件没有使用主键时,照样会锁全表。比如DELETE FROM mytable这样的删除语句。
2)如果你的应用程序对查询性能要求较高,就要使用MYISAM了。MYISAM索引和数据是分开的,而且其索引是压缩的,可以更好地利用内存。所以它的查询性能明显优于INNODB。压缩后的索引也能节约一些磁盘空间。MYISAM拥有全文索引的功能,这可以极大地优化LIKE查询的效率。
3)现在一般都是选用innodb了,主要是myisam的全表锁,读写串行问题,并发效率锁表,效率低myisam对于读写密集型应用一般是不会去选用的。
6.线上优化调整
MySQL数据库上线后,可以等其稳定运行一段时间后再根据服务器的status状态进行适当优化,我们可以用如下命令列出MySQL服务器运行的各种状态值。通过命令:
show global status; 也可以通过 show status like '查询%';
1、慢查询
有时我们为了定位系统中效率比较低下的Query语法,需要打开慢查询日志,也就是Slow Query log。打开慢查询日志的相关命令如下:
mysql>show variables like '%slow%'; +---------------------+-----------------------------------------+ |Variable_name | Value | +---------------------+-----------------------------------------+ |log_slow_queries | ON | |slow_launch_time | 2 | +---------------------+-----------------------------------------+ mysql>show global status like '%slow%'; +---------------------+-------+ |Variable_name | Value | +---------------------+-------+ |Slow_launch_threads | 0 | |Slow_queries | 2128 | +---------------------+-------+
打开慢查询日志可能会对系统性能有一点点影响,如果你的MySQL是主从结构,可以考虑打开其中一台从服务器的慢查询日志,这样既可以监控慢查询,对系统性能影响也会很小。另外,可以用MySQL自带的命令mysqldumpslow
进行查询。比如:下面的命令可以查出访问次数最多的20个SQL语句:
mysqldumpslow -s c -t 20 host-slow.log
2、连接数
我们如果经常遇见MySQL:ERROR1040:Too many connections的情况,一种情况是访问量确实很高,MySQL服务器扛不住了,这个时候就要考虑增加从服务器分散读压力,从架构层面。另外一种情况是MySQL配置文件中max_connections的值过小。来看一个例子。
mysql> show variables like 'max_connections'; +-----------------+-------+ |Variable_name | Value | +-----------------+-------+ |max_connections | 800 | +-----------------+-------+ ## 这台服务器最大连接数是800,然后查询一下该服务器响应的最大连接数; mysql> show global status like 'Max_used_connections'; +----------------------+-------+ |Variable_name | Value | +----------------------+-------+ |Max_used_connections | 245 | +----------------------+-------+ ## MySQL服务器过去的最大连接数是245,没有达到服务器连接数的上线800,不会出现1040错误。 ## Max_used_connections /max_connections * 100% = 85% ## 最大连接数占上限连接数的85%左右,如果发现比例在10%以下,则说明MySQL服务器连接数的上限设置得过高了。
3.key_buffer_size
key_buffer_size是设置MyISAM表索引缓存空间的大小,此参数对MyISAM表性能影响最大。下面是一台MyISAM为主要存储引擎服务器的配置:
mysql> show variables like 'key_buffer_size'; +-----------------+-----------+ |Variable_name | Value | +-----------------+-----------+ |key_buffer_size | 536870912 | +-----------------+-----------+ ## 从上面可以看出,分配了536MB内存给key_buffer_size。再来看key_buffer_size的使用情况: mysql> show global status like 'key_read%'; +-------------------+--------------+ |Variable_name | Value | +-------------------+--------------+ |Key_read_requests | 27813678766 | |Key_reads | 6798830 | +-------------------+--------------+ 一共有27813678766个索引读取请求,有6798830个请求在内存中没有找到,直接从硬盘读取索引。 key_cache_miss_rate = key_reads / key_read_requests * 100% 比如上面的数据,key_cache_miss_rate为0.0244%,4000%个索引读取请求才有一个直接读硬盘,效果已经很好了,key_cache_miss_rate在0.1%以 下都很好,如果key_cache_miss_rate在0.01%以下的话,则说明key_buffer_size分配得过多,可以适当减少。
4.临时表
当执行语句时,关于已经被创建了隐含临时表的数量,我们可以用如下命令查询其具体情况:
mysql> show global status like 'created_tmp%'; +-------------------------+----------+ |Variable_name | Value | +-------------------------+----------+ |Created_tmp_disk_tables | 21119 | |Created_tmp_files | 6 | |Created_tmp_tables | 17715532 | +-------------------------+----------+ ## MySQL服务器对临时表的配置: mysql> show variables where Variable_name in ('tmp_table_size','max_heap_table_size'); +---------------------+---------+ |Variable_name | Value | +---------------------+---------+ |max_heap_table_size | 2097152 | |tmp_table_size | 2097152 | +---------------------+---------+ 每次创建临时表时,Created_tmp_table都会增加,如果磁盘上创建临时表,Created_tmp_disk_tables也会增加。Created_tmp_files表示MySQL服务创建的临时文件数, 比较理想的配置是: Created_tmp_disk_tables / Created_tmp_files *100% <= 25% 比如上面的服务器: Created_tmp_disk_tables / Created_tmp_files *100% =1.20%,这个值就很棒了。
5.打开表的情况
Open_tables表示打开表的数量,Opened_tables表示打开过的表数量,我们可以用如下命令查看其具体情况:
mysql> show global status like 'open%tables%'; +---------------+-------+ |Variable_name | Value | +---------------+-------+ |Open_tables | 351 | |Opened_tables | 1455 | +---------------+-------+ ## 查询下服务器table_open_cache; mysql> show variables like 'table_open_cache'; +------------------+-------+ |Variable_name | Value | +------------------+-------+ |table_open_cache | 2048 | +------------------+-------+ 如果Opened_tables数量过大,说明配置中table_open_cache的值可能太小。 比较合适的值为: open_tables / opened_tables* 100% > = 85% open_tables / table_open_cache* 100% < = 95%
6.进程使用情况
如果我们在MySQL服务器的配置文件中设置了thread_cache_size,当客户端断开时,服务器处理此客户请求的线程将会缓存起来以响应一下客户而不是销毁(前提是缓存数未达上线)Thread_created表示创建过的线程数,我们可以用如下命令查看:
mysql> show global status like 'thread%'; +-------------------+-------+ |Variable_name | Value | +-------------------+-------+ |Threads_cached | 40 | |Threads_connected | 1 | |Threads_created | 330 | |Threads_running | 1 | +-------------------+-------+ ## 查询服务器thread_cache_size配置如下: mysql> show variables like 'thread_cache_size'; +-------------------+-------+ |Variable_name | Value | +-------------------+-------+ |thread_cache_size | 100 | +-------------------+-------+ 如果发现Threads_created的值过大的话,表明MySQL服务器一直在创建线程,这也是比较耗费资源的,可以适当增大配置文件中thread_cache_size的值。
7.查询缓存(query cache)
它主要涉及两个参数,query_cache_size
是设置MySQL的Query Cache大小,query_cache_type
是设置使用查询缓存的类型,我们可以用如下命令查看其具体情况:
mysql> show global status like 'qcache%'; +-------------------------+-----------+ |Variable_name | Value | +-------------------------+-----------+ |Qcache_free_blocks | 22756 | |Qcache_free_memory | 76764704 | |Qcache_hits | 213028692 | |Qcache_inserts | 208894227 | |Qcache_lowmem_prunes | 4010916 | |Qcache_not_cached | 13385031 | |Qcache_queries_in_cache | 43560 | |Qcache_total_blocks | 111212 | +-------------------------+-----------+
MySQL查询缓存变量的相关解释如下:
Qcache_free_blocks: 缓存中相领内存快的个数。数目大说明可能有碎片。flush query cache会对缓存中的碎片进行整理,从而得到一个空间块。
Qcache_free_memory:缓存中的空闲空间。
Qcache_hits:多少次命中。通过这个参数可以查看到Query Cache的基本效果。
Qcache_inserts:插入次数,没插入一次查询时就增加1。命中次数除以插入次数就是命中比率。
Qcache_lowmem_prunes:多少条Query因为内存不足而被清楚出Query Cache。通过Qcache_lowmem_prunes和Query_free_memory相互结合,能 够更清楚地了解到系统中Query Cache的内存大小是否真的足够,是否非常频繁地出现因为内存不足而有Query被换出的情况。
Qcache_not_cached:不适合进行缓存的查询数量,通常是由于这些查询不是select语句或用了now()之类的函数。
Qcache_queries_in_cache:当前缓存的查询和响应数量。
Qcache_total_blocks:缓存中块的数量。
query_cache
的配置命令:
mysql> show variables like 'query_cache%'; +------------------------------+---------+ |Variable_name | Value | +------------------------------+---------+ |query_cache_limit | 1048576 | |query_cache_min_res_unit | 2048 | |query_cache_size | 2097152 | |query_cache_type | ON | |query_cache_wlock_invalidate | OFF | +------------------------------+---------+
字段解释如下:
query_cache_limit:超过此大小的查询将不缓存。
query_cache_min_res_unit:缓存块的最小值。
query_cache_size:查询缓存大小。
query_cache_type:缓存类型,决定缓存什么样的查询,示例中表示不缓存select sql_no_cache查询。
query_cache_wlock_invalidat:表示当有其他客户端正在对MyISAM表进行写操作,读请求是要等WRITE LOCK释放资源后再查询还是允许直接从Query Cache中读取结果,默认为OFF(可以直接从Query Cache中取得结果。)
query_cache_min_res_unit的配置是一柄双刃剑,默认是4KB,设置值大对大数据查询有好处,但如果你的查询都是小数据查询,就容易造成内存碎片和浪费。
查询缓存碎片率 = Qcache_free_blocks /Qcache_total_blocks * 100%
如果查询碎片率超过20%,可以用 flush query cache 整理缓存碎片,或者试试减少query_cache_min_res_unit,如果你查询都是小数据库的话。
查询缓存利用率 = (Qcache_free_size – Qcache_free_memory)/query_cache_size * 100%
查询缓存利用率在25%一下的话说明query_cache_size设置得过大,可适当减少;查询缓存利用率在80%以上而且Qcache_lowmem_prunes > 50的话则说明query_cache_size可能有点小,不然就是碎片太多。
查询命中率 = (Qcache_hits – Qcache_insert)/Qcache)hits * 100%
示例服务器中的查询缓存碎片率等于20%左右,查询缓存利用率在50%,查询命中率在2%,说明命中率很差,可能写操作比较频繁,而且可能有些碎片。
8.排序使用情况
它表示系统中对数据进行排序时所用的Buffer,我们可以用如下命令查看:
mysql> show global status like 'sort%'; +-------------------+----------+ |Variable_name | Value | +-------------------+----------+ |Sort_merge_passes | 10 | |Sort_range | 37431240 | |Sort_rows |6738691532| |Sort_scan | 1823485 | +-------------------+----------+
Sort_merge_passes包括如下步骤:MySQL首先会尝试在内存中做排序,使用的内存大小由系统变量sort_buffer_size来决定,如果它不够大则把所有的记录都读在内存中,而MySQL则会把每次在内存中排序的结果存到临时文件中,等MySQL找到所有记录之后,再把临时文件中的记录做一次排序。这次再排序就会增加sort_merge_passes。实际上,MySQL会用另外一个临时文件来存储再次排序的结果,所以我们通常会看sort_merge_passes增加的数值是建临时文件数的两倍。因为用到了临时文件,所以速度可能会比较慢,增大sort_buffer_size会减少sort_merge_passes和创建临时文件的次数,但盲目地增大sort_buffer_size并不一定能提高速度。
9.文件打开数(open_files)
我们现在处理MySQL故障时,发现当Open_files大于open_files_limit值时,MySQL数据库就会发生卡住的现象,导致Nginx服务器打不开相应页面。这个问题大家在工作中应注意,我们可以用如下命令查看其具体情况:
mysql>show global status like 'open_files';
+---------------+-------+
|Variable_name | Value |
+---------------+-------+
|Open_files | 1481 |
+---------------+-------+
mysql> show global status like 'open_files_limit';
+------------------+--------+
|Variable_name | Value |
+------------------+--------+
|Open_files_limit | 4509 |
+------------------+--------+
比较合适的设置是:Open_files / Open_files_limit * 100% < = 75%
10.InnoDB_buffer_pool_cache合理设置
InnoDB存储引擎的缓存机制和MyISAM的最大区别就在于,InnoDB不仅仅缓存索引,同时还会缓存实际的数据。此参数用来设置InnoDB最主要的Buffer的大小,也就是缓存用户表及索引数据的最主要缓存空间,对InnoDB整体性能影响也最大。
无论是MySQL官方手册还是网络上许多人分享的InnoDB优化建议,都是简单地建议将此值设置为整个系统物理内存的50%~80%。这种做法其实不妥,我们应根据实际的运行场景来正确设置此项参数。
很多时候我们会发现,通过参数设置进行性能优化所带来的性能提升,并不如许多人想象的那样会产生质的飞跃,除非是之前的设置存在严重不合理的情况。我们不能将性能调优完全依托与通过DBA在数据库上线后进行参数调整,而应该在系统设计和开发阶段就尽可能减少性能问题。(重点在于前期架构合理的设计及开发的程序合理)
7.MySQL数据库的可扩展架构方案-高可用
如果凭借MySQL的优化任无法顶住压力,这个时候我们就必须考虑MySQL的可扩展性架构了(有人称为MySQL集群)它有以下明显的优势:
1)成本低,很容易通过价格低廉Pc server搭建出一个处理能力非常强大的计算机集群。
2)不太容易遇到瓶颈,因为很容易通过添加主机来增加处理能力。
3)单节点故障对系统的整体影响较小。
Get busy living or get busy dying. 努力活出精彩的人生,否则便如行尸走肉
- 转载请注明来源:Mysql数据库之优化系列
- 本文永久链接地址:https://www.xionghaier.cn/archives/419.html