mariadb 10.1查看per connection内存消耗

在mariadb 10.1版本中，在information_schema.processlist表中，新增了几个字段，其中有一个memory_used，其记录的是连接的内存消耗。

同时新增了一个状态变量memory_used，其记录的应该是所有连接加起来消耗的内存（官方并没有特别详细地解释https://mariadb.com/kb/en/mariadb/show-processlist/），应该类似于oracle pga的概念。

为了再检查下mysql占用内存远超过buffer pool的原因，我们特地让运维将某个线上实例从percona切换到了mariadb 10.1.21进行观察。如下：

[root@iZbp13xgu1d7hpg1gca4ndZ ~]# mysql -uroot -pmysqlWelcome to the MariaDB monitor. Commands end with ; or g.Your MariaDB connection id is 1046786Server version: 10.1.20-MariaDB MariaDB ServerCopyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.Type ‘help;‘ or ‘h‘ for help. Type ‘c‘ to clear the current input statement.MariaDB [(none)]> show status like ‘%memory_used%‘;+---------------+-------+| Variable_name | Value |+---------------+-------+| Memory_used | 67464 |+---------------+-------+1 row in set (0.00 sec)MariaDB [(none)]> show global status like ‘%memory_used%‘;+---------------+-----------+| Variable_name | Value |+---------------+-----------+| Memory_used | 568761128 |+---------------+-----------+1 row in set (0.00 sec)MariaDB [(none)]> select user,host,memory_used from information_schema.processlist;+-----------------+----------------------+-------------+| user | host | memory_used |+-----------------+----------------------+-------------+| root | localhost | 84576 || osm | 10.253.106.167:47847 | 95376 || osm | 10.253.106.167:47843 | 94616 || osm | 10.253.106.167:47845 | 94224 || osm | 10.253.106.167:47841 | 93856 || osm | 10.253.106.167:47835 | 94224 || osm | 10.253.106.167:47836 | 94616 || osm | 10.253.106.167:47831 | 67464 || osm | 10.253.106.167:47832 | 67464 || osm | 10.253.106.167:47815 | 71312 || osm | 10.253.106.167:47791 | 67464 || osm | 10.253.106.167:47792 | 67464 || osm | 10.253.106.167:47780 | 67464 || event_scheduler | localhost | 39784 |+-----------------+----------------------+-------------+14 rows in set (0.00 sec)

在其内存输出中，没有办法得出global memory_used是如何组成的？processlist汇总起来也不是这个值，这确实比较奇怪，官方和各种forum也没找到各种解释。。

该服务器buffer pool配置的是4GB，外有一些临时表在用，当前的进程内存消耗如下：

所以，就算4GB+memory_used也差不多4.55G差不多，和实际的6.4G差距还是蛮大的，看来mysql在这方面还是需要有较大的改进。

mariadb 10.1查看per connection内存消耗

标签：分享   monitor   http   概念   pga   acl   form   for   log   

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

mariadb 如何实现服务器内存使用最大化

查询最高内存占用

使用以下命令可以知道mysql的配置使用多少 RAM

SELECT ( @@key_buffer_size
+ @@query_cache_size
+ @@innodb_buffer_pool_size
+ @@innodb_additional_mem_pool_size
+ @@innodb_log_buffer_size
+ @@max_connections * ( @@read_buffer_size
+ @@read_rnd_buffer_size
+ @@sort_buffer_size
+ @@join_buffer_size
+ @@binlog_cache_size
+ @@thread_stack
+ @@tmp_table_size
)
) / (1024 * 1024 * 1024) AS MAX_MEMORY_GB;

可以使用mysql计算器来计算内存使用

下面是理论，可以直接到推荐配置

如何调整配置

key_buffer_size（MyISAM索引用）

指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。为了最小化磁盘的 I/O ， MyISAM 存储引擎的表使用键高速缓存来缓存索引，这个键高速缓存的大小则通过 key-buffer-size 参数来设置。如果应用系统中使用的表以 MyISAM 存储引擎为主，则应该适当增加该参数的值，以便尽可能的缓存索引，提高访问的速度。

怎么设

show global status like 'key_read%';

+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_read_requests | 27813678764 |
| Key_reads | 6798830 |
---------------------

key_buffer_size通过检查状态值Key_read_requests和Key_reads，可以知道key_buffer_size设置是否合理。

比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好。

show global status like '%created_tmp_disk_tables%';


key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表，但是内部的临时磁盘表是MyISAM表，也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。

对于1G内存的机器，如果不使用MyISAM表，推荐值是16M（8-64M）

另一个参考如下

show global status like 'key_blocks_u%';
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_blocks_unused | 0 |
| Key_blocks_used | 413543 |
+------------------------+-------------+


Key_blocks_unused表示未使用的缓存簇(blocks)数，Key_blocks_used表示曾经用到的最大的blocks数，比如这台服务器，所有的缓存都用到了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置：

可以根据此工式来动态的调整Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

show engines;


查询存储引擎

innodb_buffer_pool_size （innodb索引用）

这个参数和MyISAM的key_buffer_size有相似之处，但也是有差别的。这个参数主要缓存innodb表的索引，数据，插入数据时的缓冲。为Innodb加速优化首要参数。　　

该参数分配内存的原则：这个参数默认分配只有8M，可以说是非常小的一个值。

如果是专用的DB服务器，且以InnoDB引擎为主的场景，通常可设置物理内存的50%，这个参数不能动态更改，所以分配需多考虑。分配过大，会使Swap占用过多，致使Mysql的查询特慢。

如果是非专用DB服务器，可以先尝试设置成内存的1/4，如果有问题再调整

query_cache_size（查询缓存）

