MySQL优化二（连接优化和缓存优化）

body {
font-family: Helvetica, arial, sans-serif;
font-size: 14px;
line-height: 1.6;
padding-top: 10px;
padding-bottom: 10px;
background-color: white;
padding: 30px; }

body > *:first-child {
margin-top: 0 !important; }
body > *:last-child {
margin-bottom: 0 !important; }

a {
color: #4183C4; }
a.absent {
color: #cc0000; }
a.anchor {
display: block;
padding-left: 30px;
margin-left: -30px;
cursor: pointer;
position: absolute;
top: 0;
left: 0;
bottom: 0; }

h1, h2, h3, h4, h5, h6 {
margin: 20px 0 10px;
padding: 0;
font-weight: bold;
-webkit-font-smoothing: antialiased;
cursor: text;
position: relative; }

h1:hover a.anchor, h2:hover a.anchor, h3:hover a.anchor, h4:hover a.anchor, h5:hover a.anchor, h6:hover a.anchor {
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAA09pVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNiAoMTMuMCAyMDEyMDMwNS5tLjQxNSAyMDEyLzAzLzA1OjIxOjAwOjAwKSAgKE1hY2ludG9zaCkiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6OUM2NjlDQjI4ODBGMTFFMTg1ODlEODNERDJBRjUwQTQiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6OUM2NjlDQjM4ODBGMTFFMTg1ODlEODNERDJBRjUwQTQiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDo5QzY2OUNCMDg4MEYxMUUxODU4OUQ4M0REMkFGNTBBNCIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDo5QzY2OUNCMTg4MEYxMUUxODU4OUQ4M0REMkFGNTBBNCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PsQhXeAAAABfSURBVHjaYvz//z8DJYCRUgMYQAbAMBQIAvEqkBQWXI6sHqwHiwG70TTBxGaiWwjCTGgOUgJiF1J8wMRAIUA34B4Q76HUBelAfJYSA0CuMIEaRP8wGIkGMA54bgQIMACAmkXJi0hKJQAAAABJRU5ErkJggg==) no-repeat 10px center;
text-decoration: none; }

h1 tt, h1 code {
font-size: inherit; }

h2 tt, h2 code {
font-size: inherit; }

h3 tt, h3 code {
font-size: inherit; }

h4 tt, h4 code {
font-size: inherit; }

h5 tt, h5 code {
font-size: inherit; }

h6 tt, h6 code {
font-size: inherit; }

h1 {
font-size: 28px;
color: black; }

h2 {
font-size: 24px;
border-bottom: 1px solid #cccccc;
color: black; }

h3 {
font-size: 18px; }

h4 {
font-size: 16px; }

h5 {
font-size: 14px; }

h6 {
color: #777777;
font-size: 14px; }

p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0; }

hr {
background: transparent url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAYAAAAECAYAAACtBE5DAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyJpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEzNDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6OENDRjNBN0E2NTZBMTFFMEI3QjRBODM4NzJDMjlGNDgiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6OENDRjNBN0I2NTZBMTFFMEI3QjRBODM4NzJDMjlGNDgiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDo4Q0NGM0E3ODY1NkExMUUwQjdCNEE4Mzg3MkMyOUY0OCIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDo4Q0NGM0E3OTY1NkExMUUwQjdCNEE4Mzg3MkMyOUY0OCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PqqezsUAAAAfSURBVHjaYmRABcYwBiM2QSA4y4hNEKYDQxAEAAIMAHNGAzhkPOlYAAAAAElFTkSuQmCC) repeat-x 0 0;
border: 0 none;
color: #cccccc;
height: 4px;
padding: 0;
}

body > h2:first-child {
margin-top: 0;
padding-top: 0; }
body > h1:first-child {
margin-top: 0;
padding-top: 0; }
body > h1:first-child + h2 {
margin-top: 0;
padding-top: 0; }
body > h3:first-child, body > h4:first-child, body > h5:first-child, body > h6:first-child {
margin-top: 0;
padding-top: 0; }

a:first-child h1, a:first-child h2, a:first-child h3, a:first-child h4, a:first-child h5, a:first-child h6 {
margin-top: 0;
padding-top: 0; }

h1 p, h2 p, h3 p, h4 p, h5 p, h6 p {
margin-top: 0; }

li p.first {
display: inline-block; }
li {
margin: 0; }
ul, ol {
padding-left: 30px; }

ul :first-child, ol :first-child {
margin-top: 0; }

dl {
padding: 0; }
dl dt {
font-size: 14px;
font-weight: bold;
font-style: italic;
padding: 0;
margin: 15px 0 5px; }
dl dt:first-child {
padding: 0; }
dl dt > :first-child {
margin-top: 0; }
dl dt > :last-child {
margin-bottom: 0; }
dl dd {
margin: 0 0 15px;
padding: 0 15px; }
dl dd > :first-child {
margin-top: 0; }
dl dd > :last-child {
margin-bottom: 0; }

blockquote {
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }

table {
padding: 0;border-collapse: collapse; }
table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
table tr:nth-child(2n) {
background-color: #f8f8f8; }
table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
table tr th :first-child, table tr td :first-child {
margin-top: 0; }
table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }

