2016.9.2

最近被阿里云的数据库要搞疯掉了

自打阿里云抽风，非要取消myisam引擎，都换成innodb

没事总是主备切换，也没有错误日志

一问客服就是物理机波动，擦，波动是什么？？？？？？？？

服务器自己跳舞了吗

看了看参数设置，很多都不知道

这两天有时间自己搜索整理了下

发给大家，有需要的看看

我的服务器应用主要是WEB网站服务

有一些不懂的地方或者不对的地方，还请大牛不吝赐教！

回复在评论中就可以了，thank you

我是K哥

auto_increment_offset表示自增长字段从那个数开始，他的取值范围是1 .. 65535

auto_increment_increment表示自增长字段每次递增的量，其默认值是1，取值范围是1 .. 65535

back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。

也就是说，如果MySql的连接数据达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log，如果等待连接的数量超过back_log，将不被授予连接资源。

将会报：unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时.    

back_log值不能超过TCP/IP连接的侦听队列的大小。若超过则无效，查看当前系统的TCP/IP连接的侦听队列的大小命令：cat /proc/sys/net/ipv4/tcp_max_syn_backlog目前系统为1024。

对于Linux系统推荐设置为小于512的整数。

修改系统内核参数，查看mysql 当前系统默认back_log值， 查看当前数量命令：show variables like ‘back_log‘;

我给了3000

binlog_cache_size （global）默认即可

Binlog Cache 用于在打开了二进制日志（binlog）记录功能的环境，是 MySQL 用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。

一般来说，如果我们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。但是如果我们的数据库大事务较多，写入量比较大，可与适当调高binlog_cache_size。同时，我们可以通过binlog_cache_use 以及 binlog_cache_disk_use来分析设置的binlog_cache_size是否足够，是否有大量的binlog_cache由于内存大小不够而使用临时文件（binlog_cache_disk_use）来缓存了。

Binlog_cache_use 显示 事务的数量被用于这个buffer(也可能是临时文件)用于存储语句。  

Binlog_cache_disk_use 显示多少的事务数 必须得使用临时文件  

这两个变量能用于调整binlog_cache_size 到一个足够大的值来避免使用临时文件 

mysql> show status like ‘binlog_%‘;   

+-----------------------+------------+  

| Variable_name         | Value      |  

+-----------------------+------------+  

| Binlog_cache_disk_use | 102374     |   

| Binlog_cache_use      | 1549499037 |   

character_set_server: 服务器安装时指定的默认字符集设定。

character_set_database: 数据库服务器中某个库使用的字符集设定，如果建库时没有指明，将使用服务器安装时指定的字符集设置。

concurrent_inser：在MyISAM里读写操作是串行的，但当对同一个表进行查询和插入操作时，为了降低锁竞争的频率，根据concurrent_insert的设置，MyISAM是可以并行处理查询和插入的：

当concurrent_insert=0时，不允许并发插入功能。

当concurrent_insert=1时，允许对没有洞洞的表使用并发插入，新数据位于数据文件结尾（缺省）。

当concurrent_insert=2时，不管表有没有洞洞，都允许在数据文件结尾并发插入。

connect_timeout，默认10没问题

该参数控制在与服务器建立连接的时候等待三次握手成功的超时时间，该参数主要是对于网络质量较差导致连接超时，建议外网访问波动较大可以提高该参数。

default_time_zone，MySQL的时区

default_week_format， week()函数使用的默认周格式。

delayed_insert_limit用于控制写入数量，每次handler写入磁盘的数据达到此限制后会查看是否有阻塞的select操作，如果有则允许其优先执行，以避免过分阻塞读操作

delayed_insert_timeout当队列为空时，handler在等待规定的时间后会自动退出

delayed_queue_size用于控制队列大小(每个表可对应一个)，默认100，如队列已满则initiator需要等待直到有足够空间为止

delay_key_write：是指在表关闭之前，将对表的update操作更新数据到磁盘，而不更新索引到磁盘，把对索引的更改记录在内存。（这个选项的作用是暂时制止MySQL在该命令每插入一条新记录和每修改一条现有之后立刻对索引进行刷新，对索引的刷新将等到全部记录插入/修改完毕之后再进行）

这样MyISAM表可以使索引更新更快。在关闭表的时候一起更新索引到磁盘。

写入多开，读取多关

div_precision_increment：小数位精度控制，默认4就是0.0000

default-storage-engine(设置MySQL的默认存储引擎)

default-storage-engine= InnoDB(设置InnoDB类型，另外还可以设置MyISAM类型)

设置创建数据库及表默认存储类型

show table status like ‘tablename’显示表的当前存储状态值

查看MySQL有哪些存储状态及默认存储状态

 show engines;

创建表并指定存储类型

CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB;

修改表存储类型：

  Alter table tableName engine =engineName

备注：设置完后把以下几个开启：

# Uncomment the following if you are using InnoDB tables

innodb_data_home_dir = /var/lib/mysql

#innodb_data_file_path = ibdata1:1024M;ibdata2:10M:autoextend（要注释掉，否则会创建一个新的把原来的替换的。）

innodb_log_group_home_dir = /var/lib/mysql

# You can set .._buffer_pool_size up to 50 - 80 %

# of RAM but beware of setting memory usage too high

innodb_buffer_pool_size = 1000M

innodb_additional_mem_pool_size = 20M

# Set .._log_file_size to 25 % of buffer pool size

innodb_log_file_size = 500M

innodb_log_buffer_size = 20M

innodb_flush_log_at_trx_commit = 0

innodb_lock_wait_timeout = 50

设置完后一定记得把MySQL安装目录地址（我们目前是默认安装所以地址/var/lib/mysql/）下的ib_logfile0和ib_logfile1删除掉。否则重启MySQL起动失败。

