MySQL 性能优化---索引及优化

时间 2020-05-17 标签 mysql 性能优化索引

博主QQ：819594300html

博客地址：http://zpf666.blog.51cto.com/mysql

有什么疑问的朋友能够联系博主，博主会帮大家解答，谢谢支持！sql

1、MySQL性能优化之-影响性能的因素数据库

1、商业需求的影响缓存

Myisam存储引擎内置一个计数器，count(*)时直接从计数器读取；而经过innodb存储引擎查找某个数据时，是必须扫描全表的，因此当执行对表的统计（即便用count(*)函数）时，myisam要比innodb要快的不少。因此通常在innodb上执行count(*)时通常要伴随where，且where中要包含主键之外的索引列。性能优化

2、系统架构及实现的影响服务器

如下几类数据不适合存放在数据库：网络

①二进制多媒体数据：包括图片、音频、视频和其余一些相关的二进制文件。架构

②超大文本数据：从5.0.3版本开始，varchar类型最大长度调整到64KB。并发

3、查询语句对性能的影响

最大的性能瓶颈就是在于磁盘IO。

下面咱们经过用explain来查看执行sql语句的行计划

还能够打开mysql的profiling 功能，来查看sql的实际执行计划

Explain与profiling的区别：

Explain只是预计、估计、估算执行这个计划sql语句须要花费多长时间，并无真正的执行；而profiling则是实际执行了该命令，后者的准确度更高。

经过执行“SHOWPROFILE” 命令获取当前系统中保存的多个Query 的profile（配置文件）的概要信息。

4、数据库schema(架构)设计对性能的影响

5、硬件选择对性能的影响

①数据库主机IO性能是优先考虑的，IO性能主要是由磁盘、内存、网卡共同决定。

②数据库主机的CPU的处理能力也必须考虑。

③还要考虑网络设备（好比说路由器、交换机）。

总结：四句话来归纳：商业需求合理化、系统架构最优化、逻辑实现精简化、硬件设施理性化。

2、MySQL性能优化之-索引

说明：索引优化了查询，可是下降了增、改、删的效率。

“Show index from 表名” 或者 “show keys from 表名” //查询一个表有哪些索引

索引的指针类型于书本的目录页码。

作一个简单测试，假如咱们建立了一个tb1表，向表中插入20000行数据，表的建立和数据插入用以下脚本实现

再手动插入一行数据：

下面开始测试，查询stuname=’admin’的记录：

状况1：stuname列上没有建立索引的状况

状况2：stuname列上建立索引的状况再查询

总结：在查找stuname="admin"的记录时，若是在stuname上已经创建了索引，MySQL无须任何扫描全表，即准确可找到该记录。相反，MySQL会扫描全部记录。

因此在数据库表中，对字段创建索引能够大大提升查询速度。

索引是在存储引擎中实现的，而不是在服务器层中实现的。因此，每种存储引擎的索引都不必定彻底相同，并非全部的存储引擎都支持全部的索引类型。

什么是索引？

索引可以帮助咱们快速定位数据，能够提升查询的速度，它存在的形式是文件。

这里主介绍B-tree索引的结构

总结：B树索引又称平衡树索引。

磁盘块I又称根节点。

磁盘块包括数据项和指针。

数据项相似于书本章节的标题；

指针相似于书本章节所在的页码。

真实的数据存放于叶子节点，非叶子节点不存储真实数据，只存储指引搜索方向的数据项和指针。

索引对数据的排序只有升序和降序。

为何使用索引？

索引可让mysql高效运行，能够大大提升mysql的查询（包括排序，分组）效率；数据约束（惟一索引的创建）。

索引给我带来什么好处？

提升查询效率，快速定位数据。

使用索引产生的代价？

①磁盘的开销

②写数据：须要更新索引，对数据库是个很大的开销，下降表更新、添加和删除的速度。

不建议使用索引的状况：

①数据1000字如下的表不须要建索引

②一列中选择性较低的不建索引（好比这一列是性别的，可能的值只有男和女）（所谓索引的选择性，是指不重复的索引值与表记录数的比值，取值范围（0-1）。选择性越高，索引的价值越大）

索引的类型？

索引包括单列索引和组合索引。

说明：单列索引，即一个索引只包含单个列，一个表能够有多个单列索引，但这不是组合索引。组合索引，即一个索包含多个列。

1、普通索引

这是最基本的索引，它没有任何限制。

2、惟一索引