缓存机制简单的说就是缓存sql文本及查询结果，如果运行相同的sql，服务器直接从缓存中取到结果，而不需要再去解析和执行sql。如果表更改了，那么使用这个表的所有缓冲查询将不再有效，查询缓存值的相关条目被清空。更改指的是表中任何数据或是结构的改变，包括INSERT、UPDATE、DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改变了的表的使用MERGE表的查询。显然，这对于频繁更新的表，查询缓存是不适合的，而对于一些不常改变数据且有大量相同sql查询的表，查询缓存会节约很大的性能。

注意：如果你查询的表更新比较频繁，而且很少有相同的查询，最好不要使用查询缓存。因为这样会消耗很大的系统性能还没有任何的效果

要不要打开？

先设置成这样跑一段时间

query_cache_size=128M
query_cache_type=1


看看命中结果来进行进一步的判断

mysql> show status like '%Qcache%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| Qcache_free_blocks      | 669       |
| Qcache_free_memory      | 132519160 |
| Qcache_hits             | 1158      |
| Qcache_inserts          | 284824    |
| Qcache_lowmem_prunes    | 2741      |
| Qcache_not_cached       | 1755767   |
| Qcache_queries_in_cache | 579       |
| Qcache_total_blocks     | 1853      |
+-------------------------+-----------+8 rows in set (0.00 sec)


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

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数量。

我们可以看到现网命中1158，未缓存的有1755767次，说明我们这个系统命中的太少了，表变动比较多，不什么开启这个功能涉及参数

query_cache_limit：允许 Cache 的单条 Query 结果集的最大容量，默认是1MB，超过此参数设置的 Query 结果集将不会被 Cache

query_cache_min_res_unit：设置 Query Cache 中每次分配内存的最小空间大小，也就是每个 Query 的 Cache 最小占用的内存空间大小

query_cache_size：设置 Query Cache 所使用的内存大小，默认值为0，大小必须是1024的整数倍，如果不是整数倍，MySQL 会自动调整降低最小量以达到1024的倍数

query_cache_type：控制 Query Cache 功能的开关，可以设置为0(OFF),1(ON)和2(DEMAND)三种，意义分别如下： 0(OFF)：关闭 Query Cache 功能，任何情况下都不会使用 Query Cache 1(ON)：开启 Query Cache 功能，但是当 SELECT 语句中使用的 SQL_NO_CACHE 提示后，将不使用Query Cache 2(DEMAND)：开启 Query Cache 功能，但是只有当 SELECT 语句中使用了 SQL_CACHE 提示后，才使用 Query Cache

query_cache_wlock_invalidate：控制当有写锁定发生在表上的时刻是否先失效该表相关的 Query Cache，如果设置为 1(TRUE)，则在写锁定的同时将失效该表相关的所有 Query Cache，如果设置为0(FALSE)则在锁定时刻仍然允许读取该表相关的 Query Cache。

innodb_additional_mem_pool_size（InnoDB内部目录大小）

InnoDB 字典信息缓存主要用来存放 InnoDB 存储引擎的字典信息以及一些 internal 的共享数据结构信息，也就是存放Innodb的内部目录，所以其大小也与系统中所使用的 InnoDB 存储引擎表的数量有较大关系。

这个值不用分配太大，通常设置16M够用了，默认8M，如果设置的内存大小不够，InnoDB 会自动申请更多的内存，并在 MySQL 的 Error Log 中记录警告信息。

innodb_log_buffer_size （日志缓冲）

表示InnoDB写入到磁盘上的日志文件时使用的缓冲区的字节数，默认值为16M。一个大的日志缓冲区允许大量的事务在提交之前不用写日志到磁盘，所以如果有更新，插入或删除许多行的事务，则使日志缓冲区更大一些可以节省磁盘IO

通常最大设为64M足够

max_connections (最大并发连接)

MySQL的max_connections参数用来设置最大连接（用户）数。每个连接MySQL的用户均算作一个连接，max_connections的默认值为100。

这个参数实际起作用的最大值（实际最大可连接数）为16384，即该参数最大值不能超过16384，即使超过也以16384为准；

增加max_connections参数的值，不会占用太多系统资源。系统资源（CPU、内存）的占用主要取决于查询的密度、效率等；

该参数设置过小的最明显特征是出现”Too many connections”错误

mysql> show variables like '%max_connect%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| extra_max_connections | 1     |
| max_connect_errors    | 100   |
| max_connections       | 2048  |
+-----------------------+-------+3 rows in set (0.00 sec)

mysql> show status like 'Threads%';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| Threads_cached    | 0       |
| Threads_connected | 1       |
| Threads_created   | 9626717 |
| Threads_running   | 1       |
+-------------------+---------+4 rows in set (0.00 sec)


可以看到此时的并发数也就是Threads_connected=1，还远远达不到2048

mysql> show variables like 'open_files_limit';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 65535 |
+------------------+-------+1 row in set (0.00 sec)


max_connections 还取决于操作系统对单进程允许打开最大文件数的*

也就是说如果操作系统*单个进程最大可以打开100个文件

那么 max_connections 设置为200也没什么用

MySQL 的 open_files_limit 参数值是在MySQL启动时记录的操作系统对单进程打开最大文件数*的值

可以使用 show variables like 'open_files_limit'; 查看 open_files_limit 值

ulimit -n65535


或者直接在 Linux 下通过ulimit -n命令查看操作系统对单进程打开最大文件数* ( 默认为1024 )

connection级内存参数(线程独享)

connection级参数，是在每个connection第一次需要使用这个buffer的时候，一次性分配设置的内存。

排序性能

mysql对于排序,使用了两个变量来控制sort_buffer_size和 max_length_for_sort_data, 不象oracle使用SGA控制. 这种方式的缺点是要单独控制,容易出现排序性能问题.