img {
max-width: 100%; }

span.frame {
display: block;
overflow: hidden; }
span.frame > span {
border: 1px solid #dddddd;
display: block;
float: left;
overflow: hidden;
margin: 13px 0 0;
padding: 7px;
width: auto; }
span.frame span img {
display: block;
float: left; }
span.frame span span {
clear: both;
color: #333333;
display: block;
padding: 5px 0 0; }
span.align-center {
display: block;
overflow: hidden;
clear: both; }
span.align-center > span {
display: block;
overflow: hidden;
margin: 13px auto 0;
text-align: center; }
span.align-center span img {
margin: 0 auto;
text-align: center; }
span.align-right {
display: block;
overflow: hidden;
clear: both; }
span.align-right > span {
display: block;
overflow: hidden;
margin: 13px 0 0;
text-align: right; }
span.align-right span img {
margin: 0;
text-align: right; }
span.float-left {
display: block;
margin-right: 13px;
overflow: hidden;
float: left; }
span.float-left span {
margin: 13px 0 0; }
span.float-right {
display: block;
margin-left: 13px;
overflow: hidden;
float: right; }
span.float-right > span {
display: block;
overflow: hidden;
margin: 13px auto 0;
text-align: right; }

code, tt {
margin: 0 2px;
padding: 0 5px;
white-space: nowrap;
border: 1px solid #eaeaea;
background-color: #f8f8f8;
border-radius: 3px; }

pre code {
margin: 0;
padding: 0;
white-space: pre;
border: none;
background: transparent; }

.highlight pre {
background-color: #f8f8f8;
border: 1px solid #cccccc;
font-size: 13px;
line-height: 19px;
overflow: auto;
padding: 6px 10px;
border-radius: 3px; }

pre {
background-color: #f8f8f8;
border: 1px solid #cccccc;
font-size: 13px;
line-height: 19px;
overflow: auto;
padding: 6px 10px;
border-radius: 3px; }
pre code, pre tt {
background-color: transparent;
border: none; }

sup {
font-size: 0.83em;
vertical-align: super;
line-height: 0;
}

kbd {
display: inline-block;
padding: 3px 5px;
font-size: 11px;
line-height: 10px;
color: #555;
vertical-align: middle;
background-color: #fcfcfc;
border: solid 1px #ccc;
border-bottom-color: #bbb;
border-radius: 3px;
box-shadow: inset 0 -1px 0 #bbb
}

* {
-webkit-print-color-adjust: exact;
}
@media screen and (min-width: 914px) {
body {
width: 854px;
margin:0 auto;
}
}
@media print {
table, pre {
page-break-inside: avoid;
}
pre {
word-wrap: break-word;
}
}

MySQL优化二（连接优化和缓存优化）

上文MySQL优化:一、缓存优化这篇文章中提到了一个很重要的概念，就是show variables是用来表示系统编译或者配置在my.cnf中的变量值。而show status则称之为状态值，显示的是当前服务实例运行所具有的状态信息，是一个动态改变的值。因此常用来观测当前MySQl的运行是否正常，如果不正常那么依靠调整静态参数来提高MySQL的性能。所以明白这两个概念的不同，是后面调优的基础。

一、MySQL 连接优化

记得有一次在公司内部连接MySQL的时候，总是连接不上。找到DBA后，经过排查原因，是当前MySQL连接数满了，经过调整后，解决了问题。引发连接数过多的错误原因一般有两个，第一的确是有很多人在连接MySQL，造成连接数用完。第二种是max_connections值过小。

1、连接参数（show variables）

mysql> show variables like '%connect%';
+-----------------------------------------------+-----------------+
| Variable_name                                 | Value           |
+-----------------------------------------------+-----------------+
| character_set_connection                      | utf8            |
| collation_connection                          | utf8_general_ci |
| connect_timeout                               | 10              |
| disconnect_on_expired_password                | ON              |
| init_connect                                  |                 |
| max_connect_errors                            | 100             |
| max_connections                               | 151             |
| max_user_connections                          | 0               |
| performance_schema_session_connect_attrs_size | 512             |
+-----------------------------------------------+-----------------+

max_connections是指MySQL服务实例能够同时接受的的最大并发连接数。MySQL实际上支持最大连接数加一的算法，保障当连接数用完的时候，超级管理员依然可以和服务端建立连接，进行管理。

max_user_connections设置指定账号的最大并发连接数。

max_connect_errors 当某台非法主机恶意连接MySQL服务端，遭到的错误达到设置值后，MySQL会解决来自该主机的所有连接。但执行flush hosts后会清零。

2、连接状态(show status)

有一点需要注意的，变量值（show variables）是以小写字母开头的，而状态值（show status）是以大写字母开头。这样区分有助于记忆和分类

mysql> show status like '%connections%';
+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Connection_errors_max_connections | 0     |
| Connections                       | 197   |
| Max_used_connections              | 2     |
+-----------------------------------+-------+

Connection_errors_max_connections 当MySQL的最大并发数大于系统变量（show variables）中max_connections的最大并发数，因此而被拒绝的次数，将会记录在这个变量里。如果Connection_error_max_connections值比较大，则说明当前系统并发比较高，要考虑调大max_connections的值。