它与前面的普通索引相似，不一样的就是索引列的值必须惟一，但容许空值，空值是指null。若是是组合索引，组合列的值必须惟一

主键索引：一种特殊的惟一索引，不容许有空值，通常在建表的时候自动创建主键索引。

3、组合索引

为了进一步提高MySQL的效率，就要考虑创建组合索引。

例如：建立一个表，包含以下字段：

将 username, city, age建到一个索引里：

说明：若是分别在 usernname，city，age上创建单列索引，让该表有3个单列索引，查询时和上述的组合索引效率也会大不同，远远低于组合索引。虽然此时有了三个索引，但MySQL只能用到其中那个它认为彷佛是最有效率的单列索引。

创建一个这样的组合索引=实际上是至关于分别创建了下面三组组合索引：

usernname,city,age usernname,city username，没有 city，age这样的组合索引。

Mysql组合索引遵循“最左前缀”原则。简单的理解就是只从最左面的开始组合。并非只要包含这三列的查询都会用到该组合索引。

下面的几个SQL就会用到这个组合索引：

而下面几个则不会用到：

若是对多列进行索引(组合索引)，列的顺序很是重要，MySQL仅能对索引最左边的前缀进行有效的查找。

4、全文索引(用的很是的少)

只用于MyISAM表对文本域进行索引。字段类型包括char、varchar、text

不过切记对于大容量的数据表，生成全文索引是一个很是消耗时间很是消耗硬盘空间的作法。

查看索引

或者

在什么状况下创建索引？

通常来讲，在WHERE和JOIN子句中出现的列须要创建索引。

例如：在username上建立索引

此时就须要对两个表的userame上创建索引。

使用索引的注意事项

①在用like模糊查询时，以通配符%和_开头做查询时，MySQL不会使用索引，而是默认全表扫描。

例以下句会使用索引：

而下句就不会使用：

②不要在有索引的列上进行运算（运算：即便用函数，加、减、乘、除、统计等等）

将在每一个行上进行运算，这将致使索引失效而进行全表扫描，所以咱们能够改为

3、mysql性能优化-慢查询分析、优化索引和配置

基本思路：

1）性能瓶颈定位

Show命令

慢查询日志

explain分析查询

profiling分析查询

2）索引及查询优化

3）配置优化

1、查询与索引优化分析

说明：在优化MySQL时，一般须要对数据库进行分析，常见的分析手段有慢查询日志，EXPLAIN 分析查询，profiling分析以及show命令查询系统状态及系统变量，经过定位分析性能的瓶颈，才能更好的优化数据库系统的性能。

show命令：

能够经过show命令查看MySQL状态及变量，找到系统的瓶颈：

查看MySQL服务器配置信息：

查看MySQL服务器运行的各类状态值：

显示系统变量：

显示状态信息：

比较全的show命令的使用可参考：

或者http://dev.mysql.com/doc/refman/5.7/en/show.html

慢查询日志

慢查询日志开启：

慢查询日志开启方法二：

查看慢查询的设置信息

咱们能够经过打开log文件查看得知哪些SQL执行效率低下

下面是一个例子：

若是慢查询日志中记录内容不少，可使用mysqldumpslow工具（MySQL客户端安装自带）来对慢查询日志进行分类汇总。

mysqldumpslow对日志文件进行了分类汇总，显示汇总后摘要结果。

有关mysqldumpslow命令的用法能够参考其帮助：#mysqldumpslow --help

下面是一个例子：

上面显示结果中就是一条慢查询，如何优化呢？

一是在entertime列上建立索引优化查询：

二是优化这个sql查询语句：

从下图能够看查询0.00秒：

总结：使用mysqldumpslow命令能够很是明确的获得各类咱们须要的查询语句，对MySQL查询语句的监控、分析、优化是MySQL优化很是重要的一步。开启慢查询日志后，因为日志记录操做，在必定程度上会占用CPU资源影响mysql的性能，可是能够阶段性开启来定位性能瓶颈。

explain分析查询

能够模拟优化器执行SQL查询语句。

优化方法：在stuname列上建立索引：

再次执行explain。

profiling分析查询

用过慢查询咱们能够自动哪些SQL局域执行效率低下，而后咱们再经过explain能够得知SQL语句的具体执行状况、索引的使用等。还能够结合show来查看执行状态。

若是以为explain不够详细，则能够经过profiling来获得更准确的SQL执行信息。

