MySQL基础: 索引, 优化, 锁

一. mysql的架构介绍

从几年前实习开始, 陆陆续续写了好多的markdown笔记, 早期的笔记大多是在B站和一些大牛博客分享而自己整理的笔记, 早期的笔记体系比较清晰,也是我的学习成长路线.

后续的笔记也有一些在业界大佬的分享,官网论坛,github学习到的更深层次一点的东西以及一些工作的经验和踩到的坑, 以后我会把早期记下的笔记和目前在学习以及工作中遇到的整理成模块不定期分享出来,如果大家有不同的见解也希望能在评论区说出大家的看法.

希望我们永远保持这份思考与热爱.

1.Mysql简介

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB公司开发，目前属于Oracle公司。
MySQL是一种关联数据库管理系统，将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。Mysql是开源的，所以你不需要支付额外的费用。
Mysql是可以定制的，采用了GPL协议，你可以修改源码来开发自己的Mysql系统。Mysql支持大型的数据库。可以处理拥有上千万条记录的大型数据库。
MySQL使用标准的SQL数据语言形式。
Mysql可以允许于多个系统上，并且支持多种语言。这些编程语言包括C、C++、Python、Java、Perl、PHP、Eiffel、Ruby和Tcl等。
MySQL支持大型数据库，支持5000万条记录的数据仓库，32位系统表文件最大可支持4GB，64位系统支持最大的表文件为8TB。

2.MysqlLinux版的安装

以mysql5.5为例,mysql5.7不同

官网下载地址：http://dev.mysql.com/downloads/mysql/

1、检查工作

检查当前系统是否安装过mysql:

    执行安装命令前，先执行查询命令rpm -qa | grep mysql如果存在mysql-libs的旧版本包如下图请先执行卸载命令：rpm -e --nodeps  mysql-libs

检查/tmp文件夹权限:

    由于mysql安装过程中，会通过mysql用户在/tmp目录下新建tmp_db文件，所以请给/tmp较大的权限执行 ：chmod -R 777 /tmp

2、安装

    在mysql的安装文件目录下执行：rpm -ivh MySQL-server-5.5.54-1.linux2.6.x86_64.rpmrpm -ivh MySQL-client-5.5.54-1.linux2.6.x86_64.rpm

3、查看MySQL安装版本

    或者可以执行 mysqladmin --version命令，类似java -version如果打出消息，即为成功。通过vim 查看 mysql组 和mysql组

4、mysql服务的启+停

 service mysql start/stop/status

5、首次登录

安装完成后会提示出如下的提示：
在mysql首次登录前要给 root 账号设置密码

启动服务后，执行命令
/usr/bin/mysqladmin -u root  password 'root'
(mysql5.5的在/usr/local/mysql/bin下)

然后通过 mysql -uroot -proot进行登录

6、MySQL的安装位置

在linux下查看安装目录  ps -ef | grep mysql

参数	(yum安装)路径	路径	解释	备注
–basedir	/usr/local/mysql/bin	/usr/bin	相关命令目录	mysqladmin mysqldump等命令
–datadir	/usr/local/mysql/data	/var/lib/mysql/	mysql数据库文件的存放路径
–plugin-dir	/usr/local/mysql /lib/plugin	/usr/lib64/mysql /plugin	mysql插件存放路径
–log-error	/var/lib/mysql /jack.atguigu.err	/var/lib/mysql /jack.atguigu.err	/var/lib/mysql /jack.atguigu.err
–pid-file	/var/lib/mysql /jack.atguigu.pid	/var/lib/mysql /jack.atguigu.pid	进程pid文件
–socket	/var/lib/mysql /mysql.sock	/var/lib/mysql /mysql.sock	本地连接时用的unix套接字文件
	/usr/local/mysql/share	/usr/share/mysql	配置文件目录	mysql脚本及配置文件
	/etc/init.d/mysql	/etc/init.d/mysql	服务启停相关脚本

7、自启动mysql服务

8、修改字符集问题

    尝试插入输入：原因是字符集问题1 查看字符集show variables like 'character%'; show variables like '%char%';看看出现的结果：默认的是客户端和服务器都用了latin1，所以会乱码。2 修改my.cnf在/usr/share/mysql/ 中找到my.cnf的配置文件，拷贝其中的my-huge.cnf 到 /etc/  并命名为my.cnf mysql 优先选中 /etc/ 下的配置文件然后修改my.cnf:[client]default-character-set=utf8[mysqld]character_set_server=utf8character_set_client=utf8collation-server=utf8_general_ci[mysql]default-character-set=utf83、重新启动mysql但是原库的设定不会发生变化，参数修改之对新建的数据库生效4、已生成的库表字符集如何变更修改数据库的字符集mysql> alter database mytest character set 'utf8';修改数据表的字符集mysql> alter table user convert to  character set 'utf8';但是原有的数据如果是用非'utf8'编码的话，数据本身不会发生改变。

3.Mysql 的用户与权限管理

1、MySQL的用户管理

  1.创建用户create user zhang3 identified by '123123';表示创建名称为zhang3的用户，密码设为123123；2.查看用户select host,user,password,select_priv,insert_priv,drop_priv from mysql.user;select * from user\G;将 user 中的数据以行的形式显示出来(针对列很长的表可以采用这个方法 )host ：   表示连接类型% 表示所有远程通过 TCP方式的连接IP 地址 如 (192.168.1.2,127.0.0.1) 通过制定ip地址进行的TCP方式的连接机器名   通过制定i网络中的机器名进行的TCP方式的连接::1   IPv6的本地ip地址  等同于IPv4的 127.0.0.1localhost 本地方式通过命令行方式的连接 ，比如mysql -u xxx -p 123xxx 方式的连接。User:表示用户名同一用户通过不同方式链接的权限是不一样的。password ： 密码所有密码串通过 password(明文字符串) 生成的密文字符串。加密算法为MYSQLSHA1 ，不可逆 。mysql 5.7 的密码保存到 authentication_string 字段中不再使用password 字段。select_priv , insert_priv等 为该用户所拥有的权限。3.设置密码 修改当前用户的密码:set password =password('123456')修改某个用户的密码:update mysql.user set password=password('123456') where user='li4';flush privileges;   #所有通过user表的修改，必须用该命令才能生效。4.修改用户名：update mysql.user set user='li4' where user='wang5';flush privileges;   #所有通过user表的修改，必须用该命令才能生效。5.删除用户drop user li4 ;不要通过delete from  user u where user='li4' 进行删除，系统会有残留信息保留。

了解user表:

2、权限管理

授权命令：

grant 权限1,权限2,…权限n on 数据库名称.表名称 to 用户名@用户地址 identified by ‘连接口令’;
该权限如果发现没有该用户，则会直接新建一个用户。
比如
grant select,insert,delete,drop on atguigudb.* to li4@localhost  ;
#给li4用户用本地命令行方式下，授予atguigudb这个库下的所有表的插删改查的权限。grant all privileges on *.* to joe@'%'  identified by '123';
#授予通过网络方式登录的的joe用户 ，对所有库所有表的全部权限，密码设为123.
就算 all privileges 了所有权限，grant_priv 权限也只有 root 才能拥有。给 root 赋连接口令 grant all privileges on *.* to root@'%'  ;后新建的连接没有密码，需要设置密码才能远程连接。
update user set password=password('root') where user='root' and host='%';

收回权限:

授权命令：
revoke  权限1,权限2,…权限n on 数据库名称.表名称  from  用户名@用户地址 ;REVOKE ALL PRIVILEGES ON mysql.* FROM joe@localhost;
#若赋的全库的表就 收回全库全表的所有权限REVOKE select,insert,update,delete ON mysql.* FROM joe@localhost;
#收回mysql库下的所有表的插删改查权限对比赋予权限的方法。必须用户重新登录后才能生效

查看权限:

查看当前用户权限
show grants;查看某用户的全局权限
select  * from user ;查看某用户的某库的权限
select * from  db;查看某用户的某个表的权限
select * from tables_priv;

3、通过工具远程访问

1、先 ping 一下数据库服务器的ip 地址确认网络畅通。2、关闭数据库服务的防火墙service iptables stop3、 确认Mysql中已经有可以通过远程登录的账户select  * from mysql.user where user='li4' and host='%';如果没有用户,先执行如下命令：grant all privileges on *.*  to li4@'%'  identified by '123123';4、测试连接：

4.Mysql的一些杂项配置