Connections表示MySQL从启动至今，成功建立连接的连接数，这个值是不断累加的。

Max_used_connections表示MySQL从启动至今，同一时刻并发的连接数，取得是最大值。如果这个值大于 max_connections则表明系统经常处于高并发的状态，应该考虑调大最大并发连接数。

3、连接线程参数（thread variabls and status）

mysql> show variables like 'thread%';
+--------------------+---------------------------+
| Variable_name      | Value                     |
+--------------------+---------------------------+
| thread_cache_size  | 9                         |
| thread_concurrency | 10                        |
| thread_handling    | one-thread-per-connection |
| thread_stack       | 262144                    |
+--------------------+---------------------------+

thread_cache_size 设置连接线程缓存的数目。这个缓存相当于MySQL线程的缓存池（thread cache pool）,将空闲的连接线程放入连接池中缓存起来，而非立即销毁。当有新的连接请求时，如果连接池中有空闲的连接，则直接使用。否则要重新创建线程。创建线程是一个不小的系统开销。MySQL的这部分线程处理和Nginx 的线程处理有异曲同工之妙，以后介绍Nginx的线程处理时，会拿来做对比。

thread_handling 默认值是： one-thread-per-connection 表示为每个连接提供或者创建一个线程来处理请求，直至请求完毕，连接销毁或者存入缓存池。当值是no-threads 时，表示在始终只提供一个线程来处理连接，一般是单机做测试使用的。

thread_stack stack 是堆的意思，由PHP 进程详解这篇博客，知道进程和线程都是有唯一的ID的，进程的ID系统会维护，二线程的ID,则由具体的线程库区维护，当进程或者线程休眠的时候，进程的上下文信息要在内存中开辟出一块区域，保存进程的上下文信息，以便于迅速唤醒程序。默认为MySQL的每个线程设置的堆栈大小为：262144/1024=256k

查看线程状态信息

mysql> show status like 'Thread%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 1     |
| Threads_connected | 1     |
| Threads_created   | 2     |
| Threads_running   | 1     |
+-------------------+-------+

Thread_cached 当前线程池的线程数

Thread_connected 当前的连接数

Thread_cached: 当前连接线程创建数, 如果这个值过高，可以调整threadcachesize 也就是调整线程缓存池的大小。

Thred_runnint: 当前活跃的线程数。

连接请求堆栈

MySQL在很短的时间内，突然收到很多的连接请求时，MySQL会将不能来得及处理的连接请求保存在堆栈中，以便MySQL后续处理。back_log参数设置了堆栈的大小，可以通过如下命令查看：

mysql> show variables like 'back_log';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| back_log      | 80    |
+---------------+-------+

连接异常

mysql> show status like 'Aborted%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 0     |
| Aborted_connects | 219   |
+------------------+-------+

Aborted_clients MySQL 客户机被异常关闭的次数。

Aborted_connects 试图连接到MySQL服务器而失败的连接次数。

other

mysql> show status like 'Slow%';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| Slow_launch_threads | 0     |
| Slow_queries        | 0     |
+---------------------+-------+
mysql> show variables like 'slow_launch_time';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| slow_launch_time | 2     |
+------------------+-------+

Slow_lunch_threads 创建线程的时间过长，超过slow_launch_time的设定值，则会记录。

可以通过使用 Connection_error%来查看连接的错误状态信息：

mysql> show status like 'Connection_error%';
+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Connection_errors_accept          | 0     |
| Connection_errors_internal        | 0     |
| Connection_errors_max_connections | 0     |
| Connection_errors_peer_address    | 0     |
| Connection_errors_select          | 0     |
| Connection_errors_tcpwrap         | 0     |
+-----------------------------------+-------+

Connection_errors_peer_address 查找MySQL客户机IP地址是发生的错误数。

二、缓存的优化

MySQL 内部处处皆缓存，等什么时候看了MySQL的源码，再来详细的分析缓存的是如何利用的。这部分主要将各种显式的缓存优化：

查询缓存优化
结果集缓存
排序缓存
join 连接缓存
表缓存Cache 与表结构定义缓存Cache
表扫描缓存buffer
MyISAM索引缓存buffer
日志缓存
预读机制
延迟表与临时表

1、查询缓存优化

查询缓存不仅将查询语句结构缓存起来，还将查询结果缓存起来。一段时间内，如果是同样的SQL,则直接从缓存中读取结果，提高查找数据的效率。但当缓存中的数据与硬盘中的数据不一致时，缓存就会失效。

mysql> show variables like '%query_cache%';
+------------------------------+---------+
| Variable_name                | Value   |
+------------------------------+---------+
| have_query_cache             | YES     |
| query_cache_limit            | 1048576 |
| query_cache_min_res_unit     | 4096    |
| query_cache_size             | 1048576 |
| query_cache_type             | OFF     |
| query_cache_wlock_invalidate | OFF     |
+------------------------------+---------+

have_query_cache 是否支持查询缓存。

query_cache_limit 如果某条select语句的结果集大小超过了querycachelimit的值时，这个结果集将不会被添加到查询缓存。