ft_min_word_len：指定被索引的关键词的最小长度。注意：在更改该参数值后，索引必须重建！

ft_query_expansion_limit 20 0 1000 MyISAM引擎表使用 with query expansion 进行全文搜索的最大匹配数

group_concat_max_len：无要求默认即可

MySQL提供的group_concat函数可以拼接某个字段值成字符串，如 select group_concat(user_name) from sys_user,默认的分隔符是 逗号，即"," ，如果需要自定义分隔符可以使用 SEPARATOR

如：select group_concat(user_name SEPARATOR ‘_‘)  from sys_user

但是如果 user_name  拼接的字符串的长度字节超过1024 则会被截断。

通过命令 "show variables like ‘group_concat_max_len‘ " 来查看group_concat 默认的长度：

mysql> show variables like ‘group_concat_max_len‘;

+----------------------+-------+

| Variable_name | Value |

+----------------------+-------+

| group_concat_max_len | 1024 |

+----------------------+-------+

1 row in set

在MySQL配置文件中添加配置：group_concat_max_len = -1  （-1为最大值或根据实际需求设置长度），配置后需要重启MySQL服务，查看如下所示:

mysql> show variables like ‘group_concat_max_len‘;

+----------------------+------------+

| Variable_name | Value |

+----------------------+------------+

| group_concat_max_len | 4294967295 |

innodb_adaptive_hash_index，默认启动即可

哈希（hash）是一种非常快的查找方法，一般情况下查找的时间复杂度为O（1）。常用于连接（join）操作，如SQL Server和Oracle中的哈希连接（hash join）。但是SQL Server和Oracle等常见的数据库并不支持哈希索引（hash index）。MySQL的Heap存储引擎默认的索引类型为哈希，而InnoDB存储引擎提出了另一种实现方法，自适应哈希索引（adaptive hash index）。

InnoDB存储引擎会监控对表上索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以称之为自适应（adaptive）的。自适应哈希索引通过缓冲池的B+树构造而来，因此建立的速度很快。而且不需要将整个表都建哈希索引，InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。

根据InnoDB的官方文档显示，启用自适应哈希索引后，读取和写入速度可以提高2倍；对于辅助索引的连接操作，性能可以提高5倍。在我看来，自适应哈希索引是非常好的优化模式，其设计思想是数据库自优化（self-tuning），即无需DBA对数据库进行调整。

我是K哥

innodb_additional_mem_pool_size（global）

这个参数我们平时调整的可能不是太多，很多人都使用了默认值，可能很多人都不是太熟悉这个参数的作用。innodb_additional_mem_pool_size 设置了InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，所以当我们一个MySQL Instance中的数据库对象非常多的时候，是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。

这个参数大小是否足够还是比较容易知道的，因为当过小的时候，MySQL 会记录 Warning 信息到数据库的 error log 中，这时候你就知道该调整这个参数大小了。

根据MySQL手册，对于2G内存的机器，推荐值是20M。32G内存的 100M

innodb_autoinc_lock_mode：默认1即可

在5.1.22在之后，InnoDB为了解决自增主键锁表的问题，引入了参数innodb_autoinc_lock_mode。这个值为0时，每次申请自增主键时需要锁表。

这个参数的默认值是1，设为此值时，每次会“预申请”多余的id(handler.cc: compute_next_insert_id)，而insert执行完成后，会特别将这些预留的id空出，动作就是特意将预申请后的当前最大id回写到表中。

innodb_concurrency_tickets控制了凭据的数量，凭据是对线程授权。thread进入INNODB中，会获得innodb_concurrency_tickets次数通行证，该线程在接下来的innodb_concurrency_tickets次进入到INNODB中不需要再进行检查，可直接进入。默认吧

innodb_large_prefix。这个参数默认值是OFF。当改为ON时，允许列索引最大达到3072。

看不懂默认把OFF

innodb_lock_wait_timeout：默认50即可

指的是事务等待获取资源等待的最长时间，超过这个时间还未分配到资源则会返回应用失败；参数的时间单位是秒，最小可设置为1s(一般不会设置得这么小)，最大可设置1073741824秒（34年，一条语句锁等待超过30分钟估计业务该有反馈了）

默认安装时这个值是50s(公司的默认参数设置)

innodb_max_dirty_pages_pct，默认75，但我觉得可以少点

这个百分比是，最大脏页的百分数，当系统中 脏页 所占百分比超过这个值，INNODB就会进行写操作以把页中的已更新数据写入到磁盘文件中。

innodb_old_blocks_pct参数可以控制进入缓冲区sublist of old blocks区域的数量，默认是37，占整个缓冲池的比例为3/8。当全表扫描一个大表，或者做MySQLdump时，就可以将innodb_old_blocks_pct设置得小些，例如，设置innodb_old_blocks_pct=5，使数据块进入少量sublist of old blocks区域，并移动到sublist of new blocks区域，从而让更多的热数据不被踢出。当你访问一个小表，或者select查询结果很少时，则可以保持默认的innodb_old_blocks_pct=37，或者设置得更大，比如innodb_old_blocks_pct=50。

读多写少，我就改成5了。

InnoDB_old_blocks_time：默认0 即可

当用户需要访问数据时，InnoDB首先会在InnoDB缓冲池查找数据，如果缓冲池中没有数据时，InnoDB会将硬盘上的数据块插入到InnoDB缓存池中；如果InnoDB缓冲池已满，InnoDB通过LRU算法清楚InnoDB缓存池中个别数据块。每当有新数据块需要加载到InnoDB缓冲池中时，该数据块应变为‘‘数据页’’被插到midpoint的位置，并声明为old数据页。那么old数据页什么时候能移动到new Page链表中呢？

 （1）当InnoDB_old_blocks_time的参数值设置为0时。当old部分的数据页被访问到时，该数据页会被提升到链表的头部，并被标记为new数据页。

 （2）当InnoDB_old_blocks_time的参数值大于0时（以1000毫秒或者1秒为例）。old部分数据页插入缓冲池后，1秒之后被访问，该数据页会被提升到链表的头部，并被标记为new数据页。在刚插入到一秒内，即便old部分的数据页被访问，该数据页也不会移动到new链表的头部。