1、大小写问题

    SHOW VARIABLES LIKE '%lower_case_table_names%' windows系统默认大小写不敏感，但是linux系统是大小写敏感的默认为0，大小写敏感。设置1，大小写不敏感。创建的表，数据库都是以小写形式存放在磁盘上，对于sql语句都是转换为小写对表和DB进行查找。设置2，创建的表和DB依据语句上格式存放，凡是查找都是转换为小写进行。 设置变量常采用 set lower_case_table_names = 1； 的方式，但此变量是只读权限，所以需要在配置文件中改。当想设置为大小写不敏感时，要在my.cnf这个配置文件 [mysqld] 中加入 lower_case_table_names = 1 ，然后重启服务器。但是要在重启数据库实例之前就需要将原来的数据库和表转换为小写，否则更改后将找不到数据库名。在进行数据库参数设置之前，需要掌握这个参数带来的影响，切不可盲目设置。

2、生产环境 sql_mode

    MySQL的sql_mode合理设置sql_mode是个很容易被忽视的变量，默认值是空值，在这种设置下是可以允许一些非法操作的，比如允许一些非法数据的插入。在生产环境必须将这个值设置为严格模式，所以开发、测试环境的数据库也必须要设置，这样在开发测试阶段就可以发现问题。使用 set sql_mode=ONLY_FULL_GROUP_BY; 的方式设置会将之前的设置覆盖掉同时设置多个限制：set sql_mode='ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO';sql_mode常用值如下： ONLY_FULL_GROUP_BY：对于GROUP BY聚合操作，如果在SELECT中的列，没有在GROUP BY中出现，那么这个SQL是不合法的，因为列不在GROUP BY从句中NO_AUTO_VALUE_ON_ZERO：该值影响自增长列的插入。默认设置下，插入0或NULL代表生成下一个自增长值。如果用户 希望插入的值为0，而该列又是自增长的，那么这个选项就有用了。STRICT_TRANS_TABLES：在该模式下，如果一个值不能插入到一个事务表中，则中断当前的操作，对非事务表不做限制NO_ZERO_IN_DATE：在严格模式下，不允许日期和月份为零NO_ZERO_DATE：设置该值，mysql数据库不允许插入零日期，插入零日期会抛出错误而不是警告。ERROR_FOR_DIVISION_BY_ZERO：在INSERT或UPDATE过程中，如果数据被零除，则产生错误而非警告。如果未给出该模式，那么数据被零除时MySQL返回NULLNO_AUTO_CREATE_USER：禁止GRANT创建密码为空的用户NO_ENGINE_SUBSTITUTION：如果需要的存储引擎被禁用或未编译，那么抛出错误。不设置此值时，用默认的存储引擎替代，并抛出一个异常PIPES_AS_CONCAT：将"||"视为字符串的连接操作符而非或运算符，这和Oracle数据库是一样的，也和字符串的拼接函数Concat相类似ANSI_QUOTES：启用ANSI_QUOTES后，不能用双引号来引用字符串，因为它被解释为识别符ORACLE：设置等同：PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS, NO_AUTO_CREATE_USER.

5.Mysql逻辑架构介绍

1、总体概览

和其它数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上，
插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。1.连接层
最上层是一些客户端和连接服务，包含本地sock通信和大多数基于客户端/服务端工具实现的类似于tcp/ip的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。2.服务层
2.1  Management Serveices & Utilities： 系统管理和控制工具
2.2  SQL Interface: SQL接口接受用户的SQL命令，并且返回用户需要查询的结果。比如select from就是调用SQL Interface
2.3 Parser: 解析器SQL命令传递到解析器的时候会被解析器验证和解析。
2.4 Optimizer: 查询优化器。SQL语句在查询之前会使用查询优化器对查询进行优化。 用一个例子就可以理解： select uid,name from user where  gender= 1;优化器来决定先投影还是先过滤。2.5 Cache和Buffer： 查询缓存。如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等缓存是负责读，缓冲负责写。3.引擎层
存储引擎层，存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。后面介绍MyISAM和InnoDB4.存储层
数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的交互。

2、查询说明

查询流程图:

mysql的查询流程大致是：
mysql客户端通过协议与mysql服务器建连接，发送查询语句，先检查查询缓存，如果命中(一模一样的sql才能命中)，直接返回结果，否则进行语句解析,也就是说，在解析查询之前，服务器会先访问查询缓存(query cache)——它存储SELECT语句以及相应的查询结果集。如果某个查询结果已经位于缓存中，服务器就不会再对查询进行解析、优化、以及执行。它仅仅将缓存中的结果返回给用户即可，这将大大提高系统的性能。

语法解析器和预处理：首先mysql通过关键字将SQL语句进行解析，并生成一颗对应的“解析树”。mysql解析器将使用mysql语法规则验证和解析查询；预处理器则根据一些mysql规则进一步检查解析数是否合法。查询优化器当解析树被认为是合法的了，并且由优化器将其转化成执行计划。一条查询可以有很多种执行方式，最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。。然后，mysql默认使用的BTREE索引，并且一个大致方向是:无论怎么折腾sql，至少在目前来说，mysql最多只用到表中的一个索引。

6.Mysql存储引擎

1、查看命令

看你的mysql现在已提供什么存储引擎:

 mysql> show engines;

看你的mysql当前默认的存储引擎:

 mysql> show variables like '%storage_engine%';

2、各个引擎简介

1、InnoDB存储引擎
InnoDB是MySQL的默认事务型引擎，它被设计用来处理大量的短期(short-lived)事务。除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。行级锁，适合高并发情况

2、MyISAM存储引擎
MyISAM提供了大量的特性，包括全文索引、压缩、空间函数(GIS)等，但MyISAM不支持事务和行级锁(myisam改表时会将整个表全锁住)，有一个毫无疑问的缺陷就是崩溃后无法安全恢复。

3、Archive引擎
Archive存储引擎只支持INSERT和SELECT操作，在MySQL5.1之前不支持索引。
Archive表适合日志和数据采集类应用。适合低访问量大数据等情况。
根据英文的测试结论来看，Archive表比MyISAM表要小大约75%，比支持事务处理的InnoDB表小大约83%。

4、Blackhole引擎
Blackhole引擎没有实现任何存储机制，它会丢弃所有插入的数据，不做任何保存。但服务器会记录Blackhole表的日志，所以可以用于复制数据到备库，或者简单地记录到日志。但这种应用方式会碰到很多问题，因此并不推荐。

5、CSV引擎
CSV引擎可以将普通的CSV文件作为MySQL的表来处理，但不支持索引。
CSV引擎可以作为一种数据交换的机制，非常有用。
CSV存储的数据直接可以在操作系统里，用文本编辑器，或者excel读取。

6、Memory引擎
如果需要快速地访问数据，并且这些数据不会被修改，重启以后丢失也没有关系，那么使用Memory表是非常有用。Memory表至少比MyISAM表要快一个数量级。(使用专业的内存数据库更快，如redis)

7、Federated引擎
Federated引擎是访问其他MySQL服务器的一个代理，尽管该引擎看起来提供了一种很好的跨服务器的灵活性，但也经常带来问题，因此默认是禁用的。

3、MyISAM和InnoDB

innodb 索引 使用 B+TREE myisam 索引使用 b-tree
innodb 主键为聚簇索引，基于聚簇索引的增删改查效率非常高。

对比项	MyISAM	InnoDB
主外键	不支持	支持
事务	不支持	支持
行表锁	表锁，即使操作一条记录也会锁住整个表，不适合高并发的操作	行锁,操作时只锁某一行，不对其它行有影响，适合高并发的操作
缓存	行锁,操作时只锁某一行，不对其它行有影响，适合高并发的操作	不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定性的影响
表空间	小	大
关注点	性能	事务
默认安装	Y	Y
用户表默认使用	N	Y
自带系统表使用	Y	N

4、阿里巴巴淘宝用的数据库

Percona 为 MySQL 数据库服务器进行了改进，在功能和性能上较 MySQL 有着很显著的提升。该版本提升了在高负载情况下的 InnoDB 的性能、为 DBA 提供一些非常有用的性能诊断工具；另外有更多的参数和命令来控制服务器行为。该公司新建了一款存储引擎叫xtradb完全可以替代innodb,并且在性能和并发上做得更好,阿里巴巴大部分mysql数据库其实使用的percona的原型加以修改。
AliSql+AliRedis

二. 索引优化分析

1. 索引简介

1.MySQL 索引的这些使用原则

https://mp.weixin.qq.com/s?__biz=MzA3ODg3OTk4OA==&mid=2651093607&idx=4&sn=b22714abdf12a7d5b1313e127c50d8ef&chksm=844cd7fcb33b5eeac0b13bf432e70ee04d4fac9a9bafb42146d5109d57796e6a8d1fcfa6fd4c&scene=126&sessionid=1582248951&key=fd81d0175d420d2648307403389fc5afa175d46701aef2dc7eb3321875d12e9483f8fe2a3c6ab25e2ef8f151253ba3ab52f4bb872fd0b7ed7c29c3886079a98f12ad82ecf27b6d423bde6ad9e7bb352d&ascene=1&uin=MjgyMjY0NTkxMQ%3D%3D&devicetype=Windows+10&version=6208006f&lang=zh_CN&exportkey=A%2BX8nMGEM6j%2BtIs6UUMTm18%3D&pass_ticket=4JI2uwB%2FO99vbyefKjYu4az3%2Fpms7erHAsByB2rTp4rkp9gmUZIxUuyqiH%2FRC5Ql