mysql> SHOW GLOBAL STATUS like '%sort%';
+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| Sort_merge_passes         | 0      |
| Sort_priority_queue_sorts | 1409   |
| Sort_range                | 0      |
| Sort_rows                 | 843479 |
| Sort_scan                 | 13053  |
+---------------------------+--------+5 rows in set (0.00 sec)


如果发现Sort_merge_passes的值比较大，你可以考虑增加sort_buffer_size 来加速ORDER BY 或者GROUP BY 操作,不能通过查询或者索引优化的。我们这为0，那就没必要设置那么大。

读取缓存

read_buffer_size = 128K(默认128K)为需要全表扫描的MYISAM数据表线程指定缓存

read_rnd_buffer_size = 4M：(默认256K)首先，该变量可以被任何存储引擎使用，当从一个已经排序的键值表中读取行时，会先从该缓冲区中获取而不再从磁盘上获取。

大事务binlog

mysql> show global status like 'binlog_cache%';
+-----------------------+----------+
| Variable_name         | Value    |
+-----------------------+----------+
| Binlog_cache_disk_use | 220840   |
| Binlog_cache_use      | 67604667 |
+-----------------------+----------+2 rows in set (0.00 sec)


Binlog_cache_disk_use表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数

Binlog_cache_use 表示 用binlog_cache_size缓存的次数

当对应的Binlog_cache_disk_use 值比较大的时候 我们可以考虑适当的调高 binlog_cache_size 对应的值

如上图，现网是32K，我们加到64K

join语句内存影响

如果应用中，很少出现join语句，则可以不用太在乎join_buffer_size参数的设置大小。

如果join语句不是很少的话，个人建议可以适当增大join_buffer_size到1MB左右，如果内存充足可以设置为2MB。

线程内存影响

Thread_stack：每个连接线程被创建时，MySQL给它分配的内存大小。当MySQL创建一个新的连接线程时，需要给它分配一定大小的内存堆栈空间，以便存放客户端的请求的Query及自身的各种状态和处理信息。

mysql> show status like '%threads%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Delayed_insert_threads  | 0       |
| Slow_launch_threads     | 0       |
| Threadpool_idle_threads | 0       |
| Threadpool_threads      | 0       |
| Threads_cached          | 0       |
| Threads_connected       | 1       |
| Threads_created         | 9649301 |
| Threads_running         | 1       |
+-------------------------+---------+8 rows in set (0.00 sec)

mysql> show status like 'connections';
+---------------+---------+
| Variable_name | Value   |
+---------------+---------+
| Connections   | 9649311 |
+---------------+---------+1 row in set (0.00 sec)


如上：系统启动到现在共接受到客户端的连接9649311次，共创建了9649301个连接线程，当前有1个连接线程处于和客户端连接的状态。而在Thread Cache池*缓存了0个连接线程(Threads_cached)。

Thread Cache 命中率：

Thread_Cache_Hit = (Connections - Threads_created) / Connections * 100%;


一般在系统稳定运行一段时间后，Thread Cache命中率应该保持在90%左右才算正常。

内存临时表

tmp_table_size 控制内存临时表的最大值,超过限值后就往硬盘写，写的位置由变量 tmpdir 决定

max_heap_table_size 用户可以创建的内存表(memory table)的大小.这个值用来计算内存表的最大行数值。

Order By 或者Group By操作多的话，加大这两个值，默认16M

mysql> show status like 'Created_tmp_%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0     |
| Created_tmp_files       | 626   |
| Created_tmp_tables      | 3     |
+-------------------------+-------+3 rows in set (0.00 sec)


如上图，写入硬盘的为0，3次中间表，说明我们的默认值足够用了

mariadb 推荐配置

注意这里只推荐innodb引擎

内存配置只关注有注释的行

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sockdefault-storage-engine=INNODB

character-set-server=utf8
collation-server=utf8_general_ci

user=mysql
symbolic-links=0# global settings
table_cache=65535table_definition_cache=65535max_allowed_packet=4M
net_buffer_length=1M
bulk_insert_buffer_size=16M

query_cache_type=0              #是否使用查询缓冲,0关闭
query_cache_size=0              #0关闭，因为改表操作多，命中低，开启消耗cpu

# shared
key_buffer_size=8M              #保持8M MyISAM索引用
innodb_buffer_pool_size=4G              #DB专用mem*50%，非DB专用mem*15%到25%
myisam_sort_buffer_size=32M
max_heap_table_size=16M             #最大中间表大小
tmp_table_size=16M              #中间表大小

# per-thread
sort_buffer_size=256K               #加速排序缓存大小
read_buffer_size=128k               #为需要全表扫描的MYISAM数据表线程指定缓存
read_rnd_buffer_size=4M             #已排序的表读取时缓存，如果比较大内存就到6M
join_buffer_size=1M             #join语句多时加大，1-2M
thread_stack=256k               #线程空间，256K or 512K
binlog_cache_size=64K               #大事务binlog


# big-tables
innodb_file_per_table = 1skip-external-locking
max_connections=2048                #最大连接数
skip-name-resolve

# slow_query_log
slow_query_log_file = /var/log/mysql-slow.log
long_query_time = 30group_concat_max_len=65536# according to tuning-primer.sh
thread_cache_size = 8thread_concurrency = 16# set variables
concurrent_insert=2


运行时修改

使用以下命令来修改变量

set global {要改的key} = {值}; （立即生效重启后失效）
set @@{要改的key} = {值}; （立即生效重启后失效）
set @@global.{要改的key} = {值}; （立即生效重启后失效）


试验

