MySQL性能调优思路

2023-11-12 来源：哗拓教育

,或偶尔卡住如何来处理?

是周期性的变化还是偶尔问题?是服务器整体性能的问题, 还是某单条语句的问题?

具体到单条语句, 这条语句是在等待上花的时间,还是查询上花的时间?

1.1. 监测并观察服务器的状态.

观察服务器状态, 一般用如下2个命令

Show status;Show processlist;

例: mysql> show status;

#mysqladmin ext

1.2. MySQL的每秒请求数周期性变化,随着缓存失效,有短时间的高峰

解决办法:

1: 减少无关请求(业务逻辑层面,暂不讨论,但其实是最有效的手段)

2: 如果请求数是一定的,不可减少的. 我们要尽量让请求数平稳,不要有剧烈波动.

很多时候,不是服务器撑不住总的查询量,而是在某个时间段撑不住高峰请求.

1.3.对于不规则的延迟现象的观察

不规则的延迟现象往往是由于效率低下的语句造成的,如何抓到这些效率低的语句.

可以用show processlist命令长期观察,或用慢查询.

Show processlist;

这个命令是显示当前所有连接的工作状态.

#!/bin/bashwhile truedomysql -uroot -e ‘show processlistG‘|grep State:|uniq -c|sort -rnecho ‘---‘sleep 1Done

如果观察到以下状态,则需要注意

converting HEAP to MyISAM 查询结果太大时,把结果放在磁盘 (语句写的不好,取数据太多)

create tmp table 创建临时表(如group时储存中间结果,说明索引建的不好)

Copying to tmp table on disk 把内存临时表复制到磁盘 (索引不好,表字段选的不好)

locked 被其他查询锁住 (一般在使用事务时易发生,互联网应用不常发生)

logging slow query 记录慢查询

1.4. mysql 5.5 以后加了一个profile设置,可以观察到具体语句的执行步骤.

查看profile是否开启

Show variables like ‘profiling’

开启profile

 set profiling=on;

查看profiles;

show profiles;

查看profile;

show profile for query 1;

2. 如何定位到有问题的语句?

开启服务器慢查询

了解临时表的使用规则

2.1. MySQL如何使用内部临时表

在处理请求的某些场景中,服务器创建内部临时表. 即表以MEMORY引擎在内存中处理,或以MyISAM引擎储存在磁盘上处理.如果表过大,服务器可能会把内存中的临时表转存在磁盘上.

用户不能直接控制服务器内部用内存还是磁盘存储临时表

2.2. 临时表在如下几种情况被创建:

如果group by 的列没有索引,必产生内部临时表,

如果order by 与group by为不同列时,或多表联查时order by ,group by 包含的列不是第一张表的列,将会产生临时表

distinct 与order by 一起使用可能会产生临时表

如果使用SQL_SMALL_RESULT,MySQL会使用内存临时表,除非查询中有一些必须要把临时表建立在磁盘上.

union合并查询时会用到临时表

某些视图会用到临时表,如使用temptable方式建立,或使用union或聚合查询的视图

想确定查询是否需要临时表,可以用EXPLAIN查询计划,并查看Extra列,看是否有Using temporary.

如果一开始在内存中产生的临时表变大,会自动转化为磁盘临时表. 内存中临时表的最大值为tmp_table_size和max_heap_size中较小值.

这和create table时显示指定的内存表不一样:这些表只受max_heap_table_size系统参数影响.

当服务器创建内部临时表(无论在内存还是在磁盘),create_tmp_tables变量都会增加.

如果创建了在磁盘上内部临时表(无论是初始创建还是由in-memory转化),

create_tmp_disk_tables 变量都会增加.

一些情况下限制了内存临时表的使用,而使用磁盘临时表:

(使用了内部临时表的前提下) 语句中存在BLOB或TEXT列

在GROUP BY 或 DISTINCT子句中有大于512字节的string列

在UNION或UNION ALL时,SELECT语句里有大于512字节的string列.

建表: 表结构的拆分,如核心字段都用int,char,enum等定长结构;非核心字段,或用到text,超长的varchar,拆出来单放一张表.

建索引: 合理的索引可以减少内部临时表(索引优化策略里详解)

写语句: 不合理的语句将导致大量数据传输以及内部临时表的使用.

MySQL性能调优思路