1、概念

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。
可以得到索引的本质: **索引是数据结构**。
可以简单理解为: **排好序的快速查找数据结构**。

 索引的目的在于提高查询效率，可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从上往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要a----z，如果我想找到Java开头的单词呢？或者Oracle开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？

一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上.

 我们平常所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉的)结构组织的索引。其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈稀索引(hash index)等。

优势:

 1.类似大学图书馆建书目索引，提高数据检索的效率，降低数据库的IO成本2.通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗

劣势:

 1.实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间的2.虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息3.索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句

2、哪些情况需要创建索引

 1.主键自动建立唯一索引2.频繁作为查询条件的字段应该创建索引(where 后面的语句)3.查询中与其它表关联的字段，外键关系建立索引A 表关联 B 表：A join B on 后面的连接条件 既 A 表查询 B 表的条件。所以 B 表被关联的字段建立索引能大大提高查询效率因为在 join 中，join 左边的表会用每一个字段去遍历 B 表的所有的关联数据，相当于一个查询操作4.单键/组合索引的选择问题，who？(在高并发下倾向创建组合索引)5.查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度group by 和 order by 后面的字段有索引大大提高效率6.查询中统计或者分组字段

3、哪些情况不要创建索引

 1.表记录太少2.经常增删改的表Why:提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件3.Where条件里用不到的字段不创建索引索引建多了影响 增删改 的效率4.数据重复且分布平均的表字段，因此应该只为最经常查询和最经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。

2. mysql索引结构

1、BTree索引

Myisam普通索引

原理图:

关于时间复杂度:

 同一问题可用不同算法解决，而一个算法的质量优劣将影响到算法乃至程序的效率。算法分析的目的在于选择合适算法和改进算法。

 1  N  logN 分别表示数据与查询次数之间的关系。常数  1*c  表示查询最快的方式。查询次数不随数据的增加而增加变量  N    表示查询次数随数据数量的增加而增加对数  logN 表示查询次数与数据数量成对数关系。 介于常数与 N 之间。n*logN 表示使用的复合方法。

2、B+Tree索引

innodb的普通索引

B+TREE 第二级的 数据并不能直接取出来，只作索引使用。在内存有限的情况下，查询效率高于 B-TREE
B-TREE 第二级可以直接取出来，树形结构比较重，在内存无限大的时候有优势。

B树和B+树的区别:

 B+Tree与B-Tree 的区别：结论在内存有限的情况下，B+TREE 永远比 B-TREE好。无限内存则后者方便1）B-树的关键字和记录是放在一起的，叶子节点可以看作外部节点，不包含任何信息；B+树叶子节点中只有关键字和指向下一个节点的索引，记录只放在叶子节点中。(一次查询可能进行两次i/o操作)2）在B-树中，越靠近根节点的记录查找时间越快，只要找到关键字即可确定记录的存在；而B+树中每个记录的查找时间基本是一样的，都需要从根节点走到叶子节点，而且在叶子节点中还要再比较关键字。从这个角度看B-树的性能好像要比B+树好，而在实际应用中却是B+树的性能要好些。因为B+树的非叶子节点不存放实际的数据，这样每个节点可容纳的元素个数比B-树多，树高比B-树小，这样带来的好处是减少磁盘访问次数。尽管B+树找到一个记录所需的比较次数要比B-树多，但是一次磁盘访问的时间相当于成百上千次内存比较的时间，因此实际中B+树的性能可能还会好些，而且B+树的叶子节点使用指针连接在一起，方便顺序遍历（例如查看一个目录下的所有文件，一个表中的所有记录等），这也是很多数据库和文件系统使用B+树的缘故。 思考：为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引？ 1) B+树的磁盘读写代价更低 B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。 2) B+树的查询效率更加稳定 由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

3、聚簇索引与非聚簇索引

聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。
术语‘聚簇’表示数据行和相邻的键值进错的存储在一起。
如下图，左侧的索引就是聚簇索引，因为数据行在磁盘的排列和索引排序保持一致。

聚簇索引的好处：

 按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多个数据块中提取数据，所以节省了大量的io操作。

聚簇索引的限制：

 对于mysql数据库目前只有innodb数据引擎支持聚簇索引，而Myisam并不支持聚簇索引。由于数据物理存储排序方式只能有一种，所以每个Mysql的表只能有一个聚簇索引。一般情况下就是该表的主键。
为了充分利用聚簇索引的聚簇的特性，所以innodb表的主键列尽量选用有序的顺序id，而不建议用无序的id，比如uuid这种。（参考聚簇索引的好处。）

 这里说明了主键索引为何采用自增的方式：1、业务需求，有序。2、能使用到聚簇索引

4、full-text全文索引

全文索引（也称全文检索）是目前搜索引擎使用的一种关键技术。它能够利用【分词技术】等多种算法智能分析出文本文字中关键词的频率和重要性，然后按照一定的算法规则智能地筛选出我们想要的搜索结果。

    CREATE TABLE `article` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`title` varchar(200) DEFAULT NULL,`content` text,PRIMARY KEY (`id`),FULLTEXT KEY `title` (`title`,`content`)) ENGINE=MyISAM DEFAULT CHARSET=utf8;不同于like方式的的查询：SELECT * FROM article WHERE content LIKE ‘%查询字符串%’;全文索引用match+against方式查询：SELECT * FROM article WHERE MATCH(title,content) AGAINST (‘查询字符串’);明显的提高查询效率。

限制：
mysql5.6.4以前只有Myisam支持，5.6.4版本以后innodb才支持，但是官方版本不支持中文分词，需要第三方分词插件。
5.7以后官方支持中文分词。

随着大数据时代的到来，关系型数据库应对全文索引的需求已力不从心，逐渐被 solr,elasticSearch等专门的搜索引擎所替代。

5、Hash索引

Hash索引只有Memory, NDB两种引擎支持，Memory引擎默认支持Hash索引，如果多个hash值相同，出现哈希碰撞，那么索引以链表方式存储。
NoSql采用此中索引结构。

6、R-Tree索引

R-Tree在mysql很少使用，仅支持geometry数据类型，支持该类型的存储引擎只有myisam、bdb、innodb、ndb、archive几种。相对于b-tree，r-tree的优势在于范围查找。

3. mysql索引分类

1、主键索引

设定为主键后数据库会自动建立索引，innodb为聚簇索引

语法:

    随表一起建索引：CREATE TABLE customer (id INT(10) UNSIGNED  AUTO_INCREMENT ,customer_no VARCHAR(200),customer_name VARCHAR(200),PRIMARY KEY(id) );unsigned (无符号的)使用  AUTO_INCREMENT 关键字的列必须有索引(只要有索引就行)。CREATE TABLE customer2 (id INT(10) UNSIGNED   ,customer_no VARCHAR(200),customer_name VARCHAR(200),PRIMARY KEY(id) );单独建主键索引：ALTER TABLE customer add PRIMARY KEY customer(customer_no);  删除建主键索引：ALTER TABLE customer drop PRIMARY KEY ;  修改建主键索引：必须先删除掉(drop)原索引，再新建(add)索引

2、单值索引

即一个索引只包含单个列，一个表可以有多个单列索引

 索引建立成哪种索引类型？根据数据引擎类型自动选择的索引类型除开 innodb 引擎主键默认为聚簇索引 外。 innodb 的索引都采用的 B+TREEmyisam 则都采用的 B-TREE索引

语法:

    随表一起建索引：CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT ,customer_no VARCHAR(200),customer_name VARCHAR(200),PRIMARY KEY(id),KEY (customer_name)  );随表一起建立的索引 索引名同 列名(customer_name)单独建单值索引：CREATE  INDEX idx_customer_name ON customer(customer_name); 删除索引：DROP INDEX idx_customer_name ;

3、唯一索引

索引列的值必须唯一，但允许有空值

语法:

    随表一起建索引：CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT,customer_no VARCHAR(200),customer_name VARCHAR(200),PRIMARY KEY(id),KEY (customer_name),UNIQUE (customer_no));建立 唯一索引时必须保证所有的值是唯一的（除了null），若有重复数据，会报错。  单独建唯一索引：CREATE UNIQUE INDEX idx_customer_no ON customer(customer_no); 删除索引：DROP INDEX idx_customer_no on customer ;

