MySQL优化二(连接优化和缓存优化)
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): ...
随机推荐
- Javascript 浮点运算问题分析与解决
分析 JavaScript 只有一种数字类型 Number ,而且在Javascript中所有的数字都是以IEEE-754标准格式表示的. 浮点数的精度问题不是JavaScript特有的,因为有些小数 ...
- Chrome调试大全
作为一名前端开发者,打交道最多的可能是和浏览器.市面上各种浏览器多不胜数,主流的有Chrome,Firefox,Safari,IE,Opera,非主流的如360,遨游,QQ浏览器,搜狗浏览器,据说淘宝 ...
- doubango(4)--SIP协议栈传输层的启动
协议栈的默认传输结构 对于一个刚启动的协议栈来说,它需要有一个传输层,支持若干的传输结点.每一个传输结点对应于一个端口,若采用TCP连接,一个传输结点就针对于一个点到点的连接,这个连接负责sip信令的 ...
- Linux中的zero-copy技术
本文是对参考文章重要部分的摘录,同时进行简单地总结. 零拷贝技术的相关背景知识 传统的 Linux 操作系统的标准 I/O 接口是基于数据拷贝操作的,即 I/O 操作会导致数据在操作系统内核地址空间的 ...
- AutoItLibrary安装报错(robotframework)解决
官网下载地址:http://www.softpedia.com/get/Programming/Components-Libraries/AutoItLibrary.shtml Csdn下载地址:ht ...
- .md即markdown文件的基本常用编写语法(图文并茂)
序言: 很久没有写博客了,感觉只要是不写博客,人就很变得很懒,学的知识点感觉还是记不住,渐渐地让我明白,看的越多,懂的越少(你这话不是有毛病吗?应该是看的越多,懂的越多才对),此话怎讲,当你在茫茫的前 ...
- ES1:Windows下安装ElasticSearch
ElasticSearch(简称ES)是一个基于Lucene的分布式全文搜索服务器,本随笔演示在Windows安装ElasticSearch和用于管理ES的Head插件. ElasticSearch官 ...
- Tomcat使用常见问题
1,启动服务器,闪退问题 原因:tomcat软件是用java语言开发的,软件启动时,会默认到系统环境变量中查找一个名叫JAVA_HOME的变量.这个变量的作用是找到tomcat启动所需的JVM. ...
- [html5] 学习笔记-表单新增元素与属性
本节讲的是表单元素的form,formaction属性,frommethod,formenctype属性,formtarget,autofocus属性,required,labels属性. 1.for ...
- nRF51800 蓝牙学习 进程记录 2:关于二维数组 执念执战
前天在玩OLED时想完成一直想弄得一个东西,就是简单的单片机游戏.因为STM32和nRF51822的内存足够,所以就用缓存数组的方法来显示图像(我也不知道术语是啥,反正就是在内存中建立一个128X64 ...