query_cache_min_res_unit 查询缓存是以块来申请内存空间的，每次申请的块大小为设定值。4K 是非常一个合理的值，不必修改。

query_cache_size 查询缓存的大小。

query_cache_type 查询缓存的类型，值有 0（OFF）、1（ON）、2（DEMOND）。OFF表示查询缓存是关闭的。ON 表示查询总是先到查询缓存中去查找，除非在select 语句中包含sql_no_cache选项。
DEMOND 表示不适用缓存，除非在select 语句中包含sql_cache选项。

query_cache_wlock_invalidate 该参数用于设置行级排它锁与查询缓存之间的关系，默认为为0（OFF）,表示施加行级排它所的同时，该表的所有查询缓存依然有效。如果设置为1（ON）,表示事假行级排它锁的同时，该表的所有查询缓存失效。

查看查询缓存的命中率

mysql> show status like 'Qcache%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Qcache_free_blocks      | 1       |
| Qcache_free_memory      | 1031360 |
| Qcache_hits             | 0       |
| Qcache_inserts          | 0       |
| Qcache_lowmem_prunes    | 0       |
| Qcache_not_cached       | 0       |
| Qcache_queries_in_cache | 0       |
| Qcache_total_blocks     | 1       |
+-------------------------+---------+

查看当前缓存的状态信息：

Qcache_free_blocks

表示查询缓存中处以重现状态的内存块数（碎片数量）。如果Qcache_free_blocks 的值较大，则意味着查询缓存中碎片比较多，表明查询结果集较小，此时可以减小query_cache_min_res_unit的值。使用flush query cache 会对缓存中的若干个碎片进行整理，从而得到一个比较大的空闲块。缓存碎片率 = Qcache_free_blocks/ Qcache_total_blocks * 100%

Qcache_free_memory

表示当前MySQL服务实例的查询缓存还有多少可用内存。

Qcache_hits

表示使用查询缓存的次数，该值会依次增加。如果Qcache_hits比较大，则说明查询缓存使用的非常频繁，此时需要增加查询缓存。

Qcache_inserts

表示查询缓存中此前总共缓存过多少条select 语句的结果集。

Qcache_lowmen_prunes

表示因为查询缓存已满而溢出，导致MySQL删除的查询结果个数。如果该值比较大，则表明查询缓存过小。

Qcache_not_cached

表示没有进入查询缓存的select个数

Qcache_queryies_in_cache

表示查询缓存中缓存这多少条select语句的结果集

Qcache_total_blocks

查询缓存的总个数

缓存命中率的计算方式：
查询缓存的命中率 = Qcache_hits / Com_select * 100%

其中Com_select为当前MySQL实例执行select 语句的个数。一般情况下Com_select = Qcache_insert + Qcache_not_cached。而 Qcache_not_cached中包含有数据频繁变化而导致查询缓存失效的select语句，因此命中率一般来说较低。如果抛开失效的因素，查询缓存的命中率 = Qcache_hits / (Qcache_hits + Qcache_inserts) 如果使用这种公式计算出查询缓存的命中率比较高的话，这就意味着大部分select语句都命中了查询缓存。

通过如下命令查看当前系统一共执行了多少条select语句

mysql> show status like 'Com_select';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_select    | 1     |
+---------------+-------+

2、结果集缓存

结果集缓存是会话缓存，MySQL客户机成功连接服务器之后。MySQL服务器会为每个MySQL客户机保留结果集缓存。缓存MySQL客户机连接线程的连接信息以及缓存返回MySQL客户机的结果集信息,当MySQL客户机向服务器发送select 语句时，MySQL将select语句的执行结果暂存在结果集缓存中。结果集的缓存大小由 net_buffer_length 参数值定义:

mysql> show variables like 'net_buffer_length';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| net_buffer_length | 16384 |
+-------------------+-------+

如果结果集超过net_buffer_length设置的值，则自动扩充容量，但不超过：max_allowd_packet的阈限值：

mysql> show  variables like 'max_allowed_packet';
+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 4194304 |
+--------------------+---------+

3、排序缓存

MySQL 常用的有InnoDB 和MyISAM 两种数据存储引擎。因此在优化的时候，每种引擎都会采用适合自己引擎的优化方法。关于MySQL 与InnoDB 表结构文件和数据日志文件的不同，可以先看本人的博客MySQL 日志系统,以便对这些基础概念有足够的了解，接下来看引擎的优化的方法才能如鱼得水，不觉得枯燥。

1、普通排序缓存

排序缓存是会话缓存, 如果客户机向服务端发送的SQL语句中含有设计排序的order by 或者group by 子句。MySQL就会选择相应的排序算法，在普通排序索引上进行排序，提升排序速度。普通排序索引的大小由sort_buffer_size 参数定义，如果要提升排序的速度，首先应该添加合适的索引，此后则应该增大排序索引缓存sort_buffer_size.

mysql> select @@global.sort_buffer_size / 1024;
+----------------------------------+
| @@global.sort_buffer_size / 1024 |
+----------------------------------+
|                         256.0000 |
+----------------------------------+
1 row in set (0.00 sec)

接下来我们来看下与排序缓存相关的参数有哪些：