标签：不同问题 lob str 高峰多表 bsp 必须不能

小编还为您整理了以下内容，可能对您也有帮助：

怎么进行mysql数据库优化?

有八个方面可以对mysql进行优化：
1、选取最适用的字段属性
MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。
2. 使用连接（JOIN）来代替子查询(Sub-Queries)
MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。
3、使用联合(UNION)来代替手动创建的临时表
MySQL从4.0的版本开始支持union查询，它可以把需要使用临时表的两条或更多的select查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。
4、事务
尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条语句都操作成功，要么都失败
5、锁定表
尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。
6、使用外键
锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。
7、使用索引
索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(),MIN()和ORDERBY这些命令的时候，性能提高更为明显。
8、优化的查询语句
绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。

怎么进行mysql数据库优化?

几种MySQL数据库的优化方案

最近在找工作，面试时很多企业会问到关于数据库优化的问题，今天在这里总结一下数据库优化问题，以MySQL数据库为例进行讲解。
为什么要优化：
随着实际项目的启动，数据库经过一段时间的运行，最初的数据库设置，会与实际数据库运行性能会有一些差异，这时我们就需要做一个优化调整。

数据库优化这个课题较大，可分为四大类：
》主机性能
》内存使用性能
》网络传输性能
》SQL语句执行性能【软件工程师】

下面列出一些数据库SQL优化方案：
（01）选择最有效率的表名顺序（笔试常考）
数据库的解析器按照从右到左的顺序处理FROM子句中的表名，
FROM子句中写在最后的表将被最先处理，
在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后，
如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后。
例如：查询员工的编号，姓名，工资，工资等级，部门名
select emp.empno,emp.ename,emp.sal,salgrade.grade,dept.dname
from salgrade,dept,emp
where (emp.deptno = dept.deptno) and (emp.sal between salgrade.losal and salgrade.hisal)
1)如果三个表是完全无关系的话，将记录和列名最少的表，写在最后，然后依次类推
2)如果三个表是有关系的话，将引用最多的表，放在最后，然后依次类推
（02）WHERE子句中的连接顺序（笔试常考）
数据库采用自右而左的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之左,
那些可以过滤掉最大数量记录的条件必须写在WHERE子句的之右。
例如：查询员工的编号，姓名，工资，部门名
select emp.empno,emp.ename,emp.sal,dept.dname
from emp,dept
where (emp.deptno = dept.deptno) and (emp.sal > 1500)
（03）SELECT子句中避免使用*号
数据库在解析的过程中,会将*依次转换成所有的列名，这个工作是通过查询数据字典完成的，这意味着将耗费更多的时间
select empno,ename from emp;
（04）删除表中的所有记录，用TRUNCATE替代DELETE

（05）尽量多使用COMMIT
因为COMMIT会释放回滚点
（06）用WHERE子句替换HAVING子句
WHERE先执行，HAVING后执行
（07）多使用内部函数提高SQL效率

（08）使用表的别名
salgrade s
（09）使用列的别名
ename e

几种MySQL数据库的优化方案

mysql 优化包括哪些内容？

mysql的优化大的有两方面：

1、配置优化

配置的优化其实包含两个方面的：操作系统内核的优化和mysql配置文件的优化

1)系统内核的优化对专用的mysql服务器来说，无非是内存实用、连接数、超时处理、TCP处理等方面的优化，根据自己的硬件配置来进行优化，这里不多讲；

2)mysql配置的优化，一般来说包含：IO处理的常用参数、最大连接数设置、缓存使用参数的设置、慢日志的参数的设置、innodb相关参数的设置等，如果有主从关系在设置主从同步的相关参数即可，网上的相关配置文件很多，大同小异，常用的设置大多修改这些差不多就够用了。

2、sql语句的优化

1、尽量稍作计算

Mysql的作用是用来存取数据的，不是做计算的，做计算的话可以用其他方法去实现，mysql做计算是很耗资源的。

2.尽量少 join

MySQL 的优势在于简单，但这在某些方面其实也是其劣势。MySQL 优化器效率高，但是由于其统计信息的量有限，优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join，一方面由于其优化器受限，再者在 Join 这方面所下的功夫还不够，所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈。

3.尽量少排序

排序操作会消耗较多的 CPU 资源，所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL的响应时间。

对于MySQL来说，减少排序有多种办法，比如：