innodb_open_files：

这个变量只有你在InnoDB中使用多个表空间时是相关的。它指定InnoDB可以在同一时间保持打开.ibd文件的最大数量。最小值是10。默认值是300。

 .ibd文件使用的文件的描述符只用于InnoDB。它们独立于由–open-files-limit服务器选项指定的，且不影响表缓存的操作。

这边我设置的3000，有没有命令可以查看这个参数够不够

innodb_purge_batch_size：

当开启独立线程清除undo页时，表示一次删除多少个页。默认是20，不支持动态修改，一般不需要更改。

Innodb_purge_threads：控制是否使用独立purge线程

Purge操作会克隆最老旧的read_view，这个read_view中持有控制信息以限制哪些由其他事务引起的变化是可见的。然后以相反的方式读取从最老的到最近的undolog记录；如果当前运行的事务都没有引用这些记录，则分析这些记录并从索引上移除被标记删除的记录。

不懂，有没有白话讲解

innodb_read_ahead_threshold参数：默认56即可，效果不大

它控制一个区中多少页被顺序访问时，InnoDB才启用预读取，预读取下一个页中所有的页。

innodb_read_io_threads和Innodb_write_io_threads取代此版本之前参数，该参数值之和=2*cpu个数*cpu核数;如果你的系统读>写,可以设置innodb_read_io_threads值相对大点;反之，也可以.

interactive_timeout和wait_timeout，建议1800，30分钟

interactive_timeout：交互式连接超时时间(mysql工具、mysqldump等)

wait_timeout：非交互式连接超时时间，默认的连接mysql api程序

innodb_rollback_on_timeout

该变量默认值为OFF，如果事务因为加锁超时，会回滚上一条语句执行的操作。如果设置ON，则整个事务都会回滚。

innodb_stats_method（统计有关的参数）

Nulls_equal：所有Null都相等，即算作一个value group；若Null过多则会导致average group size偏大

Nulls_unequal：所有Null互不相同，每个算作一个value group；如果non-null group size过大且null数量过多，此设置会拉低整体的average group size，可能导致滥用索引

Nulls_ignored：忽略Null

看不懂，默认把

innodb_stats_on_metadata，默认关闭即可

对INFORMATION_SCHEMA中的一些表进行查询操作，以方便索引统计信息，如果读要求高的建议关闭。

innodb_stats_sample_pages

INNODB通过抽样的方式来计算统计信息,首先读取少量的索引页面,默认是8个索引页面,新版本可通过innodb_stats_sample_pages来设置样本页的数量。

求详细解释

innodb_strict_mode，默认off即可

开启InnoDB严格检查模式，尤其采用了页数据压缩功能后，最好是开启该功能。开启此功能后，当创建表（CREATE TABLE）、更改表（ALTER TABLE）和创建索引（CREATE INDEX）语句时，如果写法有错误，不会有警告信息，而是直接抛出错误，这样就可直接将问题扼杀在摇篮里。

innodb_table_locks

是否允许使用表级锁。

MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。

MySQL这3种锁的特性可大致归纳如下。

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。

行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。

页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统。这一点在本书的“开发篇”介绍表类型的选择时，也曾提到过。下面几节我们重点介绍MySQL表锁和InnoDB行锁的问题，由于BDB已经被InnoDB取代，即将成为历史，在此就不做进一步的讨论了。

我是K哥

innodb_thread_concurrency：默认0即可

InnoDB试着保持在InnoDB内并发的操作系统线程数量小于或等于这个变量给出的限制。一旦线程的数量达到此限制，其它线程被放入FIFO队列中进入等待执行的状态(additional threads are placed into a wait state within a FIFO queue for execution)。等待锁的线程不计入并发执行的线程数量。

该变量的正确值依赖于环境和负载。尝试一系列不同的值，以确定什么样的值适合您的应用。建议值是2倍的CPU数目加上磁盘的数量。

这个变量的范围是0到1000。值为0（默认）被解释为无限并发（无并发检查）。禁用线程并发检查使InnoDB可以创建它需要的那么多的线程。

innodb_buffer_pool_size(默认128M)

innodb_buffer_pool_size=1024M(1G)

   innodb_buffer_pool_size:主要针对InnoDB表性能影响最大的一个参数。功能与Key_buffer_size一样。InnoDB占用的内存，除innodb_buffer_pool_size用于存储页面缓存数据外，另外正常情况下还有大约8%的开销，主要用在每个缓存页帧的描述、adaptive hash等数据结构，如果不是安全关闭，启动时还要恢复的话，还要另开大约12%的内存用于恢复，两者相加就有差不多21%的开销。假设：12G的innodb_buffer_pool_size，最多的时候InnoDB就可能占用到14.5G的内存。若系统只有16G，而且只运行MySQL，且MySQL只用InnoDB，

那么为MySQL开12G，是最大限度地利用内存了。

另外InnoDB和 MyISAM 存储引擎不同， MyISAM 的 key_buffer_size 只能缓存索引键，而 innodb_buffer_pool_size 却可以缓存数据块和索引键。适当的增加这个参数的大小，可以有效的减少 InnoDB 类型的表的磁盘 I/O 。

当我们操作一个 InnoDB 表的时候，返回的所有数据或者去数据过程中用到的任何一个索引块，都会在这个内存区域中走一遭。

可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率，并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。值可以用以下命令查得：show status like ‘Innodb_buffer_pool_read%‘;

比如查看当前系统中系统中