mysql> show variables like '%sort%';
+--------------------------------+---------------------+
| Variable_name                  | Value               |
+--------------------------------+---------------------+
| innodb_disable_sort_file_cache | OFF                 |
| innodb_ft_sort_pll_degree      | 2                   |
| innodb_sort_buffer_size        | 1048576             |
| max_length_for_sort_data       | 1024                |
| max_sort_length                | 1024                |
| myisam_max_sort_file_size      | 9223372036853727232 |
| myisam_sort_buffer_size        | 8388608             |
| sort_buffer_size               | 262144              |
+--------------------------------+---------------------+
mysql> show status like '%sort%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Sort_merge_passes | 0     |
| Sort_range        | 0     |
| Sort_rows         | 0     |
| Sort_scan         | 0     |
+-------------------+-------+

max_length_for_sort_data

默认大小为1024字节，对每一列的进行排序操作是，如果该列的值长度较长，通过增加该参数来提升MySQL性能。

max_sort_length

order by 或者 group by 的时候使用该列的前 max_sort_length字节进行排序，排序操作完成后，会将此次排序的信息记录到本次会话的状态里。

Sort_merge_passes

使用临时文件完成排序操作的次数。MySQL在进行排序操作时，首先尝试在普通排序缓存中完成排序。如果缓存空间不够用，MySQL将利用缓存进行多次排序。并把每次的排序结果存放到临时文件中，最后再把临时文件中的数据做一次排序。Sort_merge_passes值就是记录了使用文件进行排序的次数。由于文件排序要牵涉到读文件，打开文件句柄，然后关闭文件等操作。所以读取文件的系统消耗比较大，通过增大普通排序缓存sort_buffer_size来减少使用临时文件排序的次数，从而增加排序的性能。

Sort_range

使用范围排序的次数

Sort_rows

已经排序的记录行数

Sort_scan

通过全表扫描完成排序的次数

2、MyISAM排序缓存

当我们使用alter table 语句或者create index 语句创建MyISAM表的索引，或者导入一部分数据使用load data infile path，这些操作都会导致索引被重建，重建索引时需要对索引字段进行排序操作，为了加快重建索引的效率，MyISAM提供了排序缓存用于实现索引的排序工作，这些方法都是尽量是排序的工作在内存中完成。MyISAM排序缓存的大小由myisam_sort_buffer_size定义。索引重建之后，该缓存立马释放。

但是当排序的缓存超过myisam_sort_buffer_size的阈限时，此时就需要在临时文件中完成索引字段的排序工作，外存临时文件的大小由myisam_max_sort_file_size参数设定，索引重建后，临时文件立即删除。

mysql> select @@global.myisam_sort_buffer_size/1024;
+---------------------------------------+
| @@global.myisam_sort_buffer_size/1024 |
+---------------------------------------+
|                             8192.0000 |
+---------------------------------------+
mysql> select @@global.myisam_max_sort_file_size /1024;
+------------------------------------------+
| @@global.myisam_max_sort_file_size /1024 |
+------------------------------------------+
|                    9007199254739967.7734 |
+------------------------------------------+

3、InnoDB 排序缓存

和MyISAM引擎类似，当执行alter table 、create index 创建索引是，InnoDB提供了3个InnoDB排序缓存用于实现索引的排序，每个缓存的大小由innodb_sort_buffer_size定义。

mysql> select @@global.innodb_sort_buffer_size/1024;
+---------------------------------------+
| @@global.innodb_sort_buffer_size/1024 |
+---------------------------------------+
|                             1024.0000 |
+---------------------------------------+

4、join 连接缓存

join缓存是会话缓存，如果两张表相连，但是却无法使用索引（这时使用join连接缓存的前提），MySQL将为每张表分配join 连接缓存。

mysql> select @@global.join_buffer_size/1024;
+--------------------------------+
| @@global.join_buffer_size/1024 |
+--------------------------------+
|                       256.0000 |
+--------------------------------+

join_buffer_size 定义了连接缓存的大小，如上图，默认为256;

5、表缓存Cache 与表结构定义缓存Cache

MySQL 服务访问数据库中的表时，实际上MySQL是做的文件的读取操作。MySQL的数据都是存在硬盘上的一个个文件，这个和一些内存的型的数据库不同。当我们查询一张表，使用select 语句时，不考虑使用查询缓存，首先要操作系统打开该文件，产生该文件的描述符。操作系统将文件描述符交给MySQL,MySQL才能对数据库进行CURD的操作。打开文件、产生文件描述符都需要消耗系统资源，造成访问延时。MySQL将已经打开的文件，包括文件描述符缓存起来，以后再次访问该文件时，就无需打开该文件，提高了读取文件的效率。

表结构并不经常变化，当对表进行访问的时候，除了将该表植入MySQL的表缓存外，MySQL还将表结构放入了表结构定义缓存中，供下次使用。

mysql> show variables like 'table%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| table_definition_cache     | 1400  |
| table_open_cache           | 2000  |
| table_open_cache_instances | 1     |
+----------------------------+-------+
mysql> show variables like '%open%';
+----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| have_openssl               | DISABLED |
| innodb_open_files          | 2000     |
| open_files_limit           | 65535    |
| table_open_cache           | 2000     |
| table_open_cache_instances | 1        |
+----------------------------+----------+