4、复合索引

即一个索引包含多个列

    在数据库操作期间，复合索引比单值索引所需要的开销更小(对于相同的多个列建索引)当表的行数远大于索引列的数目时可以使用复合索引

语法:

    随表一起建索引：CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT,customer_no VARCHAR(200),customer_name VARCHAR(200),PRIMARY KEY(id),KEY (customer_name),UNIQUE (customer_name),KEY (customer_no,customer_name));单独建索引：CREATE INDEX idx_no_name ON customer(customer_no,customer_name); 删除索引：DROP INDEX idx_no_name  on customer ;

5、基本语法

创建:

 CREATE [UNIOUE] INDEX indexName ON mytable (columnname(length)); ALTER TABLE mytable ADD  [UNIQUE ]  INDEX [indexName] ON (columnname(length))

删除:

 DROP INDEX [indexName] ON mytable;

查看:

 SHOW INDEX FROM table_name

    non_unique: 是否是唯一索引  1：是  0：不是seq_in_index:列 在索引中的 序列。针对符合索引(一个索引对应多个列)。针对同一个复合索引 按照创建复合索引时的顺序进行排序collation:cardinality:sub_part:packed:Null:是否允许 null 值comment:index_comment:

使用ALTER命令:

 有四种方式来添加数据表的索引：ALTER TABLE tbl_name ADD PRIMARY KEY (column_list): 该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL。ALTER TABLE tbl_name ADD UNIQUE index_name (column_list): 这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）。ALTER TABLE tbl_name ADD INDEX index_name (column_list): 添加普通索引，索引值可出现多次。ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list): 该语句指定了索引为 FULLTEXT ，用于全文索引。

4.Explain性能分析

1、MySQL常见瓶颈

产生位置	原因
CPU	SQL中对大量数据进行比较、关联、排序、分组
IO	实例内存满足不了缓存数据或排序等需要，导致产生大量物理 IO。查询执行效率低，扫描过多数据行。
锁	不适宜的锁的设置，导致线程阻塞，性能下降。死锁，线程之间交叉调用资源，导致死锁，程序卡住。
服务器硬件的性能瓶颈	top,free, iostat和vmstat来查看系统的性能状态

2、Explain简介

Explain:  查看执行计划使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈官网介绍:  http://dev.mysql.com/doc/refman/5.5/en/explain-output.html作用:

 1.表的读取顺序2.哪些索引可以使用3.数据读取操作的操作类型4.哪些索引被实际使用5.表之间的引用6.每张表有多少行被优化器查询

3、使用方法

使用方法为:  Explain + SQL语句执行计划包含的信息:

建表脚本:

 CREATE TABLE t1(id INT(10) AUTO_INCREMENT,content  VARCHAR(100) NULL ,  PRIMARY KEY (id));CREATE TABLE t2(id INT(10) AUTO_INCREMENT,content  VARCHAR(100) NULL ,  PRIMARY KEY (id));CREATE TABLE t3(id INT(10) AUTO_INCREMENT,content  VARCHAR(100) NULL ,  PRIMARY KEY (id));CREATE TABLE t4(id INT(10) AUTO_INCREMENT,content  VARCHAR(100) NULL ,  PRIMARY KEY (id));INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000)));INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000)));INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000)));INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));

4、各字段解释

1.id

select查询的序列号,包含一组数字，表示查询中执行select子句或操作表的顺序

三种情况:

id相同，执行顺序由上至下:

    id相同，执行顺序由上至下  此例中 先执行 where 后的第一条语句 t1.id = t2.id 通过 t1.id 关联 t2.id 。 而  t2.id 的结果建立在 t2.id=t3.id 的基础之上。

id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行:

 id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行

id相同不同，同时存在:

    id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行衍生表 = derived2 --> derived + 2 （2 表示由 id =2 的查询衍生出来的表。type 肯定是 all ，因为衍生的表没有建立索引）

2.select_type

查询的类型，主要是用于区别 普通查询、联合查询、子查询等的复杂查询

select_type字段:

1.SIMPLE:

简单的 select 查询,查询中不包含子查询或者UNION

2.PRIMARY:

查询中若包含任何复杂的子部分，最外层查询则被标记为Primary

3.DERIVED:

在FROM列表中包含的子查询被标记为DERIVED(衍生),MySQL会递归执行这些子查询, 把结果放在临时表里。    DERIVED 既查询通过子查询查出来的 临时表

4.SUBQUERY:

在SELECT或WHERE列表中包含了子查询

5.DEPENDENT SUBQUERY:

 在SELECT或WHERE列表中包含了子查询,子查询基于外层

    dependent subquery 与 subquery 的区别依赖子查询 ： 子查询结果为 多值子查询：查询结果为 单值

6.UNCACHEABLE SUBQUREY:

无法被缓存的子查询图1 中的 @@ 表示查的环境参数 。没办法缓存

7.UNION:

若第二个SELECT出现在UNION之后，则被标记为UNION；
若UNION包含在FROM子句的子查询中,外层SELECT将被标记为：DERIVED

8.UNION RESULT:

UNION RESULT 两个语句执行完后的结果

3.table

显示这一行的数据是关于哪张表的

4.type

显示查询使用了何种类型,
从最好到最差依次是：system>const>eq_ref>ref>range>index>ALL

type字段:

 type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range(尽量保证) > index > ALL 常见为:system>const>eq_ref>ref>range>index>ALL一般来说，得保证查询至少达到range级别，最好能达到ref。

1.system

表只有一行记录（等于系统表），这是const类型的特列，平时不会出现，这个也可以忽略不计

2.const

表示通过索引一次就找到了,const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快
如将主键置于where列表中，MySQL就能将该查询转换为一个常量

3.eq_ref

唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描

4.ref

非唯一性索引扫描，返回匹配某个单独值的所有行.
本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，
它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体

5.range

只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引
一般就是在你的where语句中出现了between、<、>、in等的查询
这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引。

6.index

Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常比ALL快，因为索引文件通常比数据文件小。
(也就是说虽然all和Index都是读全表，但index是从索引中读取的，而all是从硬盘中读的)

7.all

Full Table Scan，将遍历全表以找到匹配的行

8.index_merge

在查询过程中需要多个索引组合使用，通常出现在有 or 的关键字的sql中

9.ref_or_null

对于某个字段既需要关联条件，也需要null值得情况下。查询优化器会选择用ref_or_null连接查询。

10.index_subquery

利用索引来关联子查询，不再全表扫描。

11.unique_subquery

该联接类型类似于index_subquery。 子查询中的唯一索引

5.possible_keys

显示可能应用在这张表中的索引，一个或多个。
查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用

6.key

实际使用的索引。如果为NULL，则没有使用索引查询中若使用了覆盖索引，则该索引和查询的select字段重叠  对比下图两个 sql 语句。和 key 的值：当查询具体某一字段时，且那个字段有索引时，key 值会显示为索引

7.key_len

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。 EXPLAIN SELECT * FROM emp WHERE emp.deptno=109 AND emp.ename='AvDEjl'

如何计算

总结一下：char(30) utf8 --> key_len = 30*3 +1  表示 utf8 格式需要  *3 (跟数据类型有关) 允许为 NULL  +1  ，不允许 +0动态类型 +2  (动态类型包括 : varchar , detail text() 截取字符窜)