mysql> set @@global.innodb_buffer_pool_size=4294967296;
ERROR 1238 (HY000): Variable 'innodb_buffer_pool_size' is a read only variable
mysql> set @@global.thread_stack=262144;
ERROR 1238 (HY000): Variable 'thread_stack' is a read only variable
mysql> set @@global.binlog_cache_size=65536;
Query OK, 0 rows affected (0.00 sec)
mysql> set @@join_buffer_size=1048576;
Query OK, 0 rows affected (0.00 sec)
mysql> set @@read_rnd_buffer_size=4194304;
Query OK, 0 rows affected (0.00 sec)
mysql> set @@sort_buffer_size=262144;
Query OK, 0 rows affected (0.00 sec)
mysql> set @@read_buffer_size=131072;
Query OK, 0 rows affected (0.00 sec)
mysql> set global key_buffer_size=8388608;
Query OK, 0 rows affected (0.39 sec)


我们可以看到innodb_buffer_pool_size和thread_stack报错了，他们只能改配置文件，在运行时是只读的。 以下直接复制使用

set @@global.binlog_cache_size=65536;
set @@join_buffer_size=1048576;
set @@read_rnd_buffer_size=4194304;
set @@sort_buffer_size=262144;
set @@read_buffer_size=131072;
set global key_buffer_size=8388608;

mariadb 如何实现服务器内存使用最大化

查询最高内存占用

使用以下命令可以知道mysql的配置使用多少 RAM

SELECT ( @@key_buffer_size
+ @@query_cache_size
+ @@innodb_buffer_pool_size
+ @@innodb_additional_mem_pool_size
+ @@innodb_log_buffer_size
+ @@max_connections * ( @@read_buffer_size
+ @@read_rnd_buffer_size
+ @@sort_buffer_size
+ @@join_buffer_size
+ @@binlog_cache_size
+ @@thread_stack
+ @@tmp_table_size
)
) / (1024 * 1024 * 1024) AS MAX_MEMORY_GB;

可以使用mysql计算器来计算内存使用

下面是理论，可以直接到推荐配置

如何调整配置

key_buffer_size（MyISAM索引用）

指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。为了最小化磁盘的 I/O ， MyISAM 存储引擎的表使用键高速缓存来缓存索引，这个键高速缓存的大小则通过 key-buffer-size 参数来设置。如果应用系统中使用的表以 MyISAM 存储引擎为主，则应该适当增加该参数的值，以便尽可能的缓存索引，提高访问的速度。

怎么设

show global status like 'key_read%';

+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_read_requests | 27813678764 |
| Key_reads | 6798830 |
---------------------

key_buffer_size通过检查状态值Key_read_requests和Key_reads，可以知道key_buffer_size设置是否合理。

比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好。

show global status like '%created_tmp_disk_tables%';


key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表，但是内部的临时磁盘表是MyISAM表，也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。

对于1G内存的机器，如果不使用MyISAM表，推荐值是16M（8-64M）

另一个参考如下

show global status like 'key_blocks_u%';
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_blocks_unused | 0 |
| Key_blocks_used | 413543 |
+------------------------+-------------+


Key_blocks_unused表示未使用的缓存簇(blocks)数，Key_blocks_used表示曾经用到的最大的blocks数，比如这台服务器，所有的缓存都用到了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置：

可以根据此工式来动态的调整Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

show engines;


查询存储引擎

innodb_buffer_pool_size （innodb索引用）

这个参数和MyISAM的key_buffer_size有相似之处，但也是有差别的。这个参数主要缓存innodb表的索引，数据，插入数据时的缓冲。为Innodb加速优化首要参数。　　

该参数分配内存的原则：这个参数默认分配只有8M，可以说是非常小的一个值。

如果是专用的DB服务器，且以InnoDB引擎为主的场景，通常可设置物理内存的50%，这个参数不能动态更改，所以分配需多考虑。分配过大，会使Swap占用过多，致使Mysql的查询特慢。

如果是非专用DB服务器，可以先尝试设置成内存的1/4，如果有问题再调整

query_cache_size（查询缓存）

缓存机制简单的说就是缓存sql文本及查询结果，如果运行相同的sql，服务器直接从缓存中取到结果，而不需要再去解析和执行sql。如果表更改了，那么使用这个表的所有缓冲查询将不再有效，查询缓存值的相关条目被清空。更改指的是表中任何数据或是结构的改变，包括INSERT、UPDATE、DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改变了的表的使用MERGE表的查询。显然，这对于频繁更新的表，查询缓存是不适合的，而对于一些不常改变数据且有大量相同sql查询的表，查询缓存会节约很大的性能。

注意：如果你查询的表更新比较频繁，而且很少有相同的查询，最好不要使用查询缓存。因为这样会消耗很大的系统性能还没有任何的效果

要不要打开？

先设置成这样跑一段时间

query_cache_size=128M
query_cache_type=1


看看命中结果来进行进一步的判断

mysql> show status like '%Qcache%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| Qcache_free_blocks      | 669       |
| Qcache_free_memory      | 132519160 |
| Qcache_hits             | 1158      |
| Qcache_inserts          | 284824    |
| Qcache_lowmem_prunes    | 2741      |
| Qcache_not_cached       | 1755767   |
| Qcache_queries_in_cache | 579       |
| Qcache_total_blocks     | 1853      |
+-------------------------+-----------+8 rows in set (0.00 sec)


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

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数量。

我们可以看到现网命中1158，未缓存的有1755767次，说明我们这个系统命中的太少了，表变动比较多，不什么开启这个功能涉及参数

query_cache_limit：允许 Cache 的单条 Query 结果集的最大容量，默认是1MB，超过此参数设置的 Query 结果集将不会被 Cache

query_cache_min_res_unit：设置 Query Cache 中每次分配内存的最小空间大小，也就是每个 Query 的 Cache 最小占用的内存空间大小

query_cache_size：设置 Query Cache 所使用的内存大小，默认值为0，大小必须是1024的整数倍，如果不是整数倍，MySQL 会自动调整降低最小量以达到1024的倍数