table_open_cache

设定了可以缓存表以及视图的数量限制

table_definition_cache

设定了可以存储多少张frm 表结构

对于MySQL MyISAM引擎来说，表结构包含MYI 和MYD 以及表结构frm, 当访问MyISAM 引擎的时候，需要一次性打开两个文件（MYI 、MYD）,产生两个文件描述符。

open_files_limit

打开文件的上限

innodb_open_files

如果InnoDB 表使用的是独立表空间文件（ibd），该参数设定同一时间能够打开的文件数量。

以下是和打开表相关的状态值：

mysql> show status like 'Open%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Open_files               | 18    |
| Open_streams             | 0     |
| Open_table_definitions   | 70    |
| Open_tables              | 63    |
| Opened_files             | 125   |
| Opened_table_definitions | 0     |
| Opened_tables            | 0     |
+--------------------------+-------+

6、表扫描缓存buffer

表扫描分为顺序扫描（Sequential Scan）以及随机扫描（Random Scan）两种方式

顺序扫描
当MyISAM表没有建索引时，查询速度将进行全表扫描，效率很低。为了提升全表扫描的速度，MySQL提供了顺序扫描缓存（read buffer）。此时MySQL按照存储数据的存储顺序因此读出全部的数据块，每次读取的数据块缓存在顺序扫描缓存中，当read buffer写满之后，将数据返还给上层调用者。

随机扫描

当表里有缓存，扫描表的时候，会将表的索引字段放进内存里先拍好序，然后按照已经拍好的顺序去硬盘中查找数据。

7、MyISAM索引缓存buffer

通过缓存MYI索引文件的内容，可以加快读取索引的速度以及索引的速度。索引缓存只对MyISAM表起作用，且被所有线程共享。查询语句或者更新索引通过索引访问表数据的时候，MySQL首先检查索引缓存中是否已经存在需要的索引信息，如果有通过缓存中的索引可以直接访问到索引对应的MYD文件。如果没有，则会读取MYI文件，并将相应的索引数据读取到缓存中。索引缓存对MyISAM表的访问性能起到了至关重要的作用。

mysql> show variables like 'key%';
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| key_buffer_size          | 8388608 (8M)|
| key_cache_age_threshold  | 300     |
| key_cache_block_size     | 1024    |
| key_cache_division_limit | 100     |
+--------------------------+---------+

key_buffer_size

设置索引缓存的大小，默认是8M。建议提升。

key_cache_block_size

指定每个索引缓存的区块大小，建议设置为4K,即4096

key_cache_division_limit

为了有效的使用缓存。默认情况下MySQL降缓存划分为两个索引缓存区，温区（warm area）以及热区（hot area）。key_cache_division_limit参数以百分比的形式向曾哥索引缓存划分为多个区域。当默认值是100的时候，表示索引缓存只有温区，将启用LRU算法淘汰索引缓存中的索引。

key_cahe_age_threshold

控制温区域热区中的索引何时升级何时降级。如果该值小于100，则有热区。移动算法大致类似与LRU算法。

查看当前MySQL服务实例索引读以及索引写的状态值：

mysql> show status like 'Key%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| Key_blocks_not_flushed | 0     |
| Key_blocks_unused      | 6698  |
| Key_blocks_used        | 0     |
| Key_read_requests      | 0     |
| Key_reads              | 0     |
| Key_write_requests     | 0     |
| Key_writes             | 0     |
+------------------------+-------+

8、日志缓存

日志缓存分为二进制日志缓存以及InnoDB重做日志缓存

1、二进制日志缓存

mysql> show variables like '%binlog%cache%';
+----------------------------+----------------------+
| Variable_name              | Value                |
+----------------------------+----------------------+
| binlog_cache_size          | 32768                |
| binlog_stmt_cache_size     | 32768                |
| max_binlog_cache_size      | 18446744073709547520 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
+----------------------------+----------------------+
mysql> show status like '%binlog%cache%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Binlog_cache_disk_use      | 0     |
| Binlog_cache_use           | 0     |
| Binlog_stmt_cache_disk_use | 0     |
| Binlog_stmt_cache_use      | 0     |
+----------------------------+-------+

Mysql 进行创建或者更新的数据的时候，会记录一条二进制日志。然而频繁的进行I/O操作将对MySQL造成较大的性能影响。因此MySQL开辟了一个二进制日志缓存binlog_cache_size。首先将操作写入二进制日志，当操作成功之后，将二进制日志写入硬盘。

2、InnoDB重做日志缓存

事务在commit前，会将产生的重做日志写入InnoDB重做日志缓存，然后InnoDB【择机】执行轮询策略，将缓存中的重做日志文件写入ib_logfile0 以及ib_logfile1重做日志中。

mysql> show variables like 'innodb_log_buffer_size';
+------------------------+---------+
| Variable_name          | Value   |
+------------------------+---------+
| innodb_log_buffer_size | 8388608 |
+------------------------+---------+