通过利用索引来排序的方式进行优化

减少参与排序的记录条数

非必要不对数据进行排序

4.尽量避免 select *

在数据量少并且访问量不大的情况下，select * 没有什么影响，但是量级达到一定级别的时候，在执行效率和IO资源的使用上，还是有很大关系的，用什么字段取什么字段，减少不必要的资源浪费。

之前遇到过因为一个字段存储的数据比较大，并发高的情况下把网络带宽跑满的情况，造成网站打不开或是打开速度极慢的情况。

5.尽量用 join 代替子查询

虽然 Join 性能并不佳，但是和 MySQL 的子查询比起来还是有非常大的性能优势。MySQL 的子查询执行计划一直存在较大的问题，虽然这个问题已经存在多年，但是到目前已经发布的所有稳定版本中都普遍存在，一直没有太大改善。虽然官方也在很早就承认这一问题，并且承诺尽快解决，但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。

6.尽量少 or

当 where 子句中存在多个条件以“或”并存的时候，MySQL 的优化器并没有很好的解决其执行计划优化问题，再加上 MySQL 特有的 SQL 与 Storage 分层架构方式，造成了其性能比较低下，很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果。

7.尽量用 union all 代替 union

union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的 CPU 运算，加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候，尽量使用 union all 而不是 union。

8.尽量早过滤

这一优化策略其实最常见于索引的优化设计中(将过滤性更好的字段放得更靠前)。

在 SQL 编写中同样可以使用这一原则来优化一些 Join 的 SQL。比如我们在多个表进行分页数据查询的时候，我们最好是能够在一个表上先过滤好数据分好页，然后再用分好页的结果集与另外的表 Join，这样可以尽可能多的减少不必要的 IO 操作，大大节省 IO 操作所消耗的时间。

9.避免类型转换

这里所说的“类型转换”是指 where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换：

A:人为在column_name 上通过转换函数进行转换

直接导致 MySQL(实际上其他数据库也会有同样的问题)无法使用索引，如果非要转换，应该在传入的参数上进行转换

B:由数据库自己进行转换

如果我们传入的数据类型和字段类型不一致，同时我们又没有做任何类型转换处理，MySQL 可能会自己对我们的数据进行类型转换操作，也可能不进行处理而交由存储引擎去处理，这样一来，就会出现索引无法使用的情况而造成执行计划问题。

以上两种情况在开发者因为某种原因经常会有，本来可以用到索引的结果类型不对没有用到索引，或是因为类型不对又有越界的情况发生造成无法使用索引的情况，结果造成很严重的事故。

10.优先优化高并发的 SQL，而不是执行频率低某些“大”SQL

对于破坏性来说，高并发的 SQL 总是会比低频率的来得大，因为高并发的 SQL 一旦出现问题，甚至不会给我们任何喘息的机会就会将系统压跨。而对于一些虽然需要消耗大量 IO 而且响应很慢的 SQL，由于频率低，即使遇到，最多就是让整个系统响应慢一点，但至少可能撑一会儿，让我们有缓冲的机会。

11.从全局出发优化，而不是片面调整

SQL 优化不能是单独针对某一个进行，而应充分考虑系统中所有的 SQL，尤其是在通过调整索引优化 SQL 的执行计划的时候，千万不能顾此失彼，因小失大。

12.尽可能对每一条运行在数据库中的SQL进行 explain

优化 SQL，需要做到心中有数，知道SQL 的执行计划才能判断是否有优化余地，才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化之后，很明显的问题 SQL 可能已经很少了，大多都需要去发掘，这时候就需要进行大量的 explain 操作收集执行计划，并判断是否需要进行优化。

从编译到工具:几种Mysql的优化方法