query_cache_type：控制 Query Cache 功能的开关，可以设置为0(OFF),1(ON)和2(DEMAND)三种，意义分别如下： 0(OFF)：关闭 Query Cache 功能，任何情况下都不会使用 Query Cache 1(ON)：开启 Query Cache 功能，但是当 SELECT 语句中使用的 SQL_NO_CACHE 提示后，将不使用Query Cache 2(DEMAND)：开启 Query Cache 功能，但是只有当 SELECT 语句中使用了 SQL_CACHE 提示后，才使用 Query Cache

query_cache_wlock_invalidate：控制当有写锁定发生在表上的时刻是否先失效该表相关的 Query Cache，如果设置为 1(TRUE)，则在写锁定的同时将失效该表相关的所有 Query Cache，如果设置为0(FALSE)则在锁定时刻仍然允许读取该表相关的 Query Cache。

innodb_additional_mem_pool_size（InnoDB内部目录大小）

InnoDB 字典信息缓存主要用来存放 InnoDB 存储引擎的字典信息以及一些 internal 的共享数据结构信息，也就是存放Innodb的内部目录，所以其大小也与系统中所使用的 InnoDB 存储引擎表的数量有较大关系。

这个值不用分配太大，通常设置16M够用了，默认8M，如果设置的内存大小不够，InnoDB 会自动申请更多的内存，并在 MySQL 的 Error Log 中记录警告信息。

innodb_log_buffer_size （日志缓冲）

表示InnoDB写入到磁盘上的日志文件时使用的缓冲区的字节数，默认值为16M。一个大的日志缓冲区允许大量的事务在提交之前不用写日志到磁盘，所以如果有更新，插入或删除许多行的事务，则使日志缓冲区更大一些可以节省磁盘IO

通常最大设为64M足够

max_connections (最大并发连接)

MySQL的max_connections参数用来设置最大连接（用户）数。每个连接MySQL的用户均算作一个连接，max_connections的默认值为100。

这个参数实际起作用的最大值（实际最大可连接数）为16384，即该参数最大值不能超过16384，即使超过也以16384为准；

增加max_connections参数的值，不会占用太多系统资源。系统资源（CPU、内存）的占用主要取决于查询的密度、效率等；

该参数设置过小的最明显特征是出现”Too many connections”错误

mysql> show variables like '%max_connect%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| extra_max_connections | 1     |
| max_connect_errors    | 100   |
| max_connections       | 2048  |
+-----------------------+-------+3 rows in set (0.00 sec)

mysql> show status like 'Threads%';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| Threads_cached    | 0       |
| Threads_connected | 1       |
| Threads_created   | 9626717 |
| Threads_running   | 1       |
+-------------------+---------+4 rows in set (0.00 sec)


可以看到此时的并发数也就是Threads_connected=1，还远远达不到2048

mysql> show variables like 'open_files_limit';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 65535 |
+------------------+-------+1 row in set (0.00 sec)


max_connections 还取决于操作系统对单进程允许打开最大文件数的*

也就是说如果操作系统*单个进程最大可以打开100个文件

那么 max_connections 设置为200也没什么用

MySQL 的 open_files_limit 参数值是在MySQL启动时记录的操作系统对单进程打开最大文件数*的值

可以使用 show variables like 'open_files_limit'; 查看 open_files_limit 值

ulimit -n65535


或者直接在 Linux 下通过ulimit -n命令查看操作系统对单进程打开最大文件数* ( 默认为1024 )

connection级内存参数(线程独享)

connection级参数，是在每个connection第一次需要使用这个buffer的时候，一次性分配设置的内存。

排序性能

mysql对于排序,使用了两个变量来控制sort_buffer_size和 max_length_for_sort_data, 不象oracle使用SGA控制. 这种方式的缺点是要单独控制,容易出现排序性能问题.

mysql> SHOW GLOBAL STATUS like '%sort%';
+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| Sort_merge_passes         | 0      |
| Sort_priority_queue_sorts | 1409   |
| Sort_range                | 0      |
| Sort_rows                 | 843479 |
| Sort_scan                 | 13053  |
+---------------------------+--------+5 rows in set (0.00 sec)


如果发现Sort_merge_passes的值比较大，你可以考虑增加sort_buffer_size 来加速ORDER BY 或者GROUP BY 操作,不能通过查询或者索引优化的。我们这为0，那就没必要设置那么大。

读取缓存

read_buffer_size = 128K(默认128K)为需要全表扫描的MYISAM数据表线程指定缓存

read_rnd_buffer_size = 4M：(默认256K)首先，该变量可以被任何存储引擎使用，当从一个已经排序的键值表中读取行时，会先从该缓冲区中获取而不再从磁盘上获取。

大事务binlog

mysql> show global status like 'binlog_cache%';
+-----------------------+----------+
| Variable_name         | Value    |
+-----------------------+----------+
| Binlog_cache_disk_use | 220840   |
| Binlog_cache_use      | 67604667 |
+-----------------------+----------+2 rows in set (0.00 sec)


Binlog_cache_disk_use表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数

Binlog_cache_use 表示 用binlog_cache_size缓存的次数

当对应的Binlog_cache_disk_use 值比较大的时候 我们可以考虑适当的调高 binlog_cache_size 对应的值

如上图，现网是32K，我们加到64K

join语句内存影响

如果应用中，很少出现join语句，则可以不用太在乎join_buffer_size参数的设置大小。

如果join语句不是很少的话，个人建议可以适当增大join_buffer_size到1MB左右，如果内存充足可以设置为2MB。

线程内存影响

Thread_stack：每个连接线程被创建时，MySQL给它分配的内存大小。当MySQL创建一个新的连接线程时，需要给它分配一定大小的内存堆栈空间，以便存放客户端的请求的Query及自身的各种状态和处理信息。

