mysql——MySQL 常见故障汇总与优化

一、案例概述

MySQL 是目前企业最常见的数据库之一，占用绝大部分市场份额。在日常维护管理的过程中相信大家肯定会遇到很多常见的故障，为了提高故障处理的及时性，本章案例将常见故 障进行汇总，加强学习经验。另外数据库的默认的配置无法满足高性能网站架构的需求，从 工作经验上总结 MySQL 数据库应该如何优化。
要学习如何优化，首先要对 MySQL 的逻辑架构有个深入的了解。下图是 MySQL 逻辑架构图，可以让我们更清晰了解 MySQL 的运行原理。

最上层是一些客户端和连接服务，包含本地 sock 通信和大多数基于客户端/ 服务器端工具实现的类似于 tcp/ip 的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。 同样在该层上可以实现基于 SSL 的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
第二层架构主要完成大多少的核心服务功能，如 SQL 接口，并完成缓存的查询，SQL 的分析和优化及部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如过程、函数 等。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化如确定查 询表的顺序，是否利用索引等，最后生成相应的执行操作。如果是 select 语句，服务器还会查询内部的缓存。如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升 系统的性能。
存储引擎层，存储引擎真正的负责了 MySQL 中数据的存储和提取，服务器通过 API 与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行 选取。数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的 交互。

二、案例

2.1 案例环境

本案例故障汇总和优化相当于一个对数据库经验的总结，所以案例环境比较简单，只需 一台数据库模拟单实例环境，另外两台数据库模拟主从环境即可，但是绝大多数故障场景是无法模拟的。也就是说无法复现的。MySQL 版本使用的是 5.6。

2.2 案例需求

1） MySQL 常见故障解决。
2） MySQL 性能优化。

2.3 案例实现思路

1） 单库常见故障分析。
2） 主从常见故障分析。
3） 从几个不同方面优化 MySQL。

2.4 MySQL 单实例故障排查

1.故障现象 1

ERROR	2002	(HY000):	Can't	connect	to	local	MySQL	server	through	socket '/data/mysql/mysql.sock'

问题分析：以上这种情况一般都是数据库未启动或者数据库端口被防火墙拦截导致。
解决方法：启动数据库或者防火墙开放数据库监听端口。

2. 故障现象 2

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

问题分析：密码不正确或者没有权限访问。
解决方法：
1）修改 my.cnf 主配置文件，在[mysqld]下添加 skip-grant-tables，重启数据库。最后修改密码命令如下：

mysql> use mysql;
mysql> update user set password=password("123456") where user="root";

再删除刚刚添加的 skip-grant-tables 参数，再重启数据库，使用新密码即可登录。
2）重新授权，命令如下:

mysql> grant all on *.* to 'root'@'mysql-server' identified by '123456';

3. 故障现象 3

在使用远程连接数据库时偶尔会发生远程连接数据库很慢的问题。
问题分析：如果 MySQL 主机查询 DNS 很慢或是有很多客户端主机时会导致连接很慢，由于开发机器是不能够连接外网的，所以 DNS 解析是不可能完成的，从而也就明白了为什么连接那么慢了。
解决方法：
修改 my.cnf 主配置文件，在[mysqld]下添加 skip-name-resolve，重启数据库可以解决。注意在以后授权里面不能再使用主机名授权。

4. 故障现象 4

Can't open file: 'xxx_forums.MYI'. (errno: 145)

问题分析：
1） 服务器非正常关机，数据库所在空间已满，或一些其它未知的原因，对数据库表造成了损坏。
2） 可能是操作系统下直接将数据库文件拷贝移动会因为文件的属组问题而产生这个错误。
解决方法：
可以使用下面的两种方式修复数据表：（第一种方法仅适合独立主机用户）
1 ） 使用 myisamchk ， MySQL 自带了专门用户数据表检查和修复的工具 — — myisamchk 。一般情况下只有在这个下面才能运行 myisamchk 命令。常用的修复命令为： myisamchk -r 数据文件目录/数据表名.MYI；
2）通过 phpMyAdmin 修复， phpMyAdmin 带有修复数据表的功能，进入到某一个表中后，点击“操作”，在下方的“表维护”中点击“修复表”即可。
注意：以上两种修复方式在执行前一定要备份数据库。修改文件的属组（仅适合独立主机用户）：
复制数据库文件的过程中没有将数据库文件设置为 MySQL 运行的帐号可读写（一般适用于 Linux 和 FreeBSD 用户）。