InnoDB重做日志缓存可以确保事务提交前，事务运行期间产生的重做日志保存在InnoDB的日志缓存中，但并不写入重做日志文件中。写入时机由innodb_flush_log_at_trx_commit参数控制。

mysql> show variables like 'innodb_flush_log%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_timeout    | 1     |
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+

0:当缓存中重做日志文件以每秒一次的频率写入硬盘缓存，并且同时会更新到硬盘。

1：在每次事务提交的时候，将缓存中重做日志写到重做日志文件，同时写入硬盘，默认是该行为。

2:事务提交的时候，写到缓存，但并不触发文件系统到硬盘的同步操作，但此外每秒一次同步硬盘。

9、预读机制

预读机制主要利用了前文MySQL优化:一、缓存优化所描述的原理。即局部性特征，空间局部性，和时间局部性，这里不再赘述。

1、InnoDB预读机制

InnoDB采用预读机制，将“未来即将访问的数据”包括索引加载到预读缓存中，进而提升数据的读性能。InnoDB支持顺序预读（linear read ahead）与随机预读（random read ahead）两种方式。

数据块（page）是InnoDB硬盘管理的最小单位，一个区由64个连续的数据块构成，对于顺序预读而言，InnoDB首选将该数据所在数据块置入InnoDB缓存池中，可以预测这些数据块的后续块很快就会被访问，于是这些数据块以及前置的数据块会被置入内存中。根据innodb_read_ahead_threshold参数设定预读前后多少个数据块。

mysql> show variables like 'innodb_read_ahead%';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| innodb_read_ahead_threshold | 56    |
+-----------------------------+-------+

2、索引缓存预加载

数据库管理员可以使用MySQL命令 load index into cache 预加载MyISAM表索引

10、MyISAM表延迟插入

mysql> show variables like '%delayed%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| delayed_insert_limit       | 100   |
| delayed_insert_timeout     | 300   |
| delayed_queue_size         | 1000  |
| max_delayed_threads        | 20    |
| max_insert_delayed_threads | 20    |
+----------------------------+-------+

看到这个延迟插入的功能，想起项目里一个有点类似的功能，启发了自己的思路。

使用方法为：insert delyed into table values(*);

delyed_insert_limit

默认值为100.当向MySQL表延迟插入100行记录后，检查该表是否有select语句在等待执行，如果有，暂停insert语句执行。

delayed_insert_timeout

在超时范围内，如果delayed 队列里没有数据，延迟插入线程将关掉。

delayed_queue_size

延迟插入的队列长度,超出将阻塞，直到有足够的空间。

max_delayed_threads

延迟插入的线程数。

MyISAM表的批量延迟插入

类似 insert into table values(1),values(2),values(n)。MyISAM将进行批量插入。先将插入的数据放入缓存。当缓存被写满或者提交完毕了，MySQL一次性的将缓存中的写入硬盘。通过批量插入可以大大缩减MySQL客户机与服务机的连接语法分析等消耗，使得效率比分开执行单个insert语句快的多。

mysql> select @@global.bulk_insert_buffer_size/(1024*1024);
+----------------------------------------------+
| @@global.bulk_insert_buffer_size/(1024*1024) |
+----------------------------------------------+
|                                       8.0000 |
+----------------------------------------------+

默认批量插入的大小为8M。如果业务上有需要，可以设定的大一些，以提高批量插入的性能。

MyISAM表的索引延迟更新

索引可以加快数据检索，但是对于更新来说，不仅需要修改记录，可能还需要修改索引，因此索引会导致数据更新操作变慢，如果将MySQL的delay_key_write参数设置为1（ON）,可以弥补这一缺陷。开启后更新操作修改数据的时候先将数据的更新提交到硬盘，索引的更新全部在索引缓存里完成。在关闭表的时候，一起更新到硬盘，这样就可以使索引更新的更快。仅对MyISAM有效。

mysql> show variables like 'delay_key_write';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| delay_key_write | ON    |
+-----------------+-------+

InnoDB延迟更新

非聚簇索引的更新操作通常会带来随机I/O，降低InoDB的性能。当更新（insert, delete ，update=insert+delete）非聚簇索引的数据时，会先检查非聚簇索引页是否位于InnoDB缓存池中，如果是直接更新，否则先将“信息修改”记录在更新缓存中（change buffer）

这篇博客的内容比较多，总结提炼下来以备以后查看。对整个MySQL的优化先有个整体的框架，徐徐渐进慢慢进步。这些参数可以不用记忆，用到的时候到博客中查找或者百度即可。了解道，知道术，就可以完成优化的过程。知道原理比记忆枯燥的原理要简单的多。对MySQL优化感兴趣的博友可以关注我的博客，以便看到后续的分享。

MySQL优化二（连接优化和缓存优化）的更多相关文章