1）profiling默认是关闭的，咱们先来看一下profiling是开启仍是关闭的

或者

2）开启profiling功能

3）执行要测试的sql语句

4）对于show profile咱们还能够查看到更多的信息如内存和CPU。

5）测试完成之后，必定记住不要忘记关闭调试功能，以避免影响数据库的正常使用

配置优化

下面列出了对性能优化影响较大的主要变量，

主要分为链接请求的变量和缓冲区变量。

1、链接请求的变量

1）max_connections //设置mysql的最大链接数

何时用到：若是服务器并发链接请求量较大，建议增大该值。

注意：若是链接数越多，mysql会为每一个链接提供链接缓冲区，会开销更多的内存，因此要适当调整该值。

数值太小会报错：error 1040：too many connections

①经过mysql>show status like ‘connections’;来查看mysql服务器当前的链接数（无论成功链接与否，即便失败了记录），若是想看准确的数目，则命令是：“showprocesslist;”

②mysql>show variables like‘max_connections’ //查询最大链接数

③mysql>show status like ‘max_used_connections’ //查询响应的链接数

④max_used_connections / max_connections * 100%(当结果≈ 85%的时候为最佳)，若是二者两同，就是

max_connections设置的太低或者服务器负载已经超上限了。若是结果低于10%，则说明max_connection设置过大。

⑤那么如何修改max_connections呢？

修改/etc/my.cnf配置文件，添加以下配置：

2）back_log //设置mysql的请求队列数量

何时起做用：当一个mysql线程在很短期内收到很是多的链接请求是用到。

Mysql的链接数达到max_connections的时候，新来的请求就放在队列中，当等待链接的数目超过了back_log则忽视多余的请求。

①查看当前主机的mysql进程列表

②mysql> show variables like 'back_log'； //查看back_log的设置

③如何设置back_log?

修改/etc/my.cnf配置文件，添加以下配置：

3）wait_timeout和interactive_timeout

wait_timeout:就是很久没操做了，该链接会被断开，这里设置的就是秒数，用于非交互式模式。

Interactive_timeout：跟上面意思是同样的，不过它使用的是交互式模式，即“mysql>”模式。

Interactive_timeout默认的时间数值是28800秒（即8个小时），咱们能够把它调优成7200秒（即2小时）。

①对性能的影响：

（1）若是设置过小，链接会很快关闭

（2）若是设置太大，容易形成链接打开时间过长，在show processlist的时候，能够看见不少sleep状态的链接从而形成too many connections错误。

（3）通常状况下wait_timeout的值低一些

②查看wait_timeout和interactive_timeout的值

③如何修改wait_timeout和interactive_timeout的值

修改/etc/my.cnf配置文件，手动添加如下两行配置项

2、缓冲区的变量

1）key_buffer_size //设置索引缓冲区大小。决定了索引的处理速度。

①可经过检查Key_read_requests和Key_reads，能够知道key_buffer_size设置是否合理。

说明：key_reads / key_read_requests应该尽量的低，至少是1:100，1:1000更好。

Key_read_requests:全部索引的读请求

Key_reads:索引未命中缓存数（即不是经过缓存的索引读请求，而是直接经过读取硬盘）。

注意：key_buffer_size只对myisam存储引擎表起做用。即便你不使用myisam表，可是内部的临时磁盘表仍是myisam表，它也要使用该值。

②检查状态值，查看created_tmp_disk_tables的值

③如何调整key_buffer_size的值，默认是8M。

修改/etc/my.cnf配置文件，添加下面这一行配置项

2）query_cache_size //简称（QC），设置查询缓冲区的大小，并将查询的结果直接存放在缓存区中。

说明：从此执行一样（一样：是字母大小写法也同样，有无空格也一

样，空几个格也要严格同样）的select语句，则直接从缓冲区中读取。

①经过检查状态值’Qcache%’，能够知道query_cache_size设置是否合理

碎片过多了，须要清理。经过“flush query cache”命令对缓存碎片进行清除。注意：当一个表更新后，则与它相关的cache_blocks（缓存块）都被清空，可是这个缓存快仍是不能用，必须经过“flush query cache”命令清除后才能被使用。

Qcache_free_memory:是query_cache_size的剩余的还未被使用缓存区大小。经过该值能够知道缓存区是否够用仍是过多形成浪费了。

Qcache_hits:有多少次查询是从缓存区直接查询到的。该值越大，明缓存的效果越明显。