5. 故障现象 5

ERROR 1129 (HY000): Host 'xxx.xxx.xxx.xxx' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'

问题分析：
由于 mysql 数据库的参数：max_connect_errors（系统默认 10） mysqld 已经得到了大量(max_connect_errors)的主机’hostname’的在中途被中断了的连接请求累计超过 10 次， 就再也无法连接上 mysqld 服务，同一个 ip 在短时间内产生太多中断的数据库连接而导致的阻塞（超过 mysql 数据库 max_connection_errors 的最大值）。
解决方法：
1） 使用 mysqladmin flush-hosts 命令清除缓存，命令执行方法如下：

mysqladmin -uroot -p -h 192.168.241.48 flush-hosts 
Enter password:

2） 修改 mysql 配置文件，在[mysqld]下面添加 max_connect_errors=1000，然后重启MySQL。

6. 故障现象 6

客户端报 Too many connections
问题分析：连接数超出 Mysql 的最大连接限制。
解决方法：
1） 在 my.cnf 配置文件里面增加连接数，然后重启 MySQL 服务。max_connections = 10000
2） 临时修改最大连接数，重启后不生效。需要在 my.cnf 里面修改配置文件，下次重启生效。

set GLOBAL max_connections=10000;

7. 故障现象 7

Warning: World-writable config file '/etc/my.cnf' is ignored 
ERROR! MySQL is running but PID file could not be found

问题分析：MySQL 的配置文件/etc/my.cnf 权限不对。
解决方法：

chmod 644 /et/my.cnf

8. 故障现象 8

InnoDB: Error: page 14178 log sequence number 29455369832
InnoDB: is in the future! Current system log sequence number 29455369832

问题分析：innodb 数据文件损坏。
解决方法：修改 my.cnf 配置文件，在[mysqld]下添加 innodb_force_recovery=4, 启动数据库后备份数据文件，然后去掉该参数，利用备份文件恢复数据。

2.5 MySQL 主从故障排查

1. 故障现象 1

从库的 Slave_IO_Running 为 NO

The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).

问题分析：主库和从库的 server-id 值一样.
解决方法：修改从库的 server-id 的值，修改为和主库不一样，比主库低。修改完后重启，再同步即可！

2. 故障现象 2

从库的 Slave_IO_Running 为 NO问题分析：
问题分析：造成从库线程为 NO 的原因会有很多，主要原因是主键冲突或者主库删除或更新数据， 从库找不到记录，数据被修改导致。通常状态码报错有 1007、1032、1062、1452 等。
解决方法一：

mysql> stop slave;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> start slave;

解决方法二：
设置用户权限，设置从库只读权限

set global read_only=true;

3. 故障现象 3

Error initializing relay log position: I/O error reading the header from the binary log 

分析问题：从库的中继日志 relay-bin 损坏.
解决方法：手工修复，重新找到同步的 binlog 和 pos 点，然后重新同步即可。

mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.xxx',MASTER_LOG_POS=xxx; 

三、MySQL 优化

1. 硬件方面

说到服务器硬件，最主要的无非 CPU、内存、磁盘三大关键因素。

1）关于 CPU
CPU 对于 MySQL 应用，推荐使用 S.M.P.架构的多路对称 CPU，例如：可以使用两颗 Intel Xeon 3.6GHz 的 CPU，现在比较推荐用 4U 的服务器来专门做数据库服务器，不仅仅是针对于MySQL。
2） 关于内存
物理内存对于一台使用 MySQL 的 Database Server 来说，服务器内存建议不要小于 2GB， 推荐使用 4GB 以上的物理内存，不过内存对于现在的服务器而言可以说是一个可以忽略的问题，工作中遇到了高端服务器基本上内存都超过了 32G。
2） 关于磁盘
磁盘寻道能力（磁盘 I/O）,以目前市场上普遍高转速 SAS 硬盘(15000 转/秒)为例，这种硬盘理论上每秒寻道 15000 次，这是物理特性决定的，没有办法改变。 MySQL 每秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知。所以通常认为磁盘 I/O 是制约MySQL 性能的最大因素之一，通常是使用 RAID-0+1 磁盘阵列，注意不要尝试使用 RAID-5， MySQL 在 RAID-5 磁盘阵列上的效率不会像你期待的那样快。如果不考虑硬件的投入成本， 也可以考虑固态（SSD）硬盘专门作为数据库服务器使用。数据库的读写性能肯定会提高很多。