一、在编译时优化mysql
如果你从源代码分发安装mysql，要注意，编译过程对以后的目标程序性能有重要的影响，不同的编译方式可能得到类似的目标文件，但性能可能相差很大，因此，在编译安装mysql适应仔细根据你的应用类型选择最可能好的编译选项。这种定制的mysql可以为你的应用提供最佳性能。
技巧：选用较好的编译器和较好的编译器选项，这样应用可提高性能10-30%。（mysql文档如是说）
1.1、使用pgcc（pentium　gcc)编译器
该编译器针对运行在奔腾处理器系统上的程序进行优化，用pgcc编译mysql源代码，总体性能可提高10%。当然如果你的服务器不是用奔腾处理器，就不必用它了，因为它是专为奔腾系统设计的。
1.2、仅使用你想使用的字符集编译mysql
mysql目前提供多达24种不同的字符集，为全球用户以他们自己的语言插入或查看表中的数据。却省情况下，mysql安装所有者这些字符集，热然而，最好的选择是指选择一种你需要的。如，禁止除latin1字符集以外的所有其它字符集：
------------------------------------------------------------------------------
%./configure　-with-extra-charsets=none　[--other-configuration-options]
------------------------------------------------------------------------------
1.3、将mysqld编译成静态执行文件
将mysqld编译成静态执行文件而无需共享库也能获得更好的性能。通过在配置时指定下列选项，可静态编译mysqld。
------------------------------------------------------------------------------
%./configure　-with-mysqld-ldflags=-all-static　[--other-configuration-options]
------------------------------------------------------------------------------
1.4、配置样本
下列配置命令常用于提高性能：
------------------------------------------------------------------------------
%cflags="-o6　-mpentiumpro　-fomit-frame-pointer"　cxx=gcc　cxxflags="-o6　-mpentiumpro　-fomit-frame-pointer　-felide-constructors　-fno-exceptions　-fno-rtti"　./configure　--prefix=/usr/local　--enable-assembler　--with-mysqld-ldflags=-all-static　--disable-shared
------------------------------------------------------------------------------
二、调整服务器
确保运用正确的编译固然重要，但这只是成功的第一步，配置众多的mysql变量同样对服务器的正常运行起关键作用。你可以将这些变量的赋值存在一个配置文件中，以确保它们在每次启动mysql时均起作用，这个配置文件就是my.cnf文件。
mysql已经提供了几个my.cnf文件的样本，可在/usr/local/mysqld/share/mysql/目录下找到。这些文件分别命名为my-small.cnf、　my-medium.cnf、my-large.cnf和my-huge.cnf，规模说明可在描述配置文件适用的系统类型标题中找到。如果在只有相当少内存的系统上运行mysql，而且只是偶尔的用一下，那么my-small.cnf会比较理想，因为它命令mysqld只使用最少的资源。类似地，如果你计划构建电子商务超市，而且系统拥有2g内存，那么你可能要用到mysql-huge.cnf文件了。为了利用这些文件中的一个，你需要复制一个最适合需求的文件，改名为my.cnf。你可以选择使用配置文件三种作用范围的一种：
global：将my.cnf文件复制到服务器的/etc目录下，这使得配置文件中的变量作用于全局，即对所有服务器上的mysql数据库服务器有效。
local：将my.cnf文件复制到[mysql-install-dir]/var/目录下，使得my.cnf作用于特定的服务器。[mysql-install-dir]表示mysql安装目录。
user：你可以再*作用于特定的用户，将my.cnf复制到用户的根目录下。
究竟如何设置my.cnf中的这些变量呢？更进一步说，你可以设置哪一个变量。虽然所用变量对mysql服务器相对通用，每一个变量与mysql的的某些组件有更特定的关系。如变量max_connects归在mysqld类别下。执行下列命令即可知道：
------------------------------------------------------------------
%/usr/local/mysql/libexec/mysqld　--help
------------------------------------------------------------------
它显示大量的选项及与mysqld相关的变量。你可以很容易地在该行文字之下找出变量：
-------------------------------------------------------------------
possible　variables　for　option　--set-variable　(-o)　are
-------------------------------------------------------------------
然后你可以如下设置my.cnf中的那些变量：
-------------------------------------------------------------------
set-variable　=　max_connections=100
-------------------------------------------------------------------
它设置mysql服务器的最大并发连接数为100。要确保在my.cnf文件中的[mysqld]标题下插入变量设置。
三、表类型
很多mysql用户可能很惊讶，mysql确实为用户提供5种不同的表类型，称为dbd、heap、isam、merge和myiasm。dbd归为事务安全类，而其他为非事务安全类。
3.1、事务安全
dbd
berkeley　db(dbd)表是支持事务处理的表，由sleepycat软件公司开发。它提供mysql用户期待已久的功能-事务控制。事务控制在任何数据库系统中都是一个极有价值的功能，因为它们确保一组命令能成功地执行。
3.2、非事务安全
heap
heap表是mysql中存取数据最快的表。这是因为他们使用存储在动态内存中的一个哈希索引。另一个要点是如果mysql或服务器崩溃，数据将丢失。
isam
isam表是早期mysql版本的缺省表类型，直到myiasm开发出来。建议不要再使用它。
merge
merge是一个有趣的新类型，在3.23.25之后出现。一个merge表实际上是一个相同myisam表的集合，合并成一个表，主要是为了效率原因。这样可以提高速度、搜索效率、修复效率并节省磁盘空间。
myiasm
这是mysql的缺省表类型。它基于iasm代码，但有很多有用的扩展。myiasm比较好的原因：
myiasm表小于iasm表，所以使用较少资源。
myiasm表在不同的平台上二进制层可移植。
更大的键码尺寸，更大的键码上限。
3.3、指定表类型
你可在创建表时指定表的类型。下例创建一个heap表：
--------------------------------------------------------------------
mysqlcreate　table　email_addresses　type=heap　(-email　char(55)　not　null,
-name　char(30)　not　null,
-primary　key(email)　);
---------------------------------------------------------------------
bdb表需要一些配置工作。
3.4、更多的表类型
为了使mysql管理工作更有趣，即将发布的mysql　4.0将提供两种新的表类型，称为innobase和gemeni。
四、优化工具
mysql服务器本身提供了几条内置命令用于帮助优化。
4.1、show
你可能有兴趣知道mysql服务器究竟更了什么，下列命令给出一个总结：
-----------------------------------
mysqlshow　status;
-----------------------------------
它给出了一个相当长的状态变量及其值的列表。有些变量包含了异常终止客户的数量、异常终止连接的数量、连接尝试的次数、最大并发连接数和大量其他有用的信息。这些信息对找出系统问题和低效极具价值。
show还能做更多的事情。它可以显示关于日志文件、特定数据库、表、索引、进程和权限表中有价值的信息。详见mysql手册。
4.2、explain
当你面对select语句时，explain解释select命令如何被处理。这不仅对决定是否应该增加一个索引，而且对决定一个复杂的join如何被mysql处理都是有帮助的。
4.3、optimize
optimize语句允许你恢复空间和合并数据文件碎片，对包含变长行的表进行了大量更新和删除后，这样做特别重要。optimize目前只工作于myiasm和bdb表。