第一组：key_len=deptno(int)+null + ename(varchar(20)*3+动态  =4+1+20*3+2= 67
第二组：key_len=deptno(int)+null=4+1=5

key_len字段能够帮你检查是否充分的利用上了索引:

     RESET QUERY CACHE ;             EXPLAIN SELECT emp.deptno,COUNT(*) c FROM emp    WHERE emp.ename LIKE 'a%' AND emp.deptno=109GROUP BY emp.deptnoHAVING c >2ORDER BY c DESC同样的使用了索引但是索引的涉及的字段却不同。

8.ref

显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值

9.rows

rows列显示MySQL认为它执行查询时必须检查的行数。越少越好

8.Extra

包含不适合在其他列中显示但十分重要的额外信息

1.Using filesort

说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。
MySQL中无法利用索引完成的排序操作称为“文件排序” 出现filesort的情况：

优化后，不再出现filesort的情况：(给 ename 加上了索引):

查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度分情况：当通过前面的查询语句 筛选大部分条件后，只剩下很少的数据。using filesort 性能影响不大。需要综合考虑

2.Using temporary

使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。优化前存在 using  temporary 和 using  filesort:

create index idx_deptno_ename on emp(deptno,ename) 后解决
优化前存在的 using  temporary 和 using  filesort 不在，性能发生明显变化：

3.Using index

表示相应的select操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错！
如果同时出现using where，表明索引被用来执行索引键值的查找;
如果没有同时出现using where，表明索引只是用来读取数据而非利用索引执行查找。  覆盖索引(Covering Index):

    索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据;当能通过读取索引就可以得到想要的数据，那就不需要读取行了。①一个索引 ②包含了(或覆盖了)[select子句]与查询条件[Where子句]中 ③所有需要的字段就叫做覆盖索引。上句红字理解：select id , name from t_xxx where age=18;有一个组合索引  idx_id_name_age_xxx 包含了(覆盖了)，id,name,age三个字段。查询时直接将建立了索引的列读取出来了，而不需要去查找所在行的其他数据。所以很高效。(个人认为：在数据量较大，固定字段查询情况多时可以使用这种方法。)注意：如果要使用覆盖索引，一定要注意select列表中只取出需要的列，不可select *，因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降。

4.Using where

表明使用了where过滤

5.using join buffer

使用了连接缓存：

    出现在当两个连接时驱动表(被连接的表,left join 左边的表。inner join 中数据少的表) 没有索引的情况下。给驱动表建立索引可解决此问题。且 type 将改变成 ref

6.impossible where

where子句的值总是false，不能用来获取任何元组

7.select tables optimized away

在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。  在innodb中：

在innodb中：

    myisam 中会维护 总行数 (还有其他参数)这个参数，所以在执行查询时不会进行全表扫描。而是直接读取这个数。但会对增删产生一定的影响。根据业务情况决定谁好谁坏innodb 中没有这个机制。

5.查询优化

1、单表查询优化

建表SQL:

 CREATE TABLE IF NOT EXISTS `article` (`id` INT(10) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,`author_id` INT(10) UNSIGNED NOT NULL,`category_id` INT(10) UNSIGNED NOT NULL,`views` INT(10) UNSIGNED NOT NULL,`comments` INT(10) UNSIGNED NOT NULL,`title` VARBINARY(255) NOT NULL,`content` TEXT NOT NULL);INSERT INTO `article`(`author_id`, `category_id`, `views`, `comments`, `title`, `content`) VALUES(1, 1, 1, 1, '1', '1'),(2, 2, 2, 2, '2', '2'),(1, 1, 3, 3, '3', '3');SELECT * FROM article;

案例:

 #查询 category_id 为1 且  comments 大于 1 的情况下,views 最多的 article_id。 EXPLAIN SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;#结论：很显然,type 是 ALL,即最坏的情况。Extra 里还出现了 Using filesort,也是最坏的情况。优化是必须的。#开始优化：# 1.1 新建索引+删除索引#ALTER TABLE `article` ADD INDEX idx_article_ccv ( `category_id` , `comments`, `views` );create index idx_article_ccv on article(category_id,comments,views);DROP INDEX idx_article_ccv ON article# 1.2 第2次EXPLAINEXPLAIN SELECT id,author_id FROM `article` WHERE category_id = 1 AND comments >1 ORDER BY views DESC LIMIT 1;#结论：#type 变成了 range,这是可以忍受的。但是 extra 里使用 Using filesort 仍是无法接受的。#但是我们已经建立了索引,为啥没用呢?#这是因为按照 BTree 索引的工作原理,# 先排序 category_id,# 如果遇到相同的 category_id 则再排序 comments,如果遇到相同的 comments 则再排序 views。#当 comments 字段在联合索引里处于中间位置时,#因comments > 1 条件是一个范围值(所谓 range),#MySQL 无法利用索引再对后面的 views 部分进行检索,即 range 类型查询字段后面的索引无效。# 1.3 删除第一次建立的索引DROP INDEX idx_article_ccv ON article;# 1.4 第2次新建索引#ALTER TABLE `article` ADD INDEX idx_article_cv ( `category_id` , `views` ) ;create index idx_article_cv on article(category_id,views);# 1.5 第3次EXPLAINEXPLAIN SELECT id,author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;#结论：可以看到,type 变为了 ref,Extra 中的 Using filesort 也消失了,结果非常理想。DROP INDEX idx_article_cv ON article;

2、关联查询优化

建表SQL:

    CREATE TABLE IF NOT EXISTS `class` (`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,`card` INT(10) UNSIGNED NOT NULL,PRIMARY KEY (`id`));CREATE TABLE IF NOT EXISTS `book` (`bookid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,`card` INT(10) UNSIGNED NOT NULL,PRIMARY KEY (`bookid`));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));

案例:

    # 下面开始explain分析EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;#结论：type 有All# 添加索引优化ALTER TABLE `book` ADD INDEX Y ( `card`);# 第2次explainEXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;#可以看到第二行的 type 变为了 ref,rows 也变成了优化比较明显。#这是由左连接特性决定的。LEFT JOIN 条件用于确定如何从右表搜索行,左边一定都有,#所以右边是我们的关键点,一定需要建立索引。# 删除旧索引 + 新建 + 第3次explainDROP INDEX Y ON book;ALTER TABLE class ADD INDEX X (card);EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;

建议:

1、保证被驱动表的join字段已经被索引被驱动表  join 后的表为被驱动表  (需要被查询)2、left join 时，选择小表作为驱动表，大表作为被驱动表。left join 时一定是左边是驱动表，右边是被驱动表3、inner join 时，mysql会自己帮你把小结果集的表选为驱动表。mysql 自动选择。小表作为驱动表。因为 驱动表无论如何都会被全表扫描？。所以扫描次数越少越好4、子查询尽量不要放在被驱动表，有可能使用不到索引。select a.name ,bc.name from t_emp a left join(select b.id , c.name from t_dept b inner join t_emp c on b.ceo = c.id) bc on bc.id = a.deptid.上段查询中用到了子查询，必然 bc 表没有索引。肯定会进行全表扫描上段查询 可以直接使用 两个 left join 优化select a.name , c.name from t_emp aleft join t_dept b on a.deptid = b.idleft join t_emp c on b.ceo=c.id所有条件都可以使用到索引若必须用到子查询，可将子查询设置为驱动表，，因为驱动表的type 肯定是 all，而子查询返回的结果表没有索引，必定也是all

3、order by关键字优化

ORDER BY子句，尽量使用Index方式排序,避免使用FileSort方式排序

建表SQL:

    CREATE TABLE tblA(id int primary key not null auto_increment,age INT,birth TIMESTAMP NOT NULL,name varchar(200));INSERT INTO tblA(age,birth,name) VALUES(22,NOW(),'abc');INSERT INTO tblA(age,birth,name) VALUES(23,NOW(),'bcd');INSERT INTO tblA(age,birth,name) VALUES(24,NOW(),'def');CREATE INDEX idx_A_ageBirth ON tblA(age,birth,name);SELECT * FROM tblA;

Case1:

Case2:

 MySQL支持二种方式的排序，FileSort和Index，Index效率高.它指MySQL扫描索引本身完成排序。FileSort方式效率较低。  ORDER BY满足两情况，会使用Index方式排序:  ORDER BY 语句使用索引最左前列使用Where子句与Order BY子句条件列组合满足索引最左前列where子句中如果出现索引的范围查询(即explain中出现range)会导致order by索引失效

尽可能在索引列上完成排序操作，遵照索引建的最佳左前缀:

双路排序和单路排序

如果不在索引列上，filesort有两种算法：mysql就要启动双路排序和单路排序

1.双路排序

MySQL 4.1之前是使用双路排序,字面意思就是两次扫描磁盘，最终得到数据，
读取行指针和orderby列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出多路排序需要借助 磁盘来进行排序。所以 取数据，排好了取数据。两次 io操作。比较慢
单路排序 ，将排好的数据存在内存中，省去了一次 io 操作，所以比较快，但是需要内存空间足够。 从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。取一批数据，要对磁盘进行了两次扫描，众所周知，I\O是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序。

2.单路排序

从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间，因为它把每一行都保存在内存中了。

3.结论及引申出的问题

由于单路是后出的，总体而言好过双路在sort_buffer中，方法B比方法A要多占用很多空间，因为方法B是把所有字段都取出, 所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序（创建tmp文件，多路合并），排完再取sort_buffer容量大小，再排……从而多次I/O。
本来想省一次I/O操作，反而导致了大量的I/O操作，反而得不偿失。

4.优化策略

增大sort_buffer_size参数的设置 (用于单路排序的内存大小)

增大max_length_for_sort_data参数的设置(单次排序字段大小。(单次排序请求))

去掉select 后面不需要的字段(select 后的多了，排序的时候也会带着一起，很占内存，所以去掉没有用的)

原因:

提高Order By的速度1. Order by时select * 是一个大忌只Query需要的字段， 这点非常重要。在这里的影响是：1.1 当Query的字段大小总和小于max_length_for_sort_data 而且排序字段不是 TEXT|BLOB 类型时，会用改进后的算法——单路排序， 否则用老算法——多路排序。1.2 两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建tmp文件进行合并排序，导致多次I/O，但是用单路排序算法的风险会更大一些,所以要提高sort_buffer_size。2. 尝试提高 sort_buffer_size
不管用哪种算法，提高这个参数都会提高效率，当然，要根据系统的能力去提高，因为这个参数是针对每个进程的3. 尝试提高 max_length_for_sort_data
提高这个参数， 会增加用改进算法的概率。但是如果设的太高，数据总容量超出sort_buffer_size的概率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率.

4、limit分页查询的优化

EXPLAIN SELECT SQL_NO_CACHE * FROM emp ORDER BY deptno LIMIT 10000,40

那我们就给deptno这个字段加上索引吧。

然并卵。

优化：先利用覆盖索引把要取的数据行的主键取到，然后再用这个主键列与数据表做关联：(查询的数据量小了后)
EXPLAIN SELECT SQL_NO_CACHE * FROM emp INNER JOIN (SELECT id FROM emp e ORDER BY deptno LIMIT 10000,40) a ON a.id=emp.id

最后比较一下查询速度：
优化前：

优化后：

实践证明： ①、order by 后的字段（XXX）有索引 ②、sql 中有 limit 时，
当 select id 或 XXX字段索引包含字段时，显示 using index
当 select 后的字段含有 bouder by 字段索引不包含的字段时，将显示 using filesort

5、GROUP BY关键字优化

group by实质是先排序后进行分组，遵照索引建的最佳左前缀当无法使用索引列，增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置where高于having，能写在where限定的条件就不要去having限定了。

6、去重优化

尽量不要使用 distinct 关键字去重：优化

    t_mall_sku 表:id  shp_id      kcdz                ------  ------ --------------------3       1    北京市昌平区  4       1    北京市昌平区  5       5    北京市昌平区  6       3       重庆              8       8     天津      例子：select kcdz form t_mall_sku where id in( 3,4,5,6,8 )  将产生重复数据，select distinct kcdz form t_mall_sku where id in( 3,4,5,6,8 ) 使用 distinct 关键字去重消耗性能优化： select  kcdz form t_mall_sku where id in( 3,4,5,6,8 )  group by kcdz 能够利用到索引

6.使用索引

一般性建议:

    对于单键索引，尽量选择针对当前query过滤性更好的索引在选择组合索引的时候，当前Query中过滤性最好的字段在索引字段顺序中，位置越靠前越好。(避免索引过滤性好的索引失效)在选择组合索引的时候，尽量选择可以能够包含当前query中的where字句中更多字段的索引尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的

接下来介绍常见索引失效(案例):