mysql> show status like '%threads%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Delayed_insert_threads  | 0       |
| Slow_launch_threads     | 0       |
| Threadpool_idle_threads | 0       |
| Threadpool_threads      | 0       |
| Threads_cached          | 0       |
| Threads_connected       | 1       |
| Threads_created         | 9649301 |
| Threads_running         | 1       |
+-------------------------+---------+8 rows in set (0.00 sec)

mysql> show status like 'connections';
+---------------+---------+
| Variable_name | Value   |
+---------------+---------+
| Connections   | 9649311 |
+---------------+---------+1 row in set (0.00 sec)


如上：系统启动到现在共接受到客户端的连接9649311次，共创建了9649301个连接线程，当前有1个连接线程处于和客户端连接的状态。而在Thread Cache池*缓存了0个连接线程(Threads_cached)。

Thread Cache 命中率：

Thread_Cache_Hit = (Connections - Threads_created) / Connections * 100%;


一般在系统稳定运行一段时间后，Thread Cache命中率应该保持在90%左右才算正常。

内存临时表

tmp_table_size 控制内存临时表的最大值,超过限值后就往硬盘写，写的位置由变量 tmpdir 决定

max_heap_table_size 用户可以创建的内存表(memory table)的大小.这个值用来计算内存表的最大行数值。

Order By 或者Group By操作多的话，加大这两个值，默认16M

mysql> show status like 'Created_tmp_%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0     |
| Created_tmp_files       | 626   |
| Created_tmp_tables      | 3     |
+-------------------------+-------+3 rows in set (0.00 sec)


如上图，写入硬盘的为0，3次中间表，说明我们的默认值足够用了

mariadb 推荐配置

注意这里只推荐innodb引擎

内存配置只关注有注释的行

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sockdefault-storage-engine=INNODB

character-set-server=utf8
collation-server=utf8_general_ci

user=mysql
symbolic-links=0# global settings
table_cache=65535table_definition_cache=65535max_allowed_packet=4M
net_buffer_length=1M
bulk_insert_buffer_size=16M

query_cache_type=0              #是否使用查询缓冲,0关闭
query_cache_size=0              #0关闭，因为改表操作多，命中低，开启消耗cpu

# shared
key_buffer_size=8M              #保持8M MyISAM索引用
innodb_buffer_pool_size=4G              #DB专用mem*50%，非DB专用mem*15%到25%
myisam_sort_buffer_size=32M
max_heap_table_size=16M             #最大中间表大小
tmp_table_size=16M              #中间表大小

# per-thread
sort_buffer_size=256K               #加速排序缓存大小
read_buffer_size=128k               #为需要全表扫描的MYISAM数据表线程指定缓存
read_rnd_buffer_size=4M             #已排序的表读取时缓存，如果比较大内存就到6M
join_buffer_size=1M             #join语句多时加大，1-2M
thread_stack=256k               #线程空间，256K or 512K
binlog_cache_size=64K               #大事务binlog


# big-tables
innodb_file_per_table = 1skip-external-locking
max_connections=2048                #最大连接数
skip-name-resolve

# slow_query_log
slow_query_log_file = /var/log/mysql-slow.log
long_query_time = 30group_concat_max_len=65536# according to tuning-primer.sh
thread_cache_size = 8thread_concurrency = 16# set variables
concurrent_insert=2


运行时修改

使用以下命令来修改变量

set global {要改的key} = {值}; （立即生效重启后失效）
set @@{要改的key} = {值}; （立即生效重启后失效）
set @@global.{要改的key} = {值}; （立即生效重启后失效）


试验

mysql> set @@global.innodb_buffer_pool_size=4294967296;
ERROR 1238 (HY000): Variable 'innodb_buffer_pool_size' is a read only variable
mysql> set @@global.thread_stack=262144;
ERROR 1238 (HY000): Variable 'thread_stack' is a read only variable
mysql> set @@global.binlog_cache_size=65536;
Query OK, 0 rows affected (0.00 sec)
mysql> set @@join_buffer_size=1048576;
Query OK, 0 rows affected (0.00 sec)
mysql> set @@read_rnd_buffer_size=4194304;
Query OK, 0 rows affected (0.00 sec)
mysql> set @@sort_buffer_size=262144;
Query OK, 0 rows affected (0.00 sec)
mysql> set @@read_buffer_size=131072;
Query OK, 0 rows affected (0.00 sec)
mysql> set global key_buffer_size=8388608;
Query OK, 0 rows affected (0.39 sec)


我们可以看到innodb_buffer_pool_size和thread_stack报错了，他们只能改配置文件，在运行时是只读的。 以下直接复制使用

set @@global.binlog_cache_size=65536;
set @@join_buffer_size=1048576;
set @@read_rnd_buffer_size=4194304;
set @@sort_buffer_size=262144;
set @@read_buffer_size=131072;
set global key_buffer_size=8388608;

优化mysql 多大内存 centos6

一、mysql的优化思路

mysql的优化分为两方面：

1. 服务器使用前的优化

2. 服务使用中的优化

二、mysql的基础优化步骤

1. 硬件级优化

（1）. 最好mysql自己使用一台物理服务器

（2）. 内存和CPU方面，根据需求给予mysql服务器足够大的内存和足够多的CPU核数

(3). 避免使用Swap交换分区–交换时从硬盘读取的它的速度很慢，有的DBA安装系统时就不装swap分区

（4）. 如果是mysql主库，硬盘可以选用比较好的高速硬盘，系统用SSD固态硬盘，数据盘用sas替代sata硬盘，将操作系统和数据分区分开

（5）. mysql产生的日志与数据库也放到不同的磁盘分区上面

（6）. mysql数据库硬盘格式化时，可以指定更小的硬盘块

（7）. 关于做RAID方面，主库尽量做成RAID10，既提高了数据的读写速度也提到了数据的安全性

（8). 服务器双线双电，保障服务器运行稳定，不会因为突然断电影响业务和损坏磁盘数据