2. MySQL 配置文件

通常默认的 my.cnf 配置文件无法发挥出 MySQL 最高的性能，所以需要根据不同的硬件进行优化，配置文件的优化也是重点，下面是物理内存为 32G 的数据库优化参数，具体从全局、二进制日志、主从、innodb、myisam 几个方面优化，仅供参考。

1. default-time-zone=+8:00
   #默认 mysql 使用的是系统时区，修改为北京时间，也就是所说的东八区。
2. interactive_timeout = 120
   #服务器关闭交互式连接前等待活动的秒数。
3. wait_timeout = 120
   #服务器关闭非交互连接之前等待活动的秒数。
4. open_files_limit = 10240
   #MySQL 服务器打开文件句柄数限制。
5. group_concat_max_len = 102400
   #mysql 默认的拼接最大长度为 1024 个字节，由于 1024 个字节会出现不够用的情况， 根据实际情况进行修改。
6. user=mysql
   #使用 mysql 用户运行。
   character-set-server=utf8
   init_connect=‘SET NAMES utf8’ #设置字符集为 utf8
7. back_log = 600
   #在 MySQL 暂时停止响应新请求之前，短时间内的多少个请求可以被存在堆栈中。如果系统在短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的 TCP/IP 连接的监听队列的大小。默认值 50。
8. max_connections = 5000
   #MySQL 允许最大的进程连接数，如果经常出现 Too Many Connections 的错误提示， 则需要增大此值。
9. max_connect_errors = 6000
   #设置每个主机的连接请求异常中断的最大次数，当超过该次数，MySQL 服务器将禁止host 的连接请求，直到 mysql 服务器重启或通过 flush hosts 命令清空此 host 的相关信息。
10. table_cache = 1024
    #指示表调整缓冲区大小。它设置表高速缓存的数目。每个连接进来，都会至少打开一个表缓存。因此，table_cache 的大小应与 max_connections 的设置有关。例如，对于 200 个并行运行的连接，应该让表的缓存至少有 200 × N 。这里 N 是应用可以执行的查询的一个连接中表的最大数量。此外，还需要为临时表和文件保留一些额外的文 件描述符。 当 Mysql 访问一个表时，如果该表在缓存中已经被打开，则可以直接访问缓存；如果还没有被缓存，但是在 Mysql 表缓冲区中还有空间，那么这个表就被打开并放入表缓冲区；如果表缓存满了，则会按照一定的规则将当前未用的表释放，或者临时扩大 表 缓 存 来 存 放 ， 使 用 表 缓 存 的 好 处 是 可 以 更 快 速 地 访 问 表 中 的 内 容 。 执行 flush tables 会清空缓存的内容。一般来说，可以通过 show status 命令查看数据库运行峰值时间的状态值 Open_tables 和 Opened_tables ， 判断是否需要增加 table_cache 的 值 （ 其 中 open_tables 是 当 前 打 开 的 表 的 数量， Opened_tables 则是已经打开的表的数量）。即如果 open_tables 接近 table_cache 的时候，并且 Opened_tables 这个值在逐步增加，那就要考虑增加这个值的大小了。还有就是 Table_locks_waited 比较高的时候，也需要增加 table_cache。
11. table_open_cache = 2048指定表高速缓存的大小。每当 MySQL 访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。
12. max_heap_table_size = 256M这个变量定义了用户可以创建的内存表(memory table)的大小.这个值用来计算内存表的最大行数值。这个变量支持动态改变，即 set @max_heap_table_size=#但是对于已经存在的内存表就没有什么用了，除非这个表被重新创建(create table) 或者修改(alter table)或者 truncate table。服务重启也会设置已经存在的内存表为全局max_heap_table_size 的值。
13. external-locking = false
    #使用 skip-external-locking MySQL 选项以避免外部锁定。该选项默认开启。