从编译到工具:几种Mysql的优化方法

mysql数据库的优化方法？

我们都知道，服务器数据库的开发一般都是通过java或者是PHP语言来编程实现的，而为了提高我们数据库的运行速度和效率，数据库优化也成为了我们每日的工作重点，今天，南邵IT培训就一起来了解一下mysql服务器数据库的优化方法。

为什么要了解索引

真实案例

案例一：大学有段时间学习爬虫，爬取了知乎300w用户答题数据，存储到mysql数据中。那时不了解索引，一条简单的“根据用户名搜索全部回答的sql“需要执行半分钟左右，完全满足不了正常的使用。

案例二：近线上应用的数据库频频出现多条慢sql风险提示，而工作以来，对数据库优化方面所知甚少。例如一个用户数据页面需要执行很多次数据库查询，性能很慢，通过增加超时时间勉强可以访问，但是性能上需要优化。

索引的优点

合适的索引，可以大大减小mysql服务器扫描的数据量，避免内存排序和临时表，提高应用程序的查询性能。

索引的类型

mysql数据中有多种索引类型，primarykey，unique，normal，但底层存储的数据结构都是BTREE;有些存储引擎还提供hash索引，全文索引。

BTREE是常见的优化要面对的索引结构，都是基于BTREE的讨论。

B-TREE

查询数据简单暴力的方式是遍历所有记录;如果数据不重复，就可以通过组织成一颗排序二叉树，通过二分查找算法来查询，大大提高查询性能。而BTREE是一种更强大的排序树，支持多个分支，高度更低，数据的插入、删除、更新更快。

现代数据库的索引文件和文件系统的文件块都被组织成BTREE。

btree的每个节点都包含有key，data和只想子节点指针。

btree有度的概念d>=1。假设btree的度为d，则每个内部节点可以有n=[d+1，2d+1)个key，n+1个子节点指针。树的大高度为h=Logb[(N+1)/2]。

