MySQL性能测试调优

MySQL性能测试调优

操作系统

基本操作

查看磁盘分区mount选项

$ mount

永久修改分区mount选项(系统重启后生效)

修改文件 /etc/fstab 中对应分区的mount options列的值

在线修改分区mount选项(系统重启后失效)

$sudo -t ext4 -o remount,noatime,errors=remount-or /

文件系统优化

ext4文件系统优化

分区mount选项加noatime $sudo -t ext4 -o remount,noatime,errors=remo

注意:刚开始加了 nodelalloc 发现mysql写入不如去掉此参数(原因需分析)[参考:http://blog.tao.ma/?p=58]

MySQL

基本操作

显示innodb引擎状态

mysql> show engine innodb status;

查看配置参数

mysql> show variables [like ‘‘];

查看运行状态值

mysql> show global status [like ‘‘];

修改配置参数方法

4.1. 修改配置文件(重启服务生效,适用于所有参数)

文件位置: /etc/my.cnf

4.2. 命令动态修改(重启服务失效,适用于动态参数)

°mysql> set global [参数]=[值]

重启MySQL服务

$ sudo service [mysql.server] restart

赋权同时添加用户,刷新权限

语法:

mysql> grant [权限] privileges on [数据库].[对象] to [用户名]%‘[机器名]‘ identified by ‘[密码]‘;

示例:

mysql> grant all privileges on *.* to [email protected]‘%‘ identified by ‘pass1‘;
mysql> grant all privileges on *.* to [email protected]‘localhost‘ identified by ‘pass1‘;
mysql> flush privileges;

参数调整

innodb_buffer_pool_size 参考

作用:

InnoDB用于缓存表及索引数据的内存缓冲区,InnoDB加速优化首要参数

说明:

InnoDB用于缓存表及索引数据的内存缓冲区容量的字节数。默认是128M。最大值受限于CPU架构;32位系统最大4294967295 (2的32次方减1),64位系统最大18446744073709551615 (2的64次方减1)。在32位系统中,CPU架构和操作系统可以使用的实际最大值可能小于理论上的最大值。当缓冲区大小超过1GB时,设置innodb_buffer_pool_instances为大于1的值,能够改进一个负荷较大的服务器的可扩展性。
如果你将这个值设的较大,当多次访问数据表中相同的数据时可以减少磁盘IO.专用的数据库服务器上,你可以将此值设置为机器物理内存的80%。如果出现以下问题,请缩小该参数的值。
1.物理内存争用,导致操作系统进行页调度
2.InnoDB用额外的内存进行缓冲和控制结构,所以总共分配的内存将比指定的约大10%
3.地址空间必须是连续的,这在Windows系统中某些DLL需要加载指定地址时可能是一个问题
4.初始化缓冲池的时间与它的大小成正比,如果缓冲池太大,初始化时间可能比较长。例如,在一个现代的Linux x86_64服务器,初始化10GB的缓冲池大约需要6秒。

修改方法:

静态参数,必须通过配置文件修改: innodb_buffer_pool_size=8G

日志相关参数

2.1. innodb_log_file_size 参考

作用:

日志组中每个日志文件大小

说明:

日志组中每个日志文件的大小. 所有日志文件大小总和(innodb_log_file_size * innodb_log_files_in_group)不能超过一个最大值(略小于512GB)。例如,两个255G的日志文件刚好接近但未超过最大值。默认值是48M。合理的取值范围是1MB到缓冲池大小的1/N,N是日志组中日志文件个数。这个值越大,缓冲池就需要更少的刷新检查,减少磁盘IO。但是值过大会加大宕机恢复时间,虽然自MySQL5.5改进了恢复性能,但是还是要考虑下这个值的合理性。

修改方法:

静态参数,必须通过配置文件修改: innodb_log_file_size=256M

2.2. innodb_log_files_in_group 参考

作用:

日志组中日志文件个数。

说明:

日志组中日志文件个数。InnoDB循环方式写日志文件。默认值(也是建议值)是2。日志文件的位置通过innodb_log_group_home_dir指定。所有日志文件大小总和(innodb_log_file_size * innodb_log_files_in_group)不能超过一个最大值(略小于512GB)。

修改方法:

静态参数,必须通过配置文件修改: innodb_log_files_in_group=3

2.3. innodb_log_buffer_size 参考

作用:

InnoDB写日志文件到磁盘的缓冲区大小

说明:

InnoDB写日志文件到磁盘的缓冲区大小。默认值是8M。大的日志缓冲区支持大事务运行,在事务提交前不需要将日志写到磁盘。如果你有些事务update,insert或delete很多行,加大日志缓冲可以减少磁盘IO。

修改方法:

静态参数,必须通过配置文件修改: innodb_log_buffer_size=16M

innodb_flush_method 参考

作用:

控制InnoDB flush数据和日志文件采用的系统调用

说明:

Windows不用设置
Linux可选择:fdatasync(默认),O_DSYNC,O_DIRECT(直接写入磁盘,禁止系统Cache),O_DIRECT_NO_FSYNC(>=5.6.7版本支持)

修改方法:

静态参数,必须通过配置文件修改: innodb_flush_method=O_DIRECT

innodb_flush_log_at_trx_commit(未修改) 参考

作用:

控制事务符合ACID和提高系统性能之间的权衡

说明:

这个参数在事务符合ACID和高性能之间进行平衡,你可以通过调整这个参数达到高性能,但是宕机时可能丢失1秒的事务。
这个参数有3个值选项0,1,2:
1(默认值):严格遵从ACID,事务提交时log buffer被写到日志文件中,并将日志文件内容flush到磁盘。
0:任何mysqld进程崩溃丢失1秒钟的事务。log buffer每隔1秒被写入日志文件并将日志文件刷新到磁盘,事务提交时不执行log buffer写入日志文件的操作。因为系统调度问题,不能保证每秒日志文件都刷新到磁盘百分之百执行。
2:任何mysqld进程崩溃丢失1秒钟的事务。事务提交时log buffer被写入日志文件,每隔1秒将日志文件刷新到磁盘。因为系统调度问题,不能保证每秒日志文件都刷新到磁盘百分之百执行。

修改方法:

动态参数,可以通过配置文件和命令修改:innodb_flush_log_at_trx_commit=2

原文地址:https://www.cnblogs.com/youjianjiangnan/p/11833871.html

时间: 2024-10-14 05:20:46

MySQL性能测试调优的相关文章

MySQL性能调优与架构设计——第10章 MySQL数据库Schema设计的性能优化

第10章 MySQL Server性能优化 前言: 本章主要通过针对MySQL Server(mysqld)相关实现机制的分析,得到一些相应的优化建议.主要涉及MySQL的安装以及相关参数设置的优化,但不包括mysqld之外的比如存储引擎相关的参数优化,存储引擎的相关参数设置建议将主要在下一章“常用存储引擎的优化”中进行说明. 10.1 MySQL 安装优化 选择合适的发行版本 1. 二进制发行版(包括RPM等包装好的特定二进制版本) 由于MySQL开源的特性,不仅仅MySQL AB提供了多个平

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化 前言: 很多人都认为性能是在通过编写代码(程序代码或者是数据库代码)的过程中优化出来的,其实这是一个非常大的误区.真正影响性能最大的部分是在设计中就已经产生了的,后期的优化很多时候所能够带来的改善都只是在解决前妻设计所遗留下来的一些问题而已,而且能够解决的问题通常也比较有限.本章将就如何在 MySQL 数据库 Schema 设计的时候保证尽可能的高效,尽可能减少后期的烦恼. 9.1 高效的模型设计 最规范的就一定

MySQL性能调优与架构设计——第1章 MySQL 基本介绍

MySQL性能调优与架构设计——第1章 MySQL 基本介绍 前言:作为最为流行的开源数据库软件之一, MySQL 数据库软件已经是广为人知了. 但是为了照顾对MySQL还不熟悉的读者,这章我们将对 MySQL 做一个简单的介绍.主要内容包括MySQL 各功能模块组成,各模块协同工作原理, Query 处理的流程等. 1.1 MySQLServer 简介 1.1.1 什么是 MySQLMySQL 是由MySQL AB公司(目前已经被SUN公司收归麾下,SUN已经被Oracle收购)自主研发的,目

101个MySQL的调优技巧(1)

MySQL是一个功能强大的开源数据库. 随着越来越多的数据库驱动的应用程序,人们一直在推动MySQL发展到它的极限. 这里是101条调节和优化MySQL安装的技巧. 一些技巧是针对特定的安装环境的,但这些思路是通用的. 我已经把他们分成几类,来帮助你掌握更多MySQL的调节和优化技巧. MySQL 服务器硬件和操作系统调节: 1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中--在内存中访问文件时的速度要比在硬盘中访问时快的多. 2. 不惜一切代价避免使用Swap交换分区 – 交换时是

MySQL性能调优与架构设计——第 18 章 高可用设计之 MySQL 监控

第 18 章 高可用设计之 MySQL 监控 前言: 一个经过高可用可扩展设计的 MySQL 数据库集群,如果没有一个足够精细足够强大的监控系统,同样可能会让之前在高可用设计方面所做的努力功亏一篑.一个系统,无论如何设计如何维护,都无法完全避免出现异常的可能,监控系统就是根据系统的各项状态的分析,让我们能够尽可能多的提前预知系统可能会出现的异常状况.即使没有及时发现将要发生的异常,也要在异常出现后的第一时间知道系统已经出现异常,否则之前的设计工作很可能就白费了. 18.1 监控系统设计 系统监控

数据库服务器mysql性能调优

mysql性能调优分为4个方面 一.硬件(CPU   内存   硬盘)监控CPU  内存 硬盘的值.[[email protected] ~]# toptop - 03:58:11 up 10:05,  1 user,  load average: 0.00, 0.00, 0.00Tasks: 121 total,   1 running, 120 sleeping,   0 stopped,   0 zombieCpu(s):  0.0%us,  0.7%sy,  0.0%ni, 99.0%i

MySQL性能调优与架构设计——第 17 章 高可用设计之思路及方案

第 17 章 高可用设计之思路及方案 前言: 数据库系统是一个应用系统的核心部分,要想系统整体可用性得到保证,数据库系统就不能出现任何问题.对于一个企业级的系统来说,数据库系统的可用性尤为重要.数据库系统一旦出现问题无法提供服务,所有系统都可能无法继续工作,而不像软件中部分系统出现问题可能影响的仅仅只是某个功能无法继续服务.所以,一个成功的数据库架构在高可用设计方面也是需要充分考虑的.本章内容将针对如何构建一个高可用的 MySQL 数据库系统来介绍各种解决方案以及方案之间的比较. 17.1 利用

MySQL性能调优与架构设计——第 14 章 可扩展性设计之数据切分

第 14 章 可扩展性设计之数据切分 前言 通过 MySQL Replication 功能所实现的扩展总是会受到数据库大小的限制,一旦数据库过于庞大,尤其是当写入过于频繁,很难由一台主机支撑的时候,我们还是会面临到扩展瓶颈.这时候,我们就必须许找其他技术手段来解决这个瓶颈,那就是我们这一章所要介绍恶的数据切分技术. 14.1 何谓数据切分 可能很多读者朋友在网上或者杂志上面都已经多次见到关于数据切分的相关文章了,只不过在有些文章中称之为数据的 Sharding.其实不管是称之为数据的 Shard

[转]MySQL性能调优与架构设计——第11章 常用存储引擎优化

第11章 常用存储引擎优化 前言: MySQL 提供的非常丰富的存储引擎种类供大家选择,有多种选择固然是好事,但是需要我们理解掌握的知识也会增加很多.每一种存储引擎都有各自的特长,也都存在一定的短处.如何将各种存储引擎在自己的应用环境中结合使用,扬长避短,也是一门不太简单的学问.本章选择最为常用的两种存储引擎进行针对性的优化建议,希望能够对读者朋友有一定的帮助. 11.1 MyI SAM存储引擎优化 我们知道,MyISAM存储引擎是MySQL最为古老的存储引擎之一,也是最为流行的存储引擎之一.对