2. mysql数据库设计优化

（1). 根据需求选择正确的存储引擎，比如说读的特别猛就用MySAM,如果对事务性要求高就用InnoDB

(2). 设置合理的字段类型和字段长度,比如说你这个字段就20多个字段你设置成VARCHAR(255)就是对磁盘空间的浪费

（3）. 默认值尽可能的使用 NOT NULL，如果空值太多对mysql的查询会有影响，尤其是在查询语句编写上面

（4）. 尽量少的使用VARCHAR，TEXT，BLOB这三个字段

（5）. 添加适当索引(index) [四种: 普通索引、主键索引、唯一索引unique、全文索引]

（6）. 不要滥用索引，大表索引，小表不索引

（7）. 表的设计合理化(符合3NF)

3. mysql配置参数的优化

这里是mysql5.5版本的配置文件

vi my.cnf

[client]

port = 3306 #mysql客户端连接时的默认端口

socket = /tmp/mysql.sock #与mysql服务器本地通信所使用的socket文件路径

default-character-set = utf8 #指定默认字符集为utf8

[mysql]

no-auto-rehash #auto-rehash是自动补全的意思，就像我们在linux命令行里输入命令的时候，使用tab键的功能是一样的，这里是默认的不自动补全

default-character-set = utf8 #指定默认字符集为utf8

[mysqld]

user = mysql

port = 3306

character-set-server = utf8 #设置服务器端的字符编码

socket = /tmp/mysql.sock

basedir = /application/mysql

datadir = /mysqldata

skip-locking #避免MySQL的外部锁定，减少出错几率增强稳定性。

open_files_limit = 10240 #MySQL打开的文件描述符，默认最小1024;当open_files_limit没有被配置的时候，比较max_connections*5和ulimit -n的值，哪个大用哪个，当open_file_limit被配置的时候，比较open_files_limit和max_connections*5的值，哪个大用哪个。

back_log = 500 #back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可 以被存在堆栈中。 如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自 己的。 试图设back_log高于你的操作系统的将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。

max_connections = 800 #MySQL的最大连接数，如果服务器的并发连接请求量比较大，建议调高此值，以增加并行连接数量，当然这建立在机器能支撑的情况下，因为如果连接数越多， 介于MySQL会为每个连接提供连接缓冲区，就会开销越多的内存，所以要适当调整该值，不能盲目提高设值。可以过’conn%’通配符查看当前状态的连接 数量，以定夺该值的大小。

max_connect_errors = 3000 #对于同一主机，如果有超出该参数值个数的中断错误连接，则该主机将被禁止连接。如需对该主机进行解禁，执行：FLUSH HOST。

table_cache = 614 #物理内存越大,设置就越大.默认为2402,调到512-1024最佳

external-locking = FALSE #使用–skip-external-locking MySQL选项以避免外部锁定。该选项默认开启

max_allowed_packet =8M #设置最大包,server接受的数据包大小，避免超长SQL的执行有问题 默认值为16M，当MySQL客户端或mysqld服务器收到大于max_allowed_packet字节的信息包时，将发出“信息包过大”错误，并关闭连接。对于某些客户端，如果通信信息包过大，在执行查询期间，可能会遇“丢失与MySQL服务器的连接”错误。默认值16M。

sort_buffer_size = 6M #用于表间关联缓存的大小，查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。

join_buffer_size = 6M #联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。

thread_cache_size = 100 #服务器线程缓存这个值表示可以重新利用保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中,如果线程重新被请求， 那么请求将从缓存中读取,如果缓存中是空的或者是新的请求，那么这个线程将被重新创建,如果有很多新的线程，增加这个值可以改善系统性能.通过比较 Connections 和 Threads_created 状态的变量，可以看到这个变量的作用

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，属重点优化参数

query_cache_size = 2M #指定MySQL查询缓冲区的大小，在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建系把该功能禁掉。

query_cache_limit = 1M #默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费

query_cache_min_res_unit = 2k #MySQL参数中query_cache_min_res_unit查询缓存中的块是以这个大小进行分配的，使用下面的公式计算查询缓存的平均大小，根据计算结果设置这个变量，MySQL就会更有效地使用查询缓存，缓存更多的查询，减少内存的浪费。

default_table_type = InnoDB #默认表的引擎为InnoDB

thread_stack = 192K #限定用于每个数据库线程的栈大小。默认设置足以满足大多数应用transaction_isolation = READ-COMMITTED #设定默认的事务隔离级别.可用的级别如下:

READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE,1.READ UNCOMMITTED-读未提交2.READ COMMITTE-读已提交3.REPEATABLE READ -可重复读4.SERIALIZABLE -串行

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

max_heap_table_size = 246M #内存表，内存表不支持事务，内存表使用哈希散列索引把数据保存在内存中，因此具有极快的速度，适合缓存中小型数据库，但是使用上受到一些

long_query_time = 1 #记录时间超过1秒的查询语句

log_long_format #

log-error = /logs/error.log #开启mysql错误日志，该选项指定mysqld保存错误日志文件的位置

log-slow-queries = /logs/slow.log #慢查询日志文件路径

pid-file = /pids/mysql.pid

log-bin = /binlog/mysql-bin #binlog日志位置以及binlog的名称

relay-log = /relaylog/relay-bin #relaylog日志位置以名称

binlog_cache_size = 1M #binlog_cache_size 就是满足两点的：一个事务，在没有提交（uncommitted）的时候，产生的日志，记录到Cache中；等到事务提交（committed）需要提交的时候，则把日志持久化到磁盘，默认是32K。

max_binlog_cache_size = 32M #binlog缓存最大使用的内存

max_binlog_size = 2M #一个binlog日志的大小

expire_logs_days = 7 #保留7天的binlog