Qcache_inserts:有多少次查询不是从缓存区查询到的，而是从硬中查找的，查询到结果后，把结果插入到缓存区里面，为了下次查时候用。该值越大，说明缓存区使用的较少。

Qcache_lowmem_prunes:有多少条sql缓存是由于缓存区大小不足而被新的sql缓存给挤出了缓存区。经过qcache_lowmem_prunes和qcache_free_memory相互结果，更能真实的反映出缓存区大小是否真的够用。如qcache_lowmem_prunes这个数值不断增加，说明碎片很是的严重者缓存区过小了（能够经过查看qcache_free_blocks qcache_free_memory来判断究竟是属于哪种）

Qcache_not_cached:是指不适合缓存的查询SQL语句的数量，这些询语句不是select语句，而是像now()之类的函数（now是一个数，做用是获取当前mysql服务器的系统时间，由于时间是一个变的量，因此不适合作缓存插入到缓存区）

Qcache_queries_in_cache:是指当前缓存区中缓存的SQL语句数量。

Qcache_total_blocks:是指当前缓存区中缓存块（blocks）的数量。

②查询mysql服务器的query_cache的配置：

Query_cache_type:返回的值是off表示不缓存任何查询，即查询缓存功能没有开启

Query_cache_limit:超过该值大小的查询结果不会缓存(默认值是1M，即超过1M的查询缓存结果不缓存到缓存区)

Query_cache_min_res_unit:缓存块的最小大小，默认是4KB一个块。

Query_cache_size:查询的缓存区的大小（注意：QC存储最小单位是1024字节，你设定的QC的值必须是1024字节的倍数）

Query_cache_type:缓存的类型，即决定缓存什么样的查询，这个值必须是数字。（通常咱们设置为1就能够了）

Query_cache_wlock_invalidate:当有其余客户端正在对MyISAM表进行写操做时，若是查询在缓存区中，是否返回缓存的结果仍是等写操做完成再读表获取结果，默认是等写操做完成后再向表读取结果。

③修改query_cache_size 的大小以及缓存的类型

修改/etc/my.cnf配置文件,添加下面两行配置项：

④验证是否真正开启了

⑤缓存区中缓存的限制：

建议经过精确设置的方式，仅仅让合适的表的数据能够进入查询缓存区，仅仅让某些查询语句的查询结果被缓存。

3）max_connect_errors //设置最大失败链接次数

①目的：阻止过多尝试失败的客户端以防止暴力破解密码的状况。

当超过指定次数，则禁止该主机登陆mysql，而不是禁止该用户登陆，禁止有效期是永久的，可是能够经过重启mysql服务或经过“flush hosts”命令清空主机的相关信息。

②怎么添加max_connect_errors的值

修改/etc/my.cnf配置文件，添加下面的一行配置项：

4）sort_buffer_size //为order by或group by语句的结果分配一个缓冲区

①目的是加快下次order by、group by语句的查询速度，是一个connection级参数，当这些SQL语句第一次把结果存入到该order by或group by语句专享额缓冲区里面的时候，mysql就会一次性的为该SQL语句分配设置好缓存大小。

②怎么添加sort_buffer_size的值

修改/etc/my.cnf配置文件，添加下面的一行配置项：

例如：500个链接（即有500个order by或group by语句）将会消耗 500*sort_buffer_size(2M)=1G内存

5）max_allowed_packet=32M //限制mysql服务器接收的客户端发来的数据包的大小（即客户端存入的数据的大小）

该配置项的最大值是1G，可是设置的值必须是1024字节的整数倍。

6）join_buffer_size=2M //用于表间关联的缓存的大小

和sort_buffer_size同样，该参数对应的分配缓存大小也是每一个链接独享。

7）thread_cache_size=300 //服务器线程数量的缓存

这个值表示能够从新利用保存在缓存中线程的数量,当断开链接时,那么客户端的线程将被放到缓存中以响应下一个客户而不是销毁(前提是缓存数未达上限),若是线程从新被请求，那么请求将从缓存中读取,若是缓存中是空的（即缓存数量名额以用完），那么这个线程将被退回去并从新建立（再来进行线程缓存数请求，若是尚未名额，再退回去）,若是有不少新的线程，增长这个值能够改善系统性能。

说明：由于我没有在my.cnf文件开启这个配置项，因此空闲线程是为0。

3、配置innodb的几个变量

1）innodb_buffer_pool_size //至关于key_buffer_size对myisam的做用