Tomcat性能优化(二) ExpiresFilter设置浏览器缓存
Tomcat性能调优通过ExpiresFilter设置资源缓存 [官方文档] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#E ...
ecshop二次开发系统缓存优化之扩展数据缓存的必要性与方法
1.扩展数据缓存的必要性大家都知道ecshop系统使用的是静态模板缓存,在后台可以设置静态模板的缓存时间,只要缓存不过期,用户访问页面就相当于访问静态页面,速度可想而知,看似非常完美,但是ecsho ...
NSCache和NSURLCache、网络缓存优化
本文目录一种缓存优化方案响应头'Last-Modified'和请求头'If-Modified-Since' 'Keep-Alive'响应头和不离线的URLSession 'Expires'响应头 ...
Java系统高并发之Redis后端缓存优化
一:前端优化暴露接口,按钮防重复(点击一次按钮后就变成禁用,禁止重复提交) 采用CDN存储静态化的页面和一些静态资源(css,js等) 二:Redis后端缓存优化 Redis 是完全开源免费的,遵守 ...
MySql（十一）：MySQL性能调优——常用存储引擎优化
一.前言 MySQL 提供的非常丰富的存储引擎种类供大家选择,有多种选择固然是好事,但是需要我们理解掌握的知识也会增加很多.本章将介绍最为常用的两种存储引擎进行针对性的优化建议. 二.MyISAM存储 ...
DB数据源之SpringBoot+MyBatis踏坑过程（六）mysql中查看连接，配置连接数量
DB数据源之SpringBoot+MyBatis踏坑过程(六)mysql中查看连接,配置连接数量 liuyuhang原创,未经允许禁止转载系列目录连接 DB数据源之SpringBoot+Mybati ...
MySQL优化二缓存参数优化
数据库属于 IO密集型的应用程序,其主要职责就是数据的管理及存储工作.而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取一个IO是在毫秒级别,二者相差3个数量级.所以,要优化数 ...
MySQL优化-一、缓存优化
body { font-family: Helvetica, arial, sans-serif; font-size: 14px; line-height: 1.6; padding-top: 10 ...
MySQL/MariaDB数据库的查询缓存优化
MySQL/MariaDB数据库的查询缓存优化作者:尹正杰版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.MySQL架构 Connectors(MySQL对外提供的交互接口,API): ...

随机推荐

Jquery Validate 正则表达式实用验证代码常用的
jQuery.validate 的正则验证功能,包括手机号码.电话号码.邮政编码.QQ号码.IP地址.字母和数字.中文的验证等手机号码验证以下为引用内容: 代码如下: jQuery.validat ...
获取CPU系列号,硬盘系
unit Secrity; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, For ...
HDU-1395-2^x mod n = 1（数学题（二次出错））
题目链接: http://acm.hdu.edu.cn/showproblem.php?pid=1395 这题一定要滴水不漏的把所有代码全部看完. 这个题目是一个数学类型的题,我也没思路,只知道n== ...
BNU Online Judge-34973-Liserious战队
题目链接 http://www.bnuoj.com/bnuoj/problem_show.php?pid=34973 题目不难,很容易,不过不仔细看题可能你一直做不出,注意<<一共分为1~ ...
#图# #SPFA# #Tarjan# ----- BZOJ1179
SPFA算法 SPFA(Shortest Path Faster Algorithm)(队列优化)算法是求单源最短路径的一种算法. 判负环(在差分约束系统中会得以体现).如果某个点进入队列的次数超过N ...
jQuery选择器，用逗号分隔的时候需要注意范围问题
jQuery选择器,用逗号分隔的时候需要注意范围问题: <%@ page language="java" import="java.util.*" pag ...
Bootstrap入门（十六）组件10：well和具有响应式特性的嵌入内容
Bootstrap入门(十六)组件10:well和具有响应式特性的嵌入内容 well组件可以为内容增添一种切入效果. 具有响应式特性的嵌入内容可以根据被嵌入内容的外部容器的宽度,自动创建一个固定的比例 ...
让EFCore更疯狂些的扩展类库(二)：查询缓存、分部sql、表名替换的策略配置
前言上一篇介绍了扩展类库的功能简介,通过json文件配置sql语句和 sql语句的直接执行,这篇开始说明sql配置的策略模块:策略管理器与各种策略的配置. 类库源码:github:https:// ...
001.MVC基本概述
MVC的基本概念一.NET平台下开发web应用程序的方案(方法) 方案A:ASP.NET webForm1.web窗体:臃肿(胖)性能低优点:有很多的web控件可以使用,能够方便的和服务端交互(数 ...
ubuntu 16.04 的64位安装arm-none-linux-gnueabi-gcc的步骤和问题解决
一首先下载arm-none-linux-gnueabi-gcc交叉编译器,根据不同的需求请在网址: https://launchpad.net/gcc-arm-embedded/+download ...

MySQL优化二（连接优化和缓存优化）

MySQL优化二（连接优化和缓存优化）

一、MySQL 连接优化

1、连接参数（show variables）

2、连接状态(show status)

3、连接线程参数（thread variabls and status）

二、缓存的优化

1、查询缓存优化

2、结果集缓存

3、排序缓存

1、普通排序缓存

2、MyISAM排序缓存

3、InnoDB 排序缓存

4、join 连接缓存

5、表缓存Cache 与表结构定义缓存Cache

6、表扫描缓存buffer

7、MyISAM索引缓存buffer

8、日志缓存

9、预读机制

10、MyISAM表延迟插入

MySQL优化二（连接优化和缓存优化）的更多相关文章

随机推荐

热门专题