| Innodb_buffer_pool_read_requests      | 1283826 |

| Innodb_buffer_pool_reads              | 519     |

+---------------------------------------+---------+

其命中率99.959%=（1283826-519）/1283826*100%  命中率越高越好。

innodb_log_buffer_size(默认8M)

innodb_log_buffer_size=20M

    innodb_log_buffer_size  这是InnoDB存储引擎的事务日志所使用的缓冲区。类似于Binlog Buffer，InnoDB在写事务日志的时候，为了提高性能，也是先将信息写入Innofb Log Buffer中，当满足innodb_flush_log_trx_commit参数所设置的相应条件(或者日志缓冲区写满)之后，才会将日志写到文件 (或者同步到磁盘)中。可以通过innodb_log_buffer_size 参数设置其可以使用的最大内存空间。

   InnoDB 将日志写入日志磁盘文件前的缓冲大小。理想值为 1M 至 8M。大的日志缓冲允许事务运行时不需要将日志保存入磁盘而只到事务被提交(commit)。 因此，如果有大的事务处理，设置大的日志缓冲可以减少磁盘I/O。 在 my.cnf中以数字格式设置。

默认是8MB，系的如频繁的系统可适当增大至4MB～8MB。当然如上面介绍所说，这个参数实际上还和另外的flush参数相关。一般来说不建议超过32MB

注：innodb_flush_log_trx_commit参数对InnoDB Log的写入性能有非常关键的影响,默认值为1。该参数可以设置为0，1，2，解释如下：

0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作;

1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步;

2：事务提交会触发log buffer到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。

实际测试发现，该值对插入数据的速度影响非常大，设置为2时插入10000条记录只需要2秒，设置为0时只需要1秒，而设置为1时则需要229秒。因此，MySQL手册也建议尽量将插入操作合并成一个事务，这样可以大幅提高速度。根据MySQL手册，在存在丢失最近部分事务的危险的前提下，可以把该值设为0。

innodb_thread_sleep_delay：默认10000即可

当进入innodb层调用read_row/write_row/update_row/delete_row时，会检查已经进入innodb的线程数：innodb_srv_conc_enter_innodb

如果已经满了，就会等待innodb_thread_sleep_delay毫秒尝试一次

如果再次失败，则进入到一个FIFO队列sleep

interactive_timeout:1800即可30分钟

参数含义：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。

key_buffer_size,本系统目前为384M,可修改为400M

    key_buffer_size=400M

    key_buffer_size是用于索引块的缓冲区大小，增加它可得到更好处理的索引(对所有读和多重写)，对MyISAM(MySQL表存储的一种类型，可以百度等查看详情)表性能影响最大的一个参数。如果你使它太大，系统将开始换页并且真的变慢了。严格说是它决定了数据库索引处理的速度，尤其是索引读的速度。对于内存在4GB左右的服务器该参数可设置为256M或384M.

怎么才能知道key_buffer_size的设置是否合理呢，一般可以检查状态值Key_read_requests和Key_reads   ，比例key_reads / key_read_requests应该尽可能的低，比如1:100，1:1000 ，1:10000。其值可以用以下命令查得：show status like ‘key_read%‘;

比如查看系统当前key_read和key_read_request值为：

+-------------------+-------+

| Variable_name     | Value |

+-------------------+-------+

| Key_read_requests | 28535 |

| Key_reads         | 269   |

+-------------------+-------+

可知道有28535个请求，有269个请求在内存中没有找到直接从硬盘读取索引.

未命中缓存的概率为：0.94%=269/28535*100%.  一般未命中概率在0.1之下比较好。目前已远远大于0.1，证明效果不好。若命中率在0.01以下，则建议适当的修改key_buffer_size值。

http://dbahacker.com/mysql/innodb-myisam-compare(InnoDB与MyISAM的六大区别)

http://kb.cnblogs.com/page/99810/（查看存储引擎介绍）

MyISAM、InnoDB、MyISAM Merge引擎、InnoDB、memory(heap)、archive

key cache下面3个配置不懂，大神解释下，什么热链暖连，根据什么设定？

key_cache_age_threshold：默认300

MyISAM中，如果key_buffer里的热链里的某个缓存块在这个变量所设定的时间里没有被访问过，MySQL服务器就会把它调整到暖链里去。这个参数值越大，缓存块在热链里停留的时间就越长。

key_cache_block_size

MyISAM中key_buffer缓存块的单位长度，以字节为单位，默认值为1024

key_cache_division_limit

控制着缓存块重用算法。默认值为100，此值为key_buffer_size中暖链所占的大小百分比(其中有暖链和热链)，100意味着全是暖链。

log_queries_not_using_indexes：默认关闭即可

如果运行的SQL语句没有使用索引,则mysql数据库同样会将这条SQL语句记录到慢查询日志文件中。

long_query_time

慢查询的阈值。超过多少秒为慢，默认1

loose_rds_max_tmp_disk_space，默认10G足够了

用于控制MySQL能够使用的临时文件的大小，RDS初始默认值是10G，如果临时文件超出此大小，则会导致应用报错

loose_rds_sql_max_affected_rows：默认0

无，请大神帮忙补充

loose_rds_threads_running_high_watermark：默认50000最大即可

用于控制MySQL并发的查询数目，比如将rds_threads_running_high_watermark该值设置为100，则允许MySQL同时进行的并发查询为100个

low_priority_updates：默认0

　　低优先级更新。意思是，所有的写操作(表写锁)，包括update,delete,insert等都需要等待读操作完成后才执行 (表读锁解开)。

　　因为是针对表的锁，所以，这里仅支持MyISAM.

读为主可以设置low_priority_updates=1,写的优先级调低

max_allowed_packet：开到最大就可以了

指mysql服务器端和客户端在一次传送数据包的过程当中最大允许的数据包的大小