索引和文件系统中，B-TREE的节点常设计成接近一个内存页大小(也是磁盘扇区大小)，且树的度非常大。这样磁盘I/O的次数，就等于树的高度h。假设b=100，一百万个节点的树，h将只有3层。即，只有3次磁盘I/O就可以查找完毕，性能非常高。

索引查询

建立索引后，合适的查询语句才能大发挥索引的优势。

另外，由于查询优化器可以解析客户端的sql语句，会调整sql的查询语句的条件顺序去匹配合适的索引。

如何优化mysql写入速

单机MySQL数据库的优化
一、服务器硬件对MySQL性能的影响
①磁盘寻道能力（磁盘I/O），我们现在上的都是SAS15000转的硬盘。MySQL每秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知。所以，通常认为磁盘I/O是制约MySQL性能的最大因素之一，对于日均访问量在100万PV以上的Discuz!论坛，由于磁盘I/O的制约，MySQL的性能会非常低下！解决这一制约因素可以考虑以下几种解决方案：使用RAID1+0磁盘阵列，注意不要尝试使用RAID-5，MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快。
②CPU 对于MySQL应用，推荐使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我现在比较喜欢DELL R710，也在用其作Linuxakg 虚拟化应用；
③物理内存对于一台使用MySQL的Database Server来说，服务器内存建议不要小于2GB，推荐使用4GB以上的物理内存，不过内存对于现在的服务器而言可以说是一个可以忽略的问题，工作中遇到高端服务器基本上内存都超过了32G。
我们工作中用得比较多的数据库服务器是HP DL580G5和DELL R710，稳定性和性能都不错；特别是DELL R710，我发现许多同行都是采用它作数据库的服务器，所以重点推荐下。
二、MySQL的线上安装我建议采取编译安装的方法，这样性能上有较大提升，服务器系统我建议用64bit的Centos5.5，源码包的编译参数会默认以Debgu模式生成二进制代码，而Debug模式给MySQL带来的性能损失是比较大的，所以当我们编译准备安装的产品代码时，一定不要忘记使用“— without-debug”参数禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二个编译参数设置为—all-static的话，可以告诉编译器以静态方式编译和编译结果代码得到最高的性能。使用静态编译和使用动态编译的代码相比，性能差距可能会达到5%至10%之多。我参考了简朝阳先生的编译参数，特列如下，供大家参考
./configure –prefix=/usr/local/mysql –without-debug –without-bench –enable-thread-safe-client –enable-assembler –enable-profiling –with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static –with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb –with-csv-storage-engine –with-federated-storage-engine –with-mysqld-user=mysql –without-我是怎么了ded-server –with-server-suffix=-community –with-unix-socket-path=/usr/local/mysql/sock/mysql.sock
三、MySQL自身因素当解决了上述服务器硬件制约因素后，让我们看看MySQL自身的优化是如何操作的。对 MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面介绍一些对性能影响较大的参数。
下面，根据以上硬件配置结合一份已经优化好的my.cnf进行说明：
#vim /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的内容，其他段落内容对MySQL运行性能影响甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部锁定，减少出错几率增强稳定性。
skip-name-resolve
#禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！
back_log = 384
#back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自己的*。试图设定back_log高于你的操作系统的*将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。
key_buffer_size = 384M
#key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。注意：该参数值设置的过大反而会是服务器整体效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 614K
sort_buffer_size = 6M
#查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。
read_buffer_size = 4M
#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
join_buffer_size = 8M
#联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
#指定MySQL查询缓冲区的大小。可以通过在MySQL控制台观察，如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况；如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓冲；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。
tmp_table_size = 256M
max_connections = 768
#指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提示，则需要增大该参数值。
max_connect_errors = 1000
wait_timeout = 10
#指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
thread_concurrency = 8
#该参数取值为服务器逻辑CPU数量*2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4*2=8；这个目前也是双四核主流服务器配置。
skip-networking
#开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！
table_cache=1024
#物理内存越大，设置就越大。默认为2402,调到512-1024最佳
innodb_additional_mem_pool_size=4M
#默认为2M
innodb_flush_log_at_trx_commit=1
#设置为0就是等到innodb_log_buffer_size列队满后再统一储存，默认为1
innodb_log_buffer_size=2M
#默认为1M
innodb_thread_concurrency=8
#你的服务器CPU有几个就设置为几，建议用默认一般为8
key_buffer_size=256M
#默认为218，调到128最佳
tmp_table_size=64M
#默认为16M，调到64-256最挂
read_buffer_size=4M
#默认为64K
read_rnd_buffer_size=16M
#默认为256K
sort_buffer_size=32M
#默认为256K
thread_cache_size=120
#默认为60
query_cache_size=32M
※值得注意的是：
很多情况需要具体情况具体分析
一、如果Key_reads太大，则应该把my.cnf中Key_buffer_size变大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。
很多时候我们发现，通过参数设置进行性能优化所带来的性能提升，可能并不如许多人想象的那样产生质的飞跃，除非是之前的设置存在严重不合理的情况。我们不能将性能调优完全依托于通过DBA在数据库上线后进行的参数调整，而应该在系统设计和开发阶段就尽可能减少性能问题。
【51CTO独家特稿】如果单MySQL的优化始终还是顶不住压力时，这个时候我们就必须考虑MySQL的高可用架构（很多同学也爱说成是MySQL集群）了，目前可行的方案有：
一、MySQL Cluster
优势：可用性非常高，性能非常好。每份数据至少可在不同主机存一份拷贝，且冗余数据拷贝实时同步。但它的维护非常复杂，存在部分Bug，目前还不适合比较核心的线上系统，所以这个我不推荐。
二、DRBD磁盘网络镜像方案
优势：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致性的苛刻要求。但非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于 MySQL Replication。另外，DRBD也是官方推荐的可用于MySQL高可用方案之一，所以这个大家可根据实际环境来考虑是否部署。
三、MySQL Replication
在实际应用场景中，MySQL Replication是使用最为广泛的一种提高系统扩展性的设计手段。众多的MySQL使用者通过Replication功能提升系统的扩展性后，通过简单的增加价格低廉的硬件设备成倍甚至成数量级地提高了原有系统的性能，是广大MySQL中低端使用者非常喜欢的功能之一，也是许多MySQL使用者选择MySQL最为重要的原因。
比较常规的MySQL Replication架构也有好几种，这里分别简单说明下
MySQL Replication架构一：常规复制架构--Master-slaves，是由一个Master复制到一个或多个Salve的架构模式，主要用于读压力大的应用数据库端廉价扩展解决方案，读写分离，Master主要负责写方面的压力。
MySQL Replication架构二：级联复制架构，即Master-Slaves-Slaves,这个也是为了防止Slaves的读压力过大，而配置一层二级 Slaves，很容易解决Master端因为附属slave太多而成为瓶劲的风险。
MySQL Replication架构三：Dual Master与级联复制结合架构，即Master-Master-Slaves，最大的好处是既可以避免主Master的写操作受到Slave集群的复制带来的影响，而且保证了主Master的单点故障。
以上就是比较常见的MySQL replication架构方案，大家可根据自己公司的具体环境来设计，Mysql 负载均衡可考虑用LVS或Haproxy来做，高可用HA软件我推荐Heartbeat。
MySQL Replication的不足：如果Master主机硬件故障无法恢复，则可能造成部分未传送到slave端的数据丢失。所以大家应该根据自己目前的网络规划，选择自己合理的Mysql架构方案，跟自己的MySQL DBA和程序员多沟涌，多备份（备份我至少会做到本地和异地双备份），多测试，数据的事是最大的事，出不得半点差错，切记切记。