14. max_allowed_packet = 32M#设置在网络传输中一次消息传输量的最大值。系统默认值 为 1MB，最大值是 1GB，必须设置 1024 的倍数。
15. sort_buffer_size = 512M# Sort_Buffer_Size 是一个 connection 级参数，在每个 connection（session）第一次需要使用这个 buffer 的时候，一次性分配设置的内存。Sort_Buffer_Size 并不是越大越好，由于是 connection 级的参数，过大的设置+高并发可能会耗尽系统内存资源。
    16.join_buffer_size = 8M#用于表间关联缓存的大小，和 sort_buffer_size 一样，该参数对应的分配内存也是每个连接独享。
16. thread_cache_size = 300# 服务器线程缓存这个值表示可以重新利用保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中,如果线程重新被请求，那么请求将从缓存中读取,如果缓存中是空的或者是新的请求，那么这个线程将被重新创建,如果有很多新 的 线 程 ， 增 加 这 个 值 可 以 改 善 系 统 性 能 . 通 过 比较 Connections 和 Threads_created 状态的变量，可以看到这个变量的作用。设置规则如下：1GB 内存配置为 8，2GB 配置为 16，3GB 配置为 32，4GB 或更高内存，可配置更大。
17. thread_concurrency = 8# 设置 thread_concurrency 的值的正确与否, 对 mysql 的性能影响很大, 在多个cpu(或多核)的情况下，错误设置了 thread_concurrency 的值, 会导致 mysql 不能充分利用多 cpu(或多核), 出现同一时刻只能一个 cpu(或核)在工作的情况。thread_concurrency 应设为 CPU 核数的 2 倍. 比如有一个双核的 CPU, 那么 thread_concurrency 的应该为4; 2 个双核的 cpu, thread_concurrency 的值应为 8。
18. query_cache_size = 512M# 对于使用 MySQL 的用户，对于这个变量大家一定不会陌生。前几年的 MyISAM 引擎优化中，这个参数也是一个重要的优化参数。但随着发展，这个参数也爆露出来一些问题。机器的内存越来越大，人们也都习惯性的把以前有用的参数分配的值越来越大。这个参数加大 后也引发了一系列问题。我们首先分析一下 query_cache_size 的工作原理：一个 SELECT 查询在 DB 中工作后，DB 会把该语句缓存下来，当同样的一个 SQL 再次来到 DB 里调用时， DB 在该表没发生变化的情况下把结果从缓存中返回给 Client。这里有一个关建点，就是 DB 在利用 Query_cache 工作时，要求该语句涉及的表在这段时间内没有发生变更。那如果该表在发生变更时，Query_cache 里的数据又怎么处理呢？首先要把 Query_cache 和该表相关的语句全部置为失效，然后在写入更新。那么如果 Query_cache 非常大，该表的查询结构又比较多，查询语句失效也慢，一个更新或是 Insert 就会很慢，这样看到的就是 Update 或是Insert 怎么这么慢了。所以在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建议把该功能禁掉。
19. query_cache_limit = 4M#指定单个查询能够使用的缓冲区大小，缺省为 1M。
20. query_cache_min_res_unit = 2k#默认是 4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易 造 成 内 存 碎 片 和 浪 费 ， 查 询 缓 存 碎 片率 = Qcache_free_blocks / Qcache_total_blocks * 100%，如果查询缓存碎片率超 过 20% ， 可 以 用 FLUSH QUERY 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% 。
21. default-storage-engine = innodb#默认引擎，现在一般都是 innodb 引擎表居多。
22. thread_stack = 192K#设置MYSQL 每个线程的堆栈大小，默认值足够大，可满足普通操作。可设置范围为 128K 至 4GB，默认为 192KB。
23. transaction_isolation = READ-COMMITTED# 设定默认的事务隔离级别，READ COMMITTEE 是读已提交
24. tmp_table_size = 256M# tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小，MySQL 产生一个 The table tbl_name is full 形式的错误，如果执行很多高级 GROUP BY 查询，增加 tmp_table_size 值。如果超过该值，则会将临时表写入磁盘。
25. 26. key_buffer_size = 1024M#批定用于索引的缓冲区大小，增加它可以得到更好的索引处理性能。
26. read_buffer_size = 2M# MySql 读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql 会为它分配一段内存缓冲区。read_buffer_size 变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，可以通过增加该变量值以及内存 缓冲区大小提高其性能。和 sort_buffer_size 一样，该参数对应的分配内存也是每个连接独享。
27. read_rnd_buffer_size = 256M# MySql 的随机读（查询操作）缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySql 会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。但 MySql 会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。
28. bulk_insert_buffer_size = 64M#批量插入数据缓存大小，可以有效提高插入效率，默认为 8M。
29. skip-name-resolve#禁止域名解析，包括主机名，所以当授权的时候使用 IP 地址。
30. ft_min_word_len = 1#从 Mysql 4.0 开始就支持全文索引功能，但是 Mysql 默认的最小索引长度是 4。如果是英文默认值是比较合理的，但是中文绝大部分词都是 2 个字符，这就导致小于 4 个字的词都不能被索引，Mysql 全文索引是专门为了解决模糊查询提供的，可以对整篇文章预先按照词进行索引，搜索效率高，能够支持百万级的数据检索。下面几个参数时关于 MySQL 二进制日志文件的优化。
31. log-bin=mysql-bin#打开 MySQL 二进制功能。
32. binlog_cache_size = 4M#在事务过程中容纳二进制日志 SQL 语句的缓存大小。二进制日志缓存是服务器支持事务存储引擎并且服务器启用了二进制日志(—log-bin 选项)的前提下为每个客户端分配的内存，注意，是每个 Client 都可以分配设置大小的 binlogcache 空间。可以通过 MySQL 的以下两个状态变量来判断当前的 binlog_cache_size 的状况： Binlog_cache_use 和Binlog_cache_disk_use。
33. max_binlog_cache_size = 128M#但是所代表的是 binlog 能够使用的最大 cache 内存大小。当我们执行多语句事务的时候 ， max_binlog_cache_size 如 果 不 够 大 的 话 ， 系 统 可 能 会 报 出“Multi-statementtransactionrequiredmorethan’max_binlog_cache_size’bytesofstorag e”的错误。
34. max_binlog_size = 1G#Binlog 日志最大值，一般来说设置为 512M 或者 1G，但不能超过 1G。该大小并不能非常严格控制Binlog 大小，尤其是当到达Binlog 比较靠近尾部而又遇到一个较大事务的时候，系统为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有 SQL 都记录进入当前日志，直到该事务结束。这一点和 Oracle 的 Redo 日志有点不一样，因为 Oracle 的Redo 日志所记录的是数据文件的物理位置的变化，而且里面同时记录了 Redo 和 Undo 相关的信息，所以同一个事务是否在一个日志中对 Oracle 来说并不关键。而 MySQL 在 Binlog 中所记录的是数据库逻辑变化信息，MySQL 称之为 Event，实际上就是带来数据库变化的 DML 之类的 Query 语句。
35. sync_binlog=1#在 MySQL 中系统默认的设置是 sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统 Crash，在 binlog_cache 中的所有 binlog 信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为 1 的时候，即使系统 Crash，也最多丢失 binlog_cache 中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为 0 和设置为 1 的系统写入性能差距可能高达 5 倍甚至更多。
36. binlog_format=mixed#默认使用 statement 模式，基于 SQL 语句的复制，另外一种是基于行的复制，为提升效率，可以将以上两种模式的混合使用，一般的复制使用 STATEMENT 模式保存 binlog，对于 STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlog，MySQL 会根据执行的 SQL 语句选择日志保存方式。
37. expire_logs_days = 7二进制日志只留存最近 7 天，不用人工手动删除。
38. log-slave-updates#这条参数只读主从架构适用，当从库 log_slave_updates 参数没有开启时，从库的binlog 不会记录来源于主库的操作记录。只有开启 log_slave_updates，从库 binlog 才会记录主库同步的操作日志。
39. slow_query_log#打开慢查询日志
40. slow_query_log_file=slow.log#慢查询日志文件位置
41. long_query_time = 2#记录超过 2 秒的 SQL 查询关于引擎是 innodb 的优化如下：
42. innodb_additional_mem_pool_size = 64M#这个参数用来设置 InnoDB 存储的数据目录信息和其它内部数据结构的内存池大小， 类似于 Oracle 的 library cache。这不是一个强制参数，可以被突破。
43. innodb_buffer_pool_size = 20480M# 这对 Innodb 表来说非常重要。Innodb 相比 MyISAM 表对缓冲更为敏感。MyISAM 可以在 默 认 的 key_buffer_size 设 置 下 运 行 的 可 以 ， 然 而 Innodb 在 默 认的 innodb_buffer_pool_size 设置下却跟蜗牛似的。由于 Innodb 把数据和索引都缓存起来， 无需留给操作系统太多的内存， 因此如果只需要用 Innodb 的话则可以设置它高达 70-80% 的可用内存。一些应用于 key_buffer 的规则有 — 如果你的数据量不大， 并且不会暴增，那么无需把 innodb_buffer_pool_size 设置的太大了。
44. innodb_data_file_path = ibdata1:1024M:autoextend#表空间文件 重要数据
45. innodb_file_io_threads = 4#文件 IO 的线程数，一般为 4，但是在 Windows 下，可以设置得较大。
46. .innodb_thread_concurrency = 8#服务器有几个 CPU 就设置为几，建议用默认设置，一般为 8。
47. innodb_write_io_threads = 8# InnoDB 使用后台线程处理数据页上写 I/O（输入输出）请求的数量。一般设置为 CPU 核数，比如 CPU 是 2 颗 8 核的，可以设置为 8。
48. innodb_read_io_threads = 8# InnoDB 使用后台线程处理数据页上读 I/O（输入输出）请求的数量。一般设置为 CPU 核数，比如 CPU 是 2 颗 8 核的，可以设置为 8。
49. innodb_flush_log_at_trx_commit = 2# 如果将此参数设置为 1，将在每次提交事务后将日志写入磁盘。为提供性能，可以设置为 0 或 2，但要承担在发生故障时丢失数据的风险。设置为 0 表示事务日志写入日志文件，而日志文件每秒刷新到磁盘一次。设置为 2 表示事务日志将在提交时写入日志，但日志文件每次刷新到磁盘一次。
50. innodb_log_buffer_size = 16M# 此参数确定些日志文件所用的内存大小，以 M 为单位。缓冲区更大能提高性能，但意外的故障将会丢失数据.MySQL 开发人员建议设置为 1－8M 之间
51. innodb_log_file_size = 256M# 此参数确定数据日志文件的大小，以 M 为单位，更大的设置可以提高性能，但也会增加恢复故障数据库所需的时间
52. innodb_log_files_in_group = 3# 为提高性能，MySQL 可以以循环方式将日志文件写到多个文件。
53. innodb_file_per_table = 1# 独享表空间（关闭）
54. innodb_max_dirty_pages_pct = 90# Buffer_Pool 中 Dirty_Page 所占的数量， 直接影响 InnoDB 的关闭时间。参数innodb_max_dirty_pages_pct 可以直接控制了Dirty_Page 在Buffer_Pool 中所占的比率， 而且幸运的是 innodb_max_dirty_pages_pct 是可以动态改变的。所以，在关闭 InnoDB 之前先将 innodb_max_dirty_pages_pct 调小， 强制数据块 Flush 一段时间， 则能够大大缩短 MySQL 关闭的时间。
55. innodb_lock_wait_timeout = 120# InnoDB 有其内置的死锁检测机制，能导致未完成的事务回滚。但是，如果结合InnoDB 使用 MyISAM 的 lock tables 语句或第三方事务引擎,则 InnoDB 无法识别死锁。为消除这种可能性，可以将 innodb_lock_wait_timeout 设置为一个整数值，指示 MySQL 在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)。
56. innodb_open_files = 8192#innodb 打开文件句柄数。关于引擎是 myisam 的优化如下：
57. myisam_sort_buffer_size = 128M# MyISAM 表发生变化时重新排序所需的缓冲
58. myisam_max_sort_file_size = 10G# MySQL 重 建 索 引 时 所 允 许 的 最 大 临 时 文 件 的 大小 (当 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE)。如果文件大小比此值更大,索引会通过键值缓冲创建(更慢)
59. myisam_max_extra_sort_file_size = 10G
60. myisam_repair_threads = 1# 如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复。这对于拥有多个 CPU 以及大量内存情况的用户,是一个很好的选择。
61. myisam_recover#自动检查和修复没有适当关闭的 MyISAM 表