查看目前配置show VARIABLES like ‘%max_allowed_packet%‘;

显示的结果为：

| Variable_name      | Value 

| max_allowed_packet | 1048576 |

以上说明目前的配置是：1M

注意：该值设置过小将导致单个记录超过限制后写入数据库失败，且后续记录写入也将失败。

max_connections参数值，

由默认的151，修改为3000（750M）。max_connections=3000

max_connections是指MySql的最大连接数，如果服务器的并发连接请求量比较大，建议调高此值，以增加并行连接数量，当然这建立在机器能支撑的情况下，因为如果连接数越多，介于MySql会为每个连接提供连接缓冲区，就会开销越多的内存，所以要适当调整该值，不能盲目提高设值。

MySQL服务器允许的最大连接数16384；

查看系统当前最大连接数：show variables like ‘max_connections‘;

max_user_connections值由默认的0，修改为800，max_user_connections=800

max_user_connections是指每个数据库用户的最大连接，针对某一个账号的所有客户端并行连接到MYSQL服务的最大并行连接数。

简单说是指同一个账号能够同时连接到mysql服务的最大连接数。

设置为0表示不限制。目前默认值为：0不受限制。

这儿顺便介绍下Max_used_connections:它是指从这次mysql服务启动到现在，同一时刻并行连接数的最大值。它不是指当前的连接情况，而是一个比较值。如果在过去某一个时刻，MYSQL服务同时有1000个请求连接过来，而之后再也没有出现这么大的并发请求时，则Max_used_connections=1000.请注意与show variables 里的max_user_connections的区别。默认为0表示无限大。

查看max_user_connections值show variables like ‘max_user_connections‘;

max_connect_errors：默认：20，改成10

是一个MySQL中与安全有关的计数器值，它负责阻止过多尝试失败的客户端以防止暴力破解密码的情况。max_connect_errors的值与性能并无太大关系。

max_prepared_stmt_count 

参数限制了同一时间在mysqld上所有session中prepared 语句的上限。

它的取值范围为“0 - 1048576”，默认为16382。

mysql对于超出max_prepared_stmt_count的prepare语句就会报Can‘t create more than max_prepared_stmt_count statements (current value: 16382)"错误。

一般而言，默认值应该是足够用的，因为现场的并发其实没有那么的大。一个可能的原因是应用端那边没有关闭prepared的语句。

直连后端MySQLDB执行如下命令

mysql> SHOW GLOBAL STATUS LIKE ‘com_stmt%‘;

查看如下3个参数值：

Com_stmt_close prepare语句关闭的次数

Com_stmt_execute prepare语句执行的次数

Com_stmt_prepare prepare语句创建的次数

通过以下命令修改max_prepared_stmt_count的值（该值可动态修改，也可在配置文件中指定后重启服务生效）

mysql> set global max_prepared_stmt_count=100000;

Query OK, 0 rows affected (0.00 sec)

myisam_sort_buffer_size：

myisam中，每个排序线程分配的缓冲区的大小。增加该值可以加快ORDER BY或GROUP BY操作。默认数值是2097144(2M)，读的多建议加大到 16777208 (16M)。

net_read_timeout：默认30S

在终止读之前，从一个连接获得数据而等待的时间秒数；当服务正在从客户端读取数据时，net_read_timeout控制何时超时。

net_retry_count=10

连接中断，重试10次后放弃，不会再尝试连接服务器。

net_write_timeout，默认60

在终止写之前，等待多少秒把block写到连接；当服务正在写数据到客户端时，net_write_timeout控制何时超时

open_files_limit：默认65535.调到最大就好

指mysql能够打开的文件句柄数。该值不足时，会引发 Too many open files错误。具体需要多少个文件句柄，还需要根据 max_connections 和 table_open_cache来计算。

query_alloc_block_size：默认8192即可

为查询分析和执行过程中创建的对象分配的内存块大小

请大神解释详细点。

query_cache_limit指定单个查询能够使用的缓冲区大小，缺省为1M即可

从4.0.1开始，MySQL提供了查询缓冲机制。使用查询缓冲，MySQL将SELECT语句和查询结果存放在缓冲区中，今后对于同样的 SELECT语句（区分大小写），将直接从缓冲区中读取结果。根据MySQL用户手册，使用查询缓冲最多可以达到238％的效率。

　　通过检查状态值Qcache_*，可以知道query_cache_size设置是否合理（上述状态值可以使用SHOW STATUS LIKE ‘Qcache%’获得）。如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况，如果Qcache_hits的值也非常大，则表明查询缓冲使用非常频繁，此时需要增加缓冲大小；如果Qcache_hits的值不大，则表明你的查询重复率很低，这种情况下使用查询缓冲反而会影响效率，那么可以考虑不用查询缓冲。此外，在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。

query_cache_size的工作原理： 读多写少，开到最大，写多关掉

       一个SELECT查询在DB中工作后，DB会把该语句缓存下来，当同样的一个SQL再次来到DB里调用时，DB在该表没发生变化的情况下把结果从缓存中返回给Client。

   这里有一个关建点，就是DB在利用Query_cache工作时，要求该语句涉及的表在这段时间内没有发生变更。那如果该表在发生变更时，Query_cache里的数据又怎么处理呢？首先要把Query_cache和该表相关的语句全部置为失效，然后在写入更新。那么如果Query_cache非常大，该表的查询结构又比较多，查询语句失效也慢，一个更新或是Insert就会很慢，这样看到的就是Update或是Insert怎么这么慢了。

   所以在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建系把该功能禁掉。

我是K哥

query_cache_type ：默认1

0表示关闭QC；1表示正常缓存；2表示SQL_CACHE才缓存

0 or OFF 不缓存或重新得到结果

1 or ON 缓存所有的结果，除了 SELECT SQL_NO_CACHE ... 查询