如何优化mysql写入速

mysql 存储过程执行太慢怎么优化

1.当我们请求mysql服务器的时候,MySQL前端会有一个监听,请求到了之后,服务器得到相关的SQL语句,执行之前(虚线部分为执行),还会做权限的判断

2.通过权限之后,SQL就到MySQL内部,他会在查询缓存中,看该SQL有没有执行过,如果有查询过,则把缓存结果返回,说明在MySQL内部,也有一个查询缓存.但是这个查询缓存,默认是不开启的,这个查询缓存,和我们的Hibernate，Mybatis的查询缓存是一样的,因为查询缓存要求SQL和参数都要一样,所以这个命中率是非常低的（没什么卵用的意思）。

3.如果我们没有开启查询缓存,或者缓存中没有找到对应的结果,那么就到了解析器,解析器主要对SQL语法进行解析

4.解析结束后就变成一颗解析树,这个解析树其实在Hibernate里面也是有的,大家回忆一下,在以前做过Hibernate项目的时候,是不是有个一个antlr.jar。这个就是专门做语法解析的工具.因为在Hibernate里面有HQL，它就是通过这个工具转换成SQL的,我们编程语言之所以有很多规范、语法,其实就是为了便于这个解析器解析,这个学过编译原理的应该知道.

5.得到解析树之后,不能马上执行,这还需要对这棵树进行预处理,也就是说,这棵树,我没有经过任何优化的树,预处理器会这这棵树进行一些预处理,比如常量放在什么地方,如果有计算的东西,把计算的结果算出来等等...