①做用：InnoDB使用该参数指定缓冲区的大小来缓冲数据和索引。

对于单独的MySQL数据库服务器，最大能够把该值设置成物理内存的80%。

建议：对于2G内存的机器，推荐值是1G（50%）。

②修改my.cnf配置文件

2）innodb_flush_log_at_trx_commit //主要控制了innodb将日志缓冲区中的数据写入日志文件并刷新磁盘的时间点，取值分别为0、一、2三个

说明：

①0、一、2的说明

0，表示当事务提交时，并不当即任何操做，而是每秒钟将日志缓冲区中的数据直接写入日志文件并刷新磁盘一次；

1，每次事物的提交都会引发日志文件写入、刷新磁盘的操做，确保了事务的ACID；

2，每次事务提交先把日志从日志缓冲区写入到操做系统的缓冲区，而后每秒钟完成一次刷新到的磁盘操做。

②实际测试

设置为2时插入10000条记录只须要2秒，设置为0时只须要1秒，而设置为1时则须要229秒。

③mysql官方建议

尽可能将插入操做合并成一个事务，这样能够大幅提升速度。

3）innodb_thread_concurrency = 0 //设置innodb线程的并发数量，默认为0，即不限制。

说明：若要设置则与服务器的CPU核数相同或是cpu的核数的2倍，建议的设置为8。

4)innodb_log_buffer_size //肯定日志文件所用的缓存大小

以M为单位。缓冲区越大越能提升性能，对于较大的事务，能够增大缓存大小。

建议设置为32M

5）innodb_log_file_size = 50M //肯定数据日志文件的大小

以M为单位。更大的设置能够提升性能。

6）innodb_log_files_in_group=3 //循环方式将日志文件写到多个文件中

为提升性能，MySQL能够以循环方式将日志文件写到多个文件。推荐设置为3

7）read_buffer_size = 1M //mysql读入缓冲区大小

对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。

和 sort_buffer_size同样，该参数对应的分配缓存是每一个链接独享。

8）read_rnd_buffer_size = 16M //MySql 的随机读（查询操做）缓冲区大小

当按任意顺序如，按照排序顺序)，将分配一个随机读缓存区。

MySql会为每一个客户链接发放该缓冲空间，因此应尽可能适当设置该值，以免内存开销过大。

9）bulk_insert_buffer_size = 64M //批量插入数据缓存大小

批量插入数据缓存大小，能够有效提升插入效率，默认为8M。

10)binary log

①binlog_cache_size = 2M //为每一个链接分配的内存，在事务过程当中用来存储二进制日志的缓存, 提升记录bin-log的效率。没有什么大事务，dml也不是很频繁的状况下能够设置小一点，若是事务大并且多，dml操做也频繁，则能够适当的调大一点。前者建议是--1M，后者建议是：即 2--4M

②max_binlog_cache_size = 8M //表示的是binlog 可以使用的最大缓存的大小。

③max_binlog_size = 512M //指定binlog日志文件的大小，若是当前的日志大小达到max_binlog_size，还会自动建立新的二进制日志。你不能将该变量设置为大于1GB或小于4096字节。默认值是1GB。在导入大容量的sql文件时，建议关闭sql_log_bin，不然硬盘扛不住，并且建议按期作删除。

④expire_logs_days = 7 //定义了mysql清除过时日志的时间。二进制日志自动删除的天数。默认值为0,表示“没有自动删除”。mysqladmin flush-logs 命令也能够从新开始新的binary log。

下面进行一个额外的测试

在优化以前执行mysqlslap工具进行测试

[root@localhost ~]#mysqlslap --defaults-file=/etc/my.cnf--concurrency=10 --iterations=1 --create-schema='test1' --query='select * fromtest1.tb1' --engine=innodb --number-of-queries=2000 -uroot -p123456 –verbose

显示结果：

Benchmark

Running forengine innodb

Average numberof seconds to run all queries: 13.837seconds

Minimum numberof seconds to run all queries: 13.837 seconds

Maximum numberof seconds to run all queries: 13.837 seconds

Number ofclients running queries: 10

Average numberof queries per client: 200

优化以后执行mysqlslap工具进行测试

显示结果：

Benchmark

Running forengine innodb

Average numberof seconds to run all queries: 4.199seconds

Minimum numberof seconds to run all queries: 4.199 seconds

Maximum numberof seconds to run all queries: 4.199 seconds

Number ofclients running queries: 10

Average numberof queries per client: 200