2 or DEMAND 仅缓存 SELECT SQL_CACHE ... 查询

query_prealloc_size：默认8192

      用于查询分析和执行的固定缓冲区的大小。在查询之间该缓冲区不释放。如果你执行复杂查询，分配更大的query_prealloc_size值可以帮助提高性能，因为它可以降低查询过程中服务器分配内存的需求。

读多建议大一点。1048576最大

slow_launch_time： 表示如果建立线程花费了比这个值更长的时间,slow_launch_threads 计数器将增加

默认2即可，请大神补充。

sql_mode：当前的服务器SQL模式，可以动态设置。

请大神补充。

Table Cache 参数的演变

      在MySQL 5.1版本中及之后的版本，表缓存分离成两部分：

                一个是打开表的缓存  ---> table_open_cache

                一个是表定义的缓存  ---> table_definition_cache

table_definition_cache[global]

表定义信息缓存是从MySQL5.1.3 版本才开始引入的一个新的缓存区，用来存放表定义信息。当我们的MySQL 中使用了较多的表的时候，此缓存无疑会提高对表定义信息的访问效率。MySQL 提供了table_definition_cache 参数给我们设置可以缓存的表的数量。在MySQL5.1.25 之前的版本中，默认值为128，从MySQL5.1.25 版本开始，则将默认值调整为256 了，最大设置值为524288。注意，这里设置的是可以缓存的表定义信息的数目，而不是内存空间的大小。表定义信息缓存是从MySQL5.1.3 版本才开始引入的一个新的缓存区，用来存放表定义信息。当我们的MySQL 中使用了较多的表的时候，此缓存无疑会提高对表定义信息的访问效率。MySQL 提供了table_definition_cache 参数给我们设置可以缓存的表的数量。在MySQL5.1.25 之前的版本中，默认值为128，从MySQL5.1.25 版本开始，则将默认值调整为256 了，最大设置值为524288。注意，这里设置的是可以缓存的表定义信息的数目，而不是内存空间的大小。

目前不知如何确定这个参数，建议默认，请大神补充

table_open_cache

可以通过查看数据库运行峰值时间的状态值 Open_tables 和 Opened_tables ，判断是否需要增加 table_cache 的值（其中 open_tables 是当前打开的表的数量， Opened_tables 则是已经打开的表的数量）。即如果open_tables接近table_cache的时候，并且Opened_tables这个值在逐步增加，那就要考虑增加这个值的大小了。还有就是Table_locks_waited比较高的时候，也需要增加table_cache。

mysql> show global status like ‘open%_tables‘;

如果Open_tables的值已经接近table_cache的值，且Opened_tables还在不断变大，则说明mysql正在将缓存的表释放以容纳新的表，此时可能需要加大table_cache的值。对于大多数情况，把MySQL数据库放在生产环境中试运行一段时间，然后把参数的值调整得比Open_tables大2倍，并且保证在比较高负载的极端条件下依然比Open_tables略大。

tmp_table_size(默认值：8388608 即：16M) tmp_table_size=16M

tmp_table_size是MySql的heap （堆积）表缓冲大小。所有联合在一个DML指令内完成，并且大多数联合甚至可以不用临时表即可以完成。大多数临时表是基于内

存的(HEAP)表。具有大的记录长度的临时表 (所有列的长度的和)或包含BLOB列的表存储在硬盘上。如果某个内部heap（堆积）表大小超过tmp_table_size，MySQL可以根据需要自动将内存中的heap表改为基于硬盘的MyISAM表。还可以通过设置tmp_table_size选项来增加临时表的大小。也就是说，如果调高该值，MySql同时将增加heap表的大小，可达到提高联接查询速度的效果。

tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小，MySQL产生一个 The table tbl_name is full 形式的错误，如果你做很多高级 GROUP BY 查询，增加 tmp_table_size 值。

transaction_isolation：默认 READ   COMMITTED

READ   COMMITTED

指定在读取数据时控制共享锁以避免脏读，但数据可在事务结束前更改，从而产生不可重复读取或幻像数据。该选项是   SQL   Server   的默认值。

 READ   UNCOMMITTED

执行脏读或0级隔离锁定，这表示不发出共享锁，也不接受排它锁。当设置该选项时，可以对数据执行未提交读或脏读；在事务结束前可以更改数据内的数值，行也可以出现在数据集中或从数据集消失。该选项的作用与在事务内所有语句中的所有表上设置 NOLOCK 相同。这是四个隔离级别中限制最小的级别。

REPEATABLE   READ

锁定查询中使用的所有数据以防止其他用户更新数据，但是其他用户可以将新的幻像行插入数据集，且幻像行包括在当前事务的后续读取中。因为并发低于默认隔离级别，所以应只在必要时才使用该选项。

SERIALIZABLE

 在数据集上放置一个范围锁，以防止其他用户在事务完成之前更新数据集或将行插入数据集内。这是四个隔离级别中限制最大的级别。因为并发级别较低，所以应只在必要时才使用该选项。该选项的作用与在事务内所有   SELECT   语句中的所有表上设置   HOLDLOCK   相同。

wait_timeout参数值

由默认的8小时，修改为30分钟。wait_timeout=1800（单位为妙）

我对wait-timeout这个参数的理解：MySQL客户端的数据库连接闲置最大时间值。

说得比较通俗一点，就是当你的MySQL连接闲置超过一定时间后将会被强行关闭。

MySQL默认的wait-timeout  值为8个小时，可以通过命令show variables like ‘wait_timeout‘查看结果值;。

设置这个值是非常有意义的，比如你的网站有大量的MySQL链接请求（每个MySQL连接都是要内存资源开销的 ），由于你的程序的原因有大量的连接请求空闲啥事也不干，白白占用内存资源，或者导致MySQL超过最大连接数从来无法新建连接导致“Too many connections”的错误。在设置之前你可以查看一下你的MYSQL的状态（可用show processlist)，如果经常发现MYSQL中有大量的Sleep进程，则需要 修改wait-timeout值了。