key_buffer_size = 124M #索引缓存大小: 它决定了数据库索引处理的速度，尤其是索引读的速度

read_buffer_size = 16M #MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能

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

bulk_insert_buffer_size = 1M #批量插入数据缓存大小，可以有效提高插入效率，默认为8M

myisam_sort_buffer_size = 1M #MyISAM表发生变化时重新排序所需的缓冲

myisam_max_sort_file_size = 10G #MySQL重建索引时所允许的最大临时文件的大小 (当 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE). 如果文件大小比此值更大,索引会通过键值缓冲创建(更慢)

myisam_repair_threads = 1 #如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复他们.这对于拥有多个CPU以及大量内存情况的用户,是一个很好的选择.

myisam_recover #自动检查和修复没有适当关闭的 MyISAM 表

lower_case_table_names = 1 #让mysql不区分大小写

skip-name-resolve #禁用DNS解析，连接速度会快很多。不过，这样的话就不能在MySQL的授权表中使用主机名了而只能用ip格式。

#slave-skip-errors = 1032,1062 #这是选填项让slave库跳过哪些错误继续同步

#replicate-ignore-db=mysql #选填，同步时候哪个数据库不同步设置

server-id = 1

innodb_additional_mem_pool_size = 4M #InnoDB 存储的数据目录信息和其它内部数据结构的内存池大小。应用程序里的表越多，你需要在这里分配越多的内存，默认是2M

innodb_buffer_pool_size = 2048M #这对Innodb表来说非常重要。Innodb相比MyISAM表对缓冲更为敏感。MyISAM可以在默 认的 key_buffer_size 设置下运行的可以，然而Innodb在默认的 设置下却跟蜗牛似的。由于Innodb把数据和索引都缓存起来，无需留给操作系统太多的内存，因此如果只需要用Innodb的话则可以设置它高达 70-80% 的可用内存。一些应用于 key_buffer 的规则有 — 如果你的数据量不大，并且不会暴增，那么无需把 innodb_buffer_pool_size 设置的太大了

innodb_file_io_threads = 4 #文件IO的线程数，一般为 4

innodb_thread_concurrency = 8 #你的服务器CPU有几个就设置为几,建议用默认一般为8

innodb_flush_log_at_trx_commit = 2 #默认为1，如果将此参数设置为1，将在每次提交事务后将日志写入磁盘。为提供性能，可以设置为0或2，但要承担在发生故障时丢失数据的风险。设置为0表示事务日志写入日志文件，而日志文件每秒刷新到磁盘一次。设置为2表示事务日志将在提交时写入日志，但日志文件每次刷新到磁盘一次。

innodb_log_buffer_size = 2M #此参数确定些日志文件所用的内存大小，以M为单位。缓冲区更大能提高性能，但意外的故障将会丢失数据.MySQL开发人员建议设置为1－8M之间

innodb_log_file_size = 4M #此参数确定数据日志文件的大小，以M为单位，更大的设置可以提高性能，但也会增加恢复故障数据库所需的时间

innodb_log_files_in_group = 3 #为提高性能，MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3M

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之前先调小，强制数据块Flush一段时间，则能够大大缩短MySQL关闭的时间。

innodb_lock_wait_timeout = 120 #InnoDB 有其内置的死锁检测机制，能导致未完成的事务回滚。但是，如果结合InnoDB使用MyISAM的lock tables 语句或第三方事务引擎,则InnoDB无法识别死锁。为消除这种可能性，可以将innodb_lock_wait_timeout设置为一个整数值，指示 MySQL在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)

innodb_file_per_table = 0 #独享表空间（关闭）

[mysqlmp]

quick

max_allowed_packet = 16M

4. 架构优化

（1）. 前端用memcached，redis等缓存分担数据库压力

（2）. 数据库读写分离，负载均衡

（3）. 数据库分库分表

（4）. 存储可采取分布式

5. 后期优化

主要是多观察，后期就是维护工作了，观察服务器负载是需要添加硬件了，还是有语句有问题啊，还是参数要修改了。

6. 查询优化（摘抄别人的）

63. 使用慢查询日志去发现慢查询。

64. 使用执行计划去判断查询是否正常运行。

65. 总是去测试你的查询看看是否他们运行在最佳状态下 –久而久之性能总会变化。

66. 避免在整个表上使用count(*),它可能锁住整张表。

67. 使查询保持一致以便后续相似的查询可以使用查询缓存。

68. 在适当的情形下使用GROUP BY而不是DISTINCT。

69. 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。

70. 保持索引简单,不在多个索引中包含同一个列。

71. 有时候MySQL会使用错误的索引,对于这种情况使用USE INDEX。

72. 检查使用SQL_MODE=STRICT的问题。

73. 对于记录数小于5的索引字段，在UNION的时候使用LIMIT不是是用OR.

74. 为了 避免在更新前SELECT，使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去实现。

75. 不要使用 MAX,使用索引字段和ORDER BY子句。

76. 避免使用ORDER BY RAND().

77。LIMIT M，N实际上可以减缓查询在某些情况下，有节制地使用。

78。在WHERE子句中使用UNION代替子查询。

79。对于UPDATES（更新），使用 SHARE MODE（共享模式），以防止独占锁。

80。在重新启动的MySQL，记得来温暖你的数据库，以确保您的数据在内存和查询速度快。

81。使用DROP TABLE，CREATE TABLE DELETE FROM从表中删除所有数据。

82。最小化的数据在查询你需要的数据，使用*消耗大量的时间。

83。考虑持久连接，而不是多个连接，以减少开销。

84。基准查询，包括使用服务器上的负载，有时一个简单的查询可以影响其他查询。

85。当负载增加您的服务器上，使用SHOW PROCESSLIST查看慢的和有问题的查询。

86。在开发环境中产生的镜像数据中 测试的所有可疑的查询。