建表SQL:

    CREATE TABLE staffs (id INT PRIMARY KEY AUTO_INCREMENT,NAME VARCHAR (24)  NULL DEFAULT '' COMMENT '姓名',age INT NOT NULL DEFAULT 0 COMMENT '年龄',pos VARCHAR (20) NOT NULL DEFAULT '' COMMENT '职位',add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间') CHARSET utf8 COMMENT '员工记录表' ;INSERT INTO staffs(NAME,age,pos,add_time) VALUES('z3',22,'manager',NOW());INSERT INTO staffs(NAME,age,pos,add_time) VALUES('July',23,'dev',NOW());INSERT INTO staffs(NAME,age,pos,add_time) VALUES('2000',23,'dev',NOW());INSERT INTO staffs(NAME,age,pos,add_time) VALUES(null,23,'dev',NOW());SELECT * FROM staffs;ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name, age, pos);

1、全值匹配我最爱

2、最佳左前缀法则

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。EXPLAIN SELECT * FROM staffs WHERE pos = 'dev';

3、不在索引列上操作

不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描EXPLAIN SELECT * FROM staffs WHERE left(NAME,4) = 'July';

4、索引范围条件之右的列无效

存储引擎不能使用索引中范围条件右边的列范围 若有索引则能使用到索引，范围条件右边的索引会失效(范围条件右边与范围条件使用的同一个组合索引，右边的才会失效。若是不同索引则不会失效)

5、尽量使用覆盖索引

尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减少select *

6、使用不等于无法使用索引

mysql 在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描使用 != 和 <> 的字段索引失效( != 针对数值类型。 <> 针对字符类型
前提 where and 后的字段在混合索引中的位置比比当前字段靠后  where age != 10 and name='xxx'  ,这种情况下，mysql自动优化，将 name='xxx' 放在 age ！=10 之前，name 依然能使用索引。只是 age 的索引失效)

7、is not null 无法使用索引

is not null 也无法使用索引,但是is null是可以使用索引的

8、like以通配符开头索引失效

like以通配符开头('%abc...')mysql索引失效会变成全表扫描的操作

问题：解决like '%字符串%'时索引不被使用的方法？

    CREATE TABLE `tbl_user` (`id` INT(11) NOT NULL AUTO_INCREMENT,`NAME` VARCHAR(20) DEFAULT NULL,`age` INT(11) DEFAULT NULL,`email` VARCHAR(20) DEFAULT NULL,PRIMARY KEY (`id`)) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;#drop table tbl_userINSERT INTO tbl_user(NAME,age,email) VALUES('1aa1',21,'b@163.com');INSERT INTO tbl_user(NAME,age,email) VALUES('2aa2',222,'a@163.com');INSERT INTO tbl_user(NAME,age,email) VALUES('3aa3',265,'c@163.com');INSERT INTO tbl_user(NAME,age,email) VALUES('4aa4',21,'d@163.com');INSERT INTO tbl_user(NAME,age,email) VALUES('aa',121,'e@163.com');#before indexEXPLAIN SELECT NAME,age    FROM tbl_user WHERE NAME LIKE '%aa%';EXPLAIN SELECT id    FROM tbl_user WHERE NAME LIKE '%aa%';EXPLAIN SELECT NAME     FROM tbl_user WHERE NAME LIKE '%aa%';EXPLAIN SELECT age   FROM tbl_user WHERE NAME LIKE '%aa%';EXPLAIN SELECT id,NAME    FROM tbl_user WHERE NAME LIKE '%aa%';EXPLAIN SELECT id,NAME,age FROM tbl_user WHERE NAME LIKE '%aa%';EXPLAIN SELECT NAME,age FROM tbl_user WHERE NAME LIKE '%aa%';EXPLAIN SELECT *     FROM tbl_user WHERE NAME LIKE '%aa%';EXPLAIN SELECT id,NAME,age,email  FROM tbl_user WHERE NAME LIKE '%aa%';#create indexCREATE INDEX idx_user_nameAge ON tbl_user(NAME,age);#DROP INDEX idx_user_nameAge ON tbl_user#after indexEXPLAIN SELECT * FROM tbl_user WHERE NAME =800 AND age = 33;

9、字符串不加单引号索引失效

底层进行转换使索引失效，使用了函数造成索引失效

10、or连接时会索引失效

少用or,用它来连接时会索引失效

11、小总结

假设index(a,b,c)

Where语句	索引是否被使用
where a = 3	Y,使用到a
where a = 3 and b = 5	Y,使用到a，b
where a = 3 and b = 5 and c = 4	Y,使用到a,b,c
where b = 3 或者 where b = 3 and c = 4 或者 where c = 4	N
where a = 3 and c = 5	使用到a，但是c不可以，b中间断了
where a = 3 and b > 4 and c = 5	使用到a和b， c不能用在范围之后，b后断了
where a = 3 and b like ‘kk%’ and c = 4	Y,使用到a,b,c
where a = 3 and b like ‘%kk’ and c = 4	Y,只用到a
where a = 3 and b like ‘%kk%’ and c = 4	Y,只用到a
where a = 3 and b like ‘k%kk%’ and c = 4	Y,使用到a,b,c

三.查询截取分析

1、慢查询日志

MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上的语句。由他来查看哪些SQL超出了我们的最大忍耐时间值，比如一条sql执行超过5秒钟，我们就算慢SQL，希望能收集超过5秒的sql，结合之前explain进行全面分析。默认情况下，MySQL数据库没有开启慢查询日志，需要我们手动来设置这个参数。当然，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件

1.查看是否开启及如何开启

默认情况下slow_query_log的值为OFF，表示慢查询日志是禁用的，可以通过设置slow_query_log的值来开启

 SHOW VARIABLES LIKE '%slow_query_log%';

使用set global slow_query_log=1开启了慢查询日志只对当前数据库生效，如果MySQL重启后则会失效。

全局变量设置，对当前连接不影响

对当前连接立刻生效

如果要永久生效，就必须修改配置文件my.cnf（其它系统变量也是如此）修改my.cnf文件，[mysqld]下增加或修改参数
slow_query_log 和slow_query_log_file后，然后重启MySQL服务器。也即将如下两行配置进my.cnf文件

 slow_query_log =1slow_query_log_file=/var/lib/mysql/atguigu-slow.log

关于慢查询的参数slow_query_log_file ，它指定慢查询日志文件的存放路径，系统默认会给一个缺省的文件host_name-slow.log（如果没有指定参数slow_query_log_file的话）

2.那么开启了慢查询日志后，什么样的SQL才会记录到慢查询日志里面呢？

这个是由参数long_query_time控制，默认情况下long_query_time的值为10秒，
命令：

 SHOW VARIABLES LIKE 'long_query_time%';

可以使用命令修改，也可以在my.cnf参数里面修改。假如运行时间正好等于long_query_time的情况，并不会被记录下来。也就是说，在mysql源码里是判断大于long_query_time，而非大于等于。

3.设置慢查询的阙值时间

使用命令

 set global long_query_time=1

修改为阙值到1秒钟的就是慢sql

修改后发现long_query_time并没有改变。

为什么设置后看不出变化？

需要重新连接或新开一个会话才能看到修改值。

 SHOW VARIABLES LIKE 'long_query_time%';

或者通过set session long_query_time=1来改变当前session变量;

4.记录慢SQL并后续分析

实验一条慢sql

跟踪日志信息

5.查询当前系统中有多少条慢查询记录

 show global status like '%Slow_queries%';

6.配置版

    【mysqld】下配置：slow_query_log=1;slow_query_log_file=/var/lib/mysql/atguigu-slow.loglong_query_time=3;log_output=FILE

2、日志分析工具mysqldumpslow

在生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具mysqldumpslow。查看mysqldumpslow的帮助信息

 mysqldumpslow --help

工作常用参考:

    得到返回记录集最多的10个SQLmysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log得到访问次数最多的10个SQLmysqldumpslow -s c -t 10 /var/lib/mysql/atguigu-slow.log得到按照时间排序的前10条里面含有左连接的查询语句mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/atguigu-slow.log另外建议在使用这些命令时结合 | 和more 使用 ，否则有可能出现爆屏情况mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log | more

3、批量数据脚本

1.建表

    # 新建库create database bigData;use bigData;#1 建表deptCREATE TABLE dept(  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,  deptno MEDIUMINT UNSIGNED NOT NULL DEFAULT 0,   dname VARCHAR(20) NOT NULL DEFAULT "",  loc VARCHAR(13) NOT NULL DEFAULT ""  ) ENGINE=INNODB DEFAULT CHARSET=UTF8 ;  #2 建表empCREATE TABLE emp(  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,  empno MEDIUMINT UNSIGNED NOT NULL DEFAULT 0, /*编号*/  ename VARCHAR(20) NOT NULL DEFAULT "", /*名字*/  job VARCHAR(9) NOT NULL DEFAULT "",/*工作*/  mgr MEDIUMINT UNSIGNED NOT NULL DEFAULT 0,/*上级编号*/  hiredate DATE NOT NULL,/*入职时间*/  sal DECIMAL(7,2) NOT NULL,/*薪水*/  comm DECIMAL(7,2) NOT NULL,/*红利*/  deptno MEDIUMINT UNSIGNED NOT NULL DEFAULT 0 /*部门编号*/  )ENGINE=INNODB DEFAULT CHARSET=UTF8 ;

2.设置参数log_bin_trust_function_creators

    创建函数，假如报错：This function has none of DETERMINISTIC......# 由于开启过慢查询日志，因为我们开启了 bin-log, 我们就必须为我们的function指定一个参数。show variables like 'log_bin_trust_function_creators';set global log_bin_trust_function_creators=1;# 这样添加了参数以后，如果mysqld重启，上述参数又会消失，永久方法：windows下my.ini[mysqld]加上log_bin_trust_function_creators=1 linux下    /etc/my.cnf下my.cnf[mysqld]加上log_bin_trust_function_creators=1

3.创建函数,保证每条数据都不同

随机产生字符串:

 DELIMITER $$CREATE FUNCTION rand_string(n INT) RETURNS VARCHAR(255)BEGIN    ##方法开始DECLARE chars_str VARCHAR(100) DEFAULT   'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ'; ##声明一个 字符窜长度为 100 的变量 chars_str ,默认值 DECLARE return_str VARCHAR(255) DEFAULT '';DECLARE i INT DEFAULT 0;##循环开始WHILE i < n DO  SET return_str =CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52),1));##concat 连接函数  ，substring(a,index,length) 从index处开始截取SET i = i + 1;END WHILE;RETURN return_str;END $$#假如要删除#drop function rand_string;

随机产生部门编号:

    #用于随机产生部门编号DELIMITER $$CREATE FUNCTION rand_num( ) RETURNS INT(5)  BEGIN   DECLARE i INT DEFAULT 0;  SET i = FLOOR(100+RAND()*10);  RETURN i;  END $$#假如要删除#drop function rand_num;

4.创建存储过程

创建往emp表中插入数据的存储过程:

    DELIMITER $$CREATE PROCEDURE insert_emp10000(IN START INT(10),IN max_num INT(10))  BEGIN  DECLARE i INT DEFAULT 0;   #set autocommit =0 把autocommit设置成0  ；提高执行效率SET autocommit = 0;    REPEAT  ##重复SET i = i + 1;  INSERT INTO emp10000 (empno, ename ,job ,mgr ,hiredate ,sal ,comm ,deptno ) VALUES ((START+i) ,rand_string(6),'SALESMAN',0001,CURDATE(),FLOOR(1+RAND()*20000),FLOOR(1+RAND()*1000),rand_num());  UNTIL i = max_num   ##直到  上面也是一个循环END REPEAT;  ##满足条件后结束循环COMMIT;   ##执行完成后一起提交END $$#删除# DELIMITER ;# drop PROCEDURE insert_emp;

创建往dept表中插入数据的存储过程:

    #执行存储过程，往dept表添加随机数据DELIMITER $$CREATE PROCEDURE insert_dept(IN START INT(10),IN max_num INT(10))  BEGIN  DECLARE i INT DEFAULT 0;   SET autocommit = 0;    REPEAT  SET i = i + 1;  INSERT INTO dept (deptno ,dname,loc ) VALUES (START +i ,rand_string(10),rand_string(8));  UNTIL i = max_num  END REPEAT;  COMMIT;  END $$ #删除# DELIMITER ;# drop PROCEDURE insert_dept;

5.调用存储过程

dept:

    DELIMITER ;CALL insert_dept(100,10);

emp:

    #执行存储过程，往emp表添加50万条数据DELIMITER ;    #将 结束标志换回 ;CALL insert_emp(100001,500000); CALL insert_emp10000(100001,10000);

6.大量数据案例

4、Show Profile

是mysql提供可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优的测量官网：http://dev.mysql.com/doc/refman/5.5/en/show-profile.html默认情况下，参数处于关闭状态，并保存最近15次的运行结果

1.是否支持，看看当前的mysql版本是否支持

 Show variables like 'profiling';  #默认是关闭，使用前需要开启

2.开启功能，默认是关闭，使用前需要开启

 show variables like 'profiling';set profiling=1;

3.运行SQL

 select * from emp group by id%10 limit 150000;select * from emp group by id%20  order by 5

4.查看结果，show profiles;

5.诊断SQL，show profile cpu,block io for query n (n为上一步前面的问题SQL数字号码);

参数备注:

    type:  | ALL                        --显示所有的开销信息  | BLOCK IO                --显示块IO相关开销  | CONTEXT SWITCHES --上下文切换相关开销  | CPU              --显示CPU相关开销信息  | IPC              --显示发送和接收相关开销信息  | MEMORY           --显示内存相关开销信息  | PAGE FAULTS      --显示页面错误相关开销信息  | SOURCE           --显示和Source_function，Source_file，Source_line相关的开销信息  | SWAPS            --显示交换次数相关开销的信息

6.日常开发需要注意的结论

converting HEAP to MyISAM 查询结果太大，内存都不够用了往磁盘上搬了。Creating tmp table 创建临时表:拷贝数据到临时表,用完再删除

    1  select * from emp group by id%20 limit 120000;2  select * from emp group by id%20  order by 5

Copying to tmp table on disk 把内存中临时表复制到磁盘，危险！！！

locked

5、全局查询日志

尽量不要在生产环境开启这个功能。

配置启用:

    在mysql的my.cnf中，设置如下：#开启general_log=1   # 记录日志文件的路径general_log_file=/path/logfile#输出格式log_output=FILE

编码启用:

    命令set global general_log=1;#全局日志可以存放到日志文件中，也可以存放到Mysql系统表中。存放到日志中性能更好一些，存储到表中set global log_output='TABLE';此后 ，你所编写的sql语句，将会记录到mysql库里的general_log表，可以用下面的命令查看select * from mysql.general_log;

四.MySql锁机制

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

1.锁的分类

从对数据操作的类型（读\写）分:

读锁 (共享锁)：针对同一份数据，多个读操作可以同时进行而不会互相影响。写锁 (排它锁）：当前写操作没有完成前，它会阻断其他写锁和读锁。

从对数据操作的粒度分:

表锁行锁为了尽可能提高数据库的并发度，每次锁定的数据范围越小越好，理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但是管理锁是很耗资源的事情（涉及获取，检查，释放锁等动作），因此数据库系统需要在高并发响应和系统性能两方面进行平衡，这样就产生了“锁粒度（Lock granularity）”的概念。一种提高共享资源并发性的方式是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。

2.表锁(偏读)

偏向MyISAM存储引擎，开销小，加锁快；无死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。

1、案例分析

建表SQL:

   【表级锁分析--建表SQL】create table mylock(id int not null primary key auto_increment,name varchar(20))engine myisam;insert into mylock(name) values('a');insert into mylock(name) values('b');insert into mylock(name) values('c');insert into mylock(name) values('d');insert into mylock(name) values('e');select * from mylock;【手动增加表锁】lock table 表名字1 read(write)，表名字2 read(write)，其它;【查看表上加过的锁】show open tables;【释放表锁】unlock tables;

加读锁:我们为mylock表加read锁(读阻塞写例子)

session_1	session_2
获得表mylock的READ锁定
连接终端
当前session可以查询该表记录
其他session也可以查询该表的记录

当前session不能查询其它没有锁定的表
其他session可以查询或者更新未锁定的表

当前session中插入或者更新锁定的表都会提示错误：
其他session插入或者更新锁定表会一直等待获得锁：
释放锁
Session2获得锁，插入操作完成：

加写锁:mylockwrite(MyISAM)

session_1	session_2
获得表mylock的WRITE锁定	待Session1开启写锁后，session2再连接终端
当前session对锁定表的查询+更新+插入操作都可以执行：	其他session对锁定表的查询被阻塞，需要等待锁被释放：

释放锁	Session2获得锁，查询返回：

2、表锁结论

MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。
MySQL的表级锁有两种模式：
表共享读锁（Table Read Lock）
表独占写锁（Table Write Lock）

锁类型	他人可读	他人可写
读锁	是	否
写锁	否	否

    结合上表，所以对MyISAM表进行操作，会有以下情况： 1.对MyISAM表的读操作（加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其它进程的写操作。 2.对MyISAM表的写操作（加写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。
简而言之，就是读锁会阻塞写，但是不会堵塞读。而写锁则会把读和写都堵塞

3.行锁(偏写)

偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁

1、案例分析

建表SQL:

    create table test_innodb_lock (a int(11),b varchar(16))engine=innodb;insert into test_innodb_lock values(1,'b2');insert into test_innodb_lock values(3,'3');insert into test_innodb_lock values(4,'4000');insert into test_innodb_lock values(5,'5000');insert into test_innodb_lock values(6,'6000');insert into test_innodb_lock values(7,'7000');insert into test_innodb_lock values(8,'8000');insert into test_innodb_lock values(9,'9000');insert into test_innodb_lock values(1,'b1');create index test_innodb_a_ind on test_innodb_lock(a);create index test_innodb_lock_b_ind on test_innodb_lock(b);select * from test_innodb_lock;

行锁定基本演示:

Session_1	Session_2

更新但是不提交，没有手写commit;	Session_2被阻塞，只能等待
提交更新	解除阻塞，更新正常进行
	commit命令执行
下面试试1号会话更新a =1	下面试试1号会话更新a =1

无索引行锁升级为表锁:

Session_1	Session_2
正常情况，各自锁定各自的行，互相不影响，一个2000另一个3000

由于在column字段b上面建了索引，如果没有正常使用，会导致行锁变表锁
比如没加单引号导致索引失效，行锁变表锁	比如没加单引号导致索引失效，行锁变表锁

2、行锁结论

Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的优势了。但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MyISAM高，甚至可能会更差。

3、Select加锁

1.读锁–共享锁(Share Lock):

共享锁又称读锁，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。
如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。用法:

 SELECT ... LOCK IN SHARE MODE;

在查询语句后面增加 LOCK IN SHARE MODE ，Mysql会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。其他线程也可以读取使用了共享锁的表（行？），而且这些线程读取的是同一个版本的数据。

2.写锁排他锁（eXclusive Lock）

排他锁又称写锁，如果事务T对数据A加上排他锁后，则其他事务不能再对A加任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。用法:

   SELECT ... FOR UPDATE;

在查询语句后面增加 FOR UPDATE ，Mysql会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。

4、间隙锁危害

1.什么是间隙锁
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（GAP Lock）。

2.危害
因为Query执行过程中通过过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。
间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害

3.间隙锁带来的插入问题

Session_1	Session_2
	阻塞产生，暂时不能插入
commit;	阻塞解除，完成插入

5、行锁分析

如何分析行锁定:
通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

 show status like 'innodb_row_lock%';

对各个状态量的说明如下：

Innodb_row_lock_current_waits：当前正在等待锁定的数量；
Innodb_row_lock_time：从系统启动到现在锁定总时间长度；
Innodb_row_lock_time_avg：每次等待所花平均时间；
Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间；
Innodb_row_lock_waits：系统启动后到现在总共等待的次数；

对于这5个状态变量，比较重要的主要是
Innodb_row_lock_time_avg（等待平均时长），
Innodb_row_lock_waits（等待总次数）
Innodb_row_lock_time（等待总时长）这三项。
尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。

最后可以通过

 SELECT * FROM information_schema.INNODB_TRX;

来查询正在被锁阻塞的sql语句。

6、优化建议

尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。尽可能较少检索条件，避免间隙锁尽量控制事务大小，减少锁定资源量和时间长度锁住某行后，尽量不要去调别的行或表，赶紧处理被锁住的行然后释放掉锁。涉及相同表的事务，对于调用表的顺序尽量保持一致。在业务环境允许的情况下,尽可能低级别事务隔离

4.页锁

开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。了解一下即可

MySQL基础: 索引, 优化, 锁相关推荐

MySQL-索引优化篇(3)_利用索引优化锁
文章目录生猛干货官方文档利用索引优化锁为什么索引能优化锁演示无索引的情况 (获取不同的数据发生了阻塞) 有索引的情况 (获取不同的数据未阻塞) 搞定MySQL 生猛干货带你搞定MyS ...
知识点：Mysql 数据库索引优化实战(4)
知识点:Mysql 索引原理完全手册(1) 知识点:Mysql 索引原理完全手册(2) 知识点:Mysql 索引优化实战(3) 知识点:Mysql 数据库索引优化实战(4) 一:插入订单业务逻辑:插 ...
Mysql之索引优化案例
Mysql之索引优化案例 1.单表简单案例 1.1创建表 1.2 问题: 1.3 解决:新建索引 1.4 再次执行 2.双表简单案例 2.1创建表并插入数据 2.2 由于是LEFT JOIN,所以左表 ...
mysql数据库索引和锁和日志
数据库索引和锁索引和锁在数据库中可以说是非常重要的知识点了,在面试中也会经常会被问到的. 本文力求简单讲清每个知识点,希望大家看完能有所收获声明:如果没有说明具体的数据库和存储引擎,默认指的是My ...
Mysql高级索引优化
Mysql逻辑架构 Mysql与其他数据库相比有点与众不同,他的架构可以在多种不同的场景中应用并发挥作用,主要体现在存储引擎的架构上,插件式的存储引擎结构将查询处理和其他的系统任务以及数据的存储提取分 ...
MySQL高级-索引优化（超详细）
性能分析 MySQL Query Optimizer Mysql中由专门负责优化SELECT语句的优化器,主要功能就是通过计算分析系统中收集到的统计信息,为客户端请求的Query提供他认为最优的执行计 ...
【MySQL】索引优化中的最左前缀原则和索引下推
目录一.引入二.覆盖索引讲接下来的问题前首先讲一下联合索引的底层存储结构长什么样?联合索引的检索过程是什么样的呢? 三.最左前缀原则最左前缀原则的定义四.索引下推五.小结一.引入在 ...
MySQL - 无索引行锁升级为表锁
文章目录生猛干货无索引行锁升级为表锁演示表结构索引信息操作演示结论搞定MySQL 生猛干货带你搞定MySQL实战,轻松对应海量业务处理及高并发需求,从容应对大场面试无索引行锁升级为表 ...
MySQL - 践行索引优化
文章目录生猛干货 Pre Table Demo DB Version Case 全值匹配最左前缀禁止索引列上做任何操作(计算.函数.(自动or手动)类型转换) 存储引擎不能使用索引中范围条件右边 ...