thread_concurrency值，由目前默认的8，修改为64，thread_concurrency=64

thread_concurrency的值的正确与否, 对mysql的性能影响很大, 在多个cpu(或多核)的情况下，错误设置了thread_concurrency的值, 会导致mysql不能充分利用多cpu(或多核), 出现同一时刻只能一个cpu(或核)在工作的情况。

thread_concurrency应设为CPU核数的2倍. 比如有一个双核的CPU, 那thread_concurrency  的应该为4; 2个双核的cpu, thread_concurrency的值应为8.

比如：根据上面介绍我们目前系统的配置，可知道为4个CPU,每个CPU为8核，按照上面的计算规则，这儿应为:4*8*2=64，

查看系统当前thread_concurrency默认配置命令：show variables like ‘thread_concurrency‘;

query_cache_size(默认32M)

query_cache_size=40M

     query_cache_size: 主要用来缓存MySQL中的ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache功能，MySQL在接受到一条select语句的请求后，如果该语句满足Query Cache的要求(未显式说明不允许使用Query Cache，或者已经显式申明需要使用Query Cache)，MySQL会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，然后到Query Cache中直接查找是否已经缓存。也就是说，如果已经在缓存中，该select请求就会直接将数据返回，从而省略了后面所有的步骤(如SQL语句的解析，优化器优化以及向存储引擎请求数据等)，极大的提高性能。根据MySQL用户手册，使用查询缓冲最多可以达到238%的效率。

当然，Query Cache也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query Cache中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache可能会得不偿失

   Query Cache的使用需要多个参数配合，其中最为关键的是query_cache_size和query_cache_type，前者设置用于缓存 ResultSet的内存大小，后者设置在何场景下使用Query Cache。在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query_cache_size一般256MB是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))来进行调整。 query_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache(使用sql_no_cache)之外的所有的select都使用query cache，只有显示要求才使用query cache(使用sql_cache)。如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲. 如果Qcache_hits的值也非常大，则表明查询缓冲使用非常频繁，此时需要增加缓冲大小；

根据命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))进行调整，一般不建议太大，256MB可能已经差不多了，大型的配置型静态数据可适当调大.

可以通过命令：show status like ‘Qcache_%‘;查看目前系统Query catch使用大小

| Qcache_hits             | 1892463  |

| Qcache_inserts          | 35627  

| Qcache_free_blocks      | 131             |

| Qcache_free_memory      | 99304           |

| Qcache_lowmem_prunes    | 28799           |

| Qcache_not_cached       | 6250            |

| Qcache_queries_in_cache | 475             |

| Qcache_total_blocks     | 1931 

命中率98.17%=1892463/(1892463 +35627 )*100

Qcache_free_blocks:表示查询缓存中目前还有多少剩余的blocks，如果该值显示较大，则说明查询缓存中的内存碎片过多了，可能在一定的时间进行整理。 

减少碎片： 合适的query_cache_min_res_unit可以减少碎片，这个参数最合适的大小和应用程序查询结果的平均大小直接相关，可以通过内存实际消耗（query_cache_size - Qcache_free_memory）除以Qcache_queries_in_cache计算平均缓存大小。 

可以通过Qcache_free_blocks来观察碎片，这个值反应了剩余的空闲块，如果这个值很多，但是

Qcache_lowmem_prunes却不断增加，则说明碎片太多了。可以使用flush query cache整理碎片，重新排序，但不会清空，清空命令是reset query cache。整理碎片期间，查询缓存无法被访问，可能导致服务器僵死一段时间，所以查询缓存不宜太大。 

Qcache_free_memory:查询缓存的内存大小，通过这个参数可以很清晰的知道当前系统的查询内存是否够用，是多了，还是不够用，DBA可以根据实际情况做出调整。 

Qcache_hits:表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大，缓存效果越理想。 

Qcache_inserts: 表示多少次未命中然后插入，意思是新来的SQL请求在缓存中未找到，不得不执行查询处理，执行查询处理后把结果insert到查询缓存中。这样的情况的次 数，次数越多，表示查询缓存应用到的比较少，效果也就不理想。当然系统刚启动后，查询缓存是空的， 这很正常。 

Qcache_lowmem_prunes:该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值，用户可以适当的调整缓存大小。 

Qcache_not_cached: 表示因为query_cache_type的设置而没有被缓存的查询数量。 

Qcache_queries_in_cache:当前缓存中缓存的查询数量。 

Qcache_total_blocks:当前缓存的block数量。

我是K哥

read_buffer_size（默认值：2097144即2M）read_buffer_size=4M

read_buffer_size 是MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。read_buffer_size变量控制这一

缓冲区的大小。如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能.

read_rnd_buffer_size(默认值：8388608即8M)read_rnd_buffer_size=8M

read_rnd_buffer_size 是MySql的随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySql会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。但MySql会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开

销过大。

record_buffer:（默认值：）

  record_buffer每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描，你可能想要增加该值。默认数值是131072(128K)

sort_buffer_size（默认值：2097144即2M）sort_buffer_size=4M

sort_buffer_size是MySql执行排序使用的缓冲大小。如果想要增加ORDER BY的速度，首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能，可以尝试增加sort_buffer_size变量的大小

skip-name-resolve：禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。

但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！

skip-networking建议被注释掉，不要开启，开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！

table_cache(默认值：512)

TABLE_CACHE(5.1.3及以后版本又名TABLE_OPEN_CACHE)

table_cache指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache，并且opened_tables在不断增长，那么你就需要增加table_cache的值了（上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得）。注意，不能盲目地把table_cache设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。