6.预处理完毕之后,此时得到一棵比较规范的树,这棵树就是要拿去马上做执行的树,比起之前的那棵树,这棵得到了一些优化

7.查询优化器，是MySQL里面最关键的东西,我们写任何一条SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它会怎么去执行?它是先执行username = toby还是password = 1?每一条SQL的执行顺序查询优化器就是根据MySQL对数据统计表的一些信息,比如索引,比如表一共有多少数据,MySQL都是有缓存起来的,在真正执行SQL之前,他会根据自己的这些数据,进行一个综合的判定,判断这一次在多种执行方式里面,到底选哪一种执行方式,可能运行的最快.这一步是MySQL性能中,最关键的核心点,也是我们的优化原则.我们平时所讲的优化SQL,其实说白了,就是想让查询优化器,按照我们的想法,帮我们选择最优的执行方案,因为我们比MySQL更懂我们的数据.MySQL看数据,仅仅只是自己收集到的信息,这些信息可能是不准确的,MySQL根据这些信息选了一个它自认为最优的方案,但是这个方案可能和我们想象的不一样.

8.这里的查询执行计划,也就是MySQL查询中的执行计划,比如要先执行username = toby还是password = 1

9.这个执行计划会传给查询执行引擎,执行引擎选择存储引擎来执行这一份传过来的计划,到磁盘中的文件中去查询,这个时候重点来了,影响这个查询性能最根本的原因是什么?就是硬盘的机械运动,也就是我们平时熟悉的IO,所以一条查询语句是快还是慢,就是根据这个时间的IO来确定的.那怎么执行IO又是什么来确定的?就是传过来的这一份执行计划.(优化就是制定一个我们认为最快的执行方案,最节省IO,和执行最快)

10.如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。

如何优化MySQL insert性能

1. 一条SQL语句插入多条数据。

常用的插入语句如：

INSERTINTO`insert_table` (`datetime`, `uid`, `content`, `type`) VALUES('0', 'userid_0', 'content_0', 0);

INSERTINTO`insert_table` (`datetime`, `uid`, `content`, `type`) VALUES('1', 'userid_1', 'content_1', 1);

修改成：

INSERTINTO`insert_table` (`datetime`, `uid`, `content`, `type`) VALUES('0', 'userid_0', 'content_0', 0), ('1', 'userid_1', 'content_1', 1);

修改后的插入操作能够提高程序的插入效率。这里第二种SQL执行效率高的主要原因有两个，一是减少SQL语句解析的操作，只需要解析一次就能进行数据的插入操作，二是SQL语句较短，可以减少网络传输的IO。

这里提供一些测试对比数据，分别是进行单条数据的导入与转化成一条SQL语句进行导入，分别测试1百、1千、1万条数据记录。

性能测试：这里提供了同时使用上面两种方法进行INSERT效率优化的测试。即多条数据合并为同一个SQL，并且在事务中进行插入。

2. 在事务中进行插入处理。把插入修改成：

START TRANSACTION;

INSERTINTO`insert_table` (`datetime`, `uid`, `content`, `type`) VALUES('0', 'userid_0', 'content_0', 0);

INSERTINTO`insert_table` (`datetime`, `uid`, `content`, `type`) VALUES('1', 'userid_1', 'content_1', 1);

...

COMMIT;

使用事务可以提高数据的插入效率，这是因为进行一个INSERT操作时，MySQL内部会建立一个事务，在事务内进行真正插入处理。通过使用事务可以减少创建事务的消耗，所有插入都在执行后才进行提交操作。

这里也提供了测试对比，分别是不使用事务与使用事务在记录数为1百、1千、1万的情况。

从测试结果可以看到，insert的效率大概有50倍的提高，这个一个很客观的数字。

显示全文

全部栏目

MySQL性能调优思路