SHOW STATUS LIKE ‘Open%tables‘;

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Open_tables   | 356   |

| Opened_tables | 0     |

+---------------+-------+

2 rows in set (0.00 sec)

open_tables表示当前打开的表缓存数，如果执行flush tables操作，则此系统会关闭一些当前没有使用的表缓存而使得此状态值减小；

opend_tables表示曾经打开的表缓存数，会一直进行累加，如果执行flush tables操作，值不会减小。

在mysql默认安装情况下，table_cache的值在2G内存以下的机器中的值默认时256到512，如果机器有4G内存,则默认这个值 是2048，但这决意味着机器内存越大，这个值应该越大，因为table_cache加大后，使得mysql对SQL响应的速度更快了，不可避免的会产生 更多的死锁（dead lock），这样反而使得数据库整个一套操作慢了下来，严重影响性能。所以平时维护中还是要根据库的实际情况去作出判断，找到最适合你维护的库的 table_cache值。

由于MySQL是多线程的机制,为了提高性能,每个线程都是独自打开自己需要的表的文件描 述符,而不是通过共享已经打开的.针对不同存储引擎处理的方法当然也不一样

在myisam表引擎中,数据文件的描述符 (descriptor)是不共享的,但是索引文件的描述符却是所有线程共享的.Innodb中和使用表空间类型有关,假如是共享表空间那么实际就一个数 据文件,当然占用的数据文件描述符就会比独立表空间少.

mysql手册上给的建议大小 是:table_cache=max_connections*n

n表示查询语句中最大表数, 还需要为临时表和文件保留一些额外的文件描述符。

这个数据遭到很多质疑,table_cache够用就好,检查 Opened_tables值,如果这个值很大,或增长很快那么你就得考虑加大table_cache了.

  table_cache：所有线程打开的表的数目。增大该值可以增加mysqld需要的文件描述符的数量。默认值是64.

thread_cache_size (服务器线程缓存)

thread_cache_size=64

默认的thread_cache_size=8，但是看到好多配置的样例里的值一般是32，64，甚至是128，感觉这个参数对优化应该有帮助，于是查了下：

根据调查发现以上服务器线程缓存thread_cache_size没有进行设置，或者设置过小,这个值表示可以重新利用保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中,如果线程重新被请求，那么请求将从缓存中读取,如果缓存中是空的或者是新的请求，那么这个线程将被重新创建,如果有很多新的线程，增加这个值可以改善系统性能.通过比较 Connections 和 Threads_created 状态的变量，可以看到这个变量的作用。(–>表示要调整的值)   根据物理内存设置规则如下：

1G —> 8

2G —> 16

3G —> 32     >3G —> 64

  mysql> show status like ‘thread%‘;

+——————-+——-+

| Variable_name     | Value |

+——————-+——-+

| Threads_cached    | 0     |  <—当前被缓存的空闲线程的数量

| Threads_connected | 1     |  <—正在使用（处于连接状态）的线程

| Threads_created   | 1498  |  <—服务启动以来，创建了多少个线程

| Threads_running   | 1     |  <—正在忙的线程（正在查询数据，传输数据等等操作）

+——————-+——-+

查看开机起来数据库被连接了多少次？

mysql> show status like ‘%connection%‘;

+———————-+——-+

| Variable_name        | Value |

+———————-+——-+

| Connections          | 1504  |          –>服务启动以来，历史连接数

| Max_used_connections | 2     |

+———————-+——-+

通过连接线程池的命中率来判断设置值是否合适？命中率超过90%以上,设定合理。

 (Connections -  Threads_created) / Connections * 100 %

OK，最后结束了，我是K哥，大家好

MySQL缓存变量介绍及修改

数据库属于IO密集型的应用程序，其主职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个 IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是IO，尽可能将磁盘IO转化为内存IO。本文先从MySQL数据库 IO相关参数(缓存参数)的角度来看看可以通过哪些参数进行IO优化。

全局缓存

启动MySQL时就要分配并且总是存在的全局缓存。目前有：key_buffer_size(默认值：402653184,即384M)、innodb_buffer_pool_size(默认值：134217728即：128M)、innodb_additional_mem_pool_size（默认值：8388608即：8M）、innodb_log_buffer_size(默认值：8388608即：8M)、query_cache_size(默认值：33554432即：32M)等五个。总共：560M.

这些变量值都可以通过命令如：show variables like ‘变量名‘;查看到。

局部缓存

除了全局缓冲，MySql还会为每个连接发放连接缓冲。个连接到MySQL服务器的线程都需要有自己的缓冲。大概需要立刻分配256K，甚至在线程空闲时，它们使用默认的线程堆栈，网络缓存等。事务开始之后，则需要增加更多的空间。运行较小的查询可能仅给指定的线程增加少量的内存消耗，然而如果对数据表做复杂的操作例如扫描、排序或者需要临时表，则需分配大约read_buffer_size，

sort_buffer_size，read_rnd_buffer_size，tmp_table_size 大小的内存空间. 不过它们只是在需要的时候才分配，并且在那些操作做完之后就释放了。有的是立刻分配成单独的组块。tmp_table_size 可能高达MySQL所能分配给这个操作的最大内存空间了

。注意，这里需要考虑的不只有一点——可能会分配多个同一种类型的缓存，例如用来处理子查询。一些特殊的查询的内存使用量可能更大——如果在MyISAM表上做成批的插入

时需要分配 bulk_insert_buffer_size 大小的内存；执行 ALTER TABLE， OPTIMIZE TABLE， REPAIR TABLE 命令时需要分配 myisam_sort_buffer_size 大小的内存。

本文出自 “kevinzhang91” 博客，请务必保留此出处http://kevinzhang91.blog.51cto.com/12012510/1845617

阿里云RDS-MYSQL数据库参数设置，K哥