MySQL高级篇（SQL优化、索引优化、锁机制、主从复制）_mysql sql优化
3 索引介绍
3.1 索引是什么
MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构（索引的本质是数据结构，排序+查询两种功能）。
索引的目的在于提高查询效率，可以类比字典。
如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。
如果没有索引，那么你可能需要逐个逐个寻找，如果我想找到Java开头的单词呢？或者Oracle开头的单词呢？
是不是觉得如果没有索引，这个事情根本无法完成？
索引可以理解为：排好序的快速查找数据结构
下图就是一种可能的索引方式示例：
假如：找4号这本书，扫码得到对应的编号为91，91比34大往右边找，91比89大往右边找，然后找到（比较三次后就可以找到，然后检索出对应的物理地址）
为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录
结论：在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用(指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引
一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。
我们平常所说的索引，如果没有特别指明，都是指B树（多路搜索树，并不一定是二叉的）结构组织的索引。其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈稀索引(hash index)等
3.2 索引优劣势
优势：
- 类似大学图书馆建书目索引，提高数据检索的效率，降低数据库的IO成本。
- 通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗。
劣势：
- 实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间的（占空间）
- 虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息。
- 索引只是提高效率的一个因素，如果你的MysQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询
3.3 索引分类和建索引命令语句
主键索引：索引值必须是唯一的，且不能为NULL
- 第一种：
CREATE TABLE table_name(id int PRIMARY KEY aoto_increment,name varchar(10)); - 第二种：
ALTER TABLE table_name ADD PRIMARY KEY (columnName);
普通索引：索引值可出现多次
- 第一种：
CREATE INDEX index_name on table_name(columnName); - 第二种：
ALTER TABLE table_name ADD INDEX index_name (columnName);
全文索引：主要是针对文本的检索，如：文章，全文索引只针对MyISAM引擎有效，并且只针对英文内容生效
- 建表时创建
#建表
CREATE TABLE articles(
id INT UNSIGNED ATUO_INCREMENT NOT NULL PRIMARY KEY,
title VARCHAR(200),
body TEXT,
FULLTEXT(title,body)
)engine=myisam charset utf8; #指定引擎
#使用
select \* from articles where match(title,body) against('英文内容'); #只针对英语内容生效
#说明
#1、在mysql中fultext索引只针对 myisam 生效
#2、mysq1自己提供的flltext只针对英文生效->sphinx (coreseek)技术处理中文工
#3、使用方法是match(字段名...) against(‘关键字')
#4、全文索引一个叫停止词，因为在一个文本中创建索引是一个无穷大的数，因此对一些常用词和字符就不会创建，这些词称为停止词
ALTER TABLE table_name ADD FULLTEXT index_name (columnName);
唯一索引：索引列的值必须唯一，但允许有空值NULL，并可以有多个。
- 第一种：
CREATE UNIQUE INDEX index_name ON table_name(columnName); - 第二种：
ALTER TABLE table_name ADD UNIQUE INDEX index_name ON (columnName);
单值索引：即一个索引只包含单个列，一个表可以有多个单列索引。
- 第一种：
CREATE INDEX index_name ON table_name(columnName); - 第二种：
ALTER TABLE table_name ADD INDEX index_name ON (columnName);
select \* from user where name='';
//经常查name字段，为其建索引
create index idx_user_name on user(name);
复合索引：即一个索引包含多个列
- 第一种：
CREATE INDEX index_name ON table_name(columnName1，columnName2...); - 第二种：
ALTER TABLE table_name ADD INDEX index_name ON (columnName1，columnName2...);
select \* from user where name='' and email='';
//经常查name和email字段，为其建索引
create index idx_user_name on user(name, email);
查询索引
- 第一种：
SHOW INDEX FROM table_name; - 第二种：
SHOW KEYS FROM table_name;
删除索引
- 第一种：
DROP INDEX index_name ON table_name; - 第二种：
ALTER TABLE table_name DROP INDEX index_name; - 删除主键索引：
ALTER TBALE table_name DROP PRIMARY KEY;
3.4 索引结构与检索原理
MySQL索引结构：
- BTree索引
- Hash索引
- full-text全文索引
- R-Tree索引
初始化介绍
一颗b+树，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示),如磁盘块1包含数据项17和35，包含指针P1、P2、P3,
P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。
真实的数据存在于叶子节点：3、5、9、10、13、15、28、29、36、60、75、79、90、99。
非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。
查找过程
如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO。在内存中用二分查找确定 29 在 17 和 35 之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29 在 26 和 30 之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO
真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高
3.5 哪些情况适合建索引
- 主键自动建立唯一索引
- 频繁作为查询条件的字段应该创建索引
- 查询中与其它表关联的字段，外键关系建立索引
- 单键/组合索引的选择问题，who?(在高并发下倾向创建组合索引)
- 查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
- 查询中统计或者分组字段
3.6 哪些情况不适合建索引
- Where条件里用不到的字段不创建索引
- 表记录太少（300w以上建）
- 经常增删改的表（提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件）
- 数据重复且分布平均的表字段，因此应该只为最经常查询和最经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。（比如：国籍、性别）
假如一个表有10万行记录，有一个字段A只有T和F两种值，且每个值的分布概率天约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。
索引的选择性是指索引列中不同值的数目与表中记录数的比。如果一个表中有2000条记录，表索引列有1980个不同的值，那么这个索引的选择性就是1980/2000=0.99。一个索引的选择性越接近于1，这个索引的效率就越高
4 性能分析
4.1 性能分析前提知识
MySQL Query Optimizer（查询优化器）[ˈkwɪəri] [ˈɒptɪmaɪzə]
Mysql中专门负责优化SELECT语句的优化器模块，主要功能：通过计算分析系统中收集到的统计信息，为客户端请求的Query提供他认为最优的执行计划（他认为最优的数据检索方式，但不见得是DBA认为是最优的,这部分最耗费时间）
当客户端向MySQL请求一条Query，命令解析器模块完成请求分类，区别出是SELECT并转发给MySQL Query Optimizer时，MySQL Query Optimizer首先会对整条Query进行优化，处理掉一些常量表达式的预算直接换算成常量值。并对Query中的查询条件进行简化和转换，如去掉一些无用或显而易见的条件、结构调整等。然后分析Query 中的 Hint信息(如果有），看显示Hint信息是否可以完全确定该Query的执行计划。如果没有Hint 或Hint信息还不足以完全确定执行计划，则会读取所涉及对象的统计信息，根据Query进行写相应的计算分析，然后再得出最后的执行计划
MySQL常见瓶颈：
- CPU：CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候
- IO：磁盘I/O瓶颈发生在装入数据远大于内存容量的时候
- 服务器硬件的性能瓶颈：top，free，iostat和vmstat来查看系统的性能状态
4.2 Explain使用简介
使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈
官网地址
Explain的作用：
- 表的读取顺序
- 数据读取操作的操作类型
- 哪些索引可以使用
- 哪些索引被实际使用
- 表之间的引用
- 每张表有多少行被优化器查询
使用Explain：
- explain + sql语句
- 执行计划包含的信息（
重点） ：| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
mysql> select \* from tbl_emp;
+----+------+--------+
| id | NAME | deptId |
+----+------+--------+
| 1 | z3 | 1 |
| 2 | z4 | 1 |
| 3 | z5 | 1 |
| 4 | w5 | 2 |
| 5 | w6 | 2 |
| 6 | s7 | 3 |
| 7 | s8 | 4 |
| 8 | s9 | 51 |
+----+------+--------+
8 rows in set (0.00 sec)
mysql> explain select \* from tbl_emp;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
| 1 | SIMPLE | tbl_emp | NULL | ALL | NULL | NULL | NULL | NULL | 8 | 100.00 | NULL |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)
4.3 执行计划包含的信息字段解释（重中之重）
执行计划包含的信息（重点） ：| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
面试重点：id、type、key、rows、Extra
id（表的读取顺序）
select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序
三种情况：
- 1、id相同，执行顺序由上至下（t1、t3、t2）
- 2、id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行（t3、t1、t2）
- 3、id相同不同，同时存在。先走数字大的，数字相同的由上至下（t3、s1、t2）
select_type（ 数据读取操作的操作类型）
查询的类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询。
- SIMPLE [ˈsɪnpl] ：简单的select查询,查询中不包含子查询或者UNION
- PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为（最后加载的那个）
- SUBQUERY [ˈkwɪəri] ：在SELECT或WHERE列表中包含了子查询
- DERIVED [dɪˈraɪvd]：在FROM列表中包含的子查询被标记为DERIVED（衍生）MySQL会递归执行这些子查询，把结果放在临时表里
- UNION [ˈjuːniən]：若第二个SELECT出现在UNION之后，则被标记为UNION；若UNION包含在FROM子句的子查询中外层SELECT将被标记为：DERIVED
- UNION RESULT [rɪˈzʌlt] ：从UNION表获取结果的SELECT（两个select语句用UNION合并）
table（显示执行的表名）
显示这一行的数据是关于哪张表的
type（访问类型排列）
显示查询使用了何种类型
访问类型排列：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index >ALL
type常用八种类型：
结果值从最好到最坏依次是（重点）：：system > const > eq_ref > ref > range > index > ALL
一般来说，得保证查询至少达到range级别，最好能达到ref
详细说明
- system：表只有一行记录（等于系统表），这是const类型的特列，平时不会出现，这个也可以忽略不计。
- const：表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快如将主键置于where列表中，MySQL就能将该查询转换为一个常量。
- eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描。
- ref：非唯一性索引扫描，返回匹配某个单独值的所有行，本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体
- range：只检索给定范围的行,使用一个索引来选择行。key列显示使用了哪个索引一般就是在你的where语句中出现了between、<、>、in等的查询。这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引
- index：Full Index Scan，index与ALL区别为index类型只遍历索引列。这通常比ALL快，因为索引文件通常比数据文件小（也就是说虽然all和Index都是读全表，但index是从索引中读取的，而all是从硬盘中读的）
- all：Full Table Scan，将遍历全表以找到匹配的行
工作案例：经理这条SQL我跑了一下Explain分析，在系统上可能会有ALL全表扫描的情况，建议尝试一下优化。我把这条SQL改了改，我优化后是这么写，这个效果已经从ALL变成了…
possible_keys（哪些索引可以使用）
显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段火若存在索引，则该索引将被列出，但不一定被查询实际使用（系统认为理论上会使用某些索引）
key（哪些索引被实际使用）
实际使用的索引。如果为NULL，则没有使用索引（要么没建，要么建了失效）
查询中若使用了覆盖索引，则该索引仅出现在key列表中
覆盖索引：建的索引字段和查询的字段一致，如下图
key_len（消耗的字节数）
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。在不损失精确性的情况下，长度越短越好
key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的
ref（表之间的引用）
显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值。
rows（每张表有多少行被优化器查询）
根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数（越小越好）
未建索引时：
建索引后：扫描行数减少
Extra [ˈekstrə]
包含不适合在其他列中显示但十分重要的额外信息
信息种类：Using filesort 、Using temporary 、Using index 、Using where 、Using join buffer 、impossible where 、select tables optimized away 、distinct
Using filesort（需要优化）
说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成的排序操作称为"文件排序"
Using temporary（需要优化）
使了用临时表保存中间结果，MysQL在对查询结果排序时使用临时表。常见于排序order by和分组查询group by
Using index（good）
表示相应的select操作中使用了覆盖索引（Covering Index），避免访问了表的数据行，效率不错！
- 情况一：
- 情况二：
覆盖索引 / 索引覆盖（Covering Index）。
- 理解方式一：就是select的数据列只用从索引中就能够取得，不必读取数据行，MySQL可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件,换句话说查询列要被所建的索引覆盖。
- 理解方式二：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含了（或覆盖了）满足查询结果的数据就叫做覆盖索引。
注意：
- 如果要使用覆盖索引，一定要注意select列表中只取出需要的列，不可select*
- 因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降
Using where：表明使用了where过滤。
Using join buffer：使用了连接缓存
impossible where：where子句的值总是false，不能用来获取任何元组
select tables optimized away
在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作，或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。
distinct
优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作。
练习
写出下图的表的执行顺序
第一行（执行顺序4）：id列为1，表示是union里的第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中derived3中3代表该查询衍生自第三个select查询，即id为3的select。【select d1.name… 】
第二行（执行顺序2）：id为3，是整个查询中第三个select的一部分。因查询包含在from中，所以为derived。【select id,namefrom t1 where other_column=’’】
第三行（执行顺序3）：select列表中的子查询select_type为subquery，为整个查询中的第二个select。【select id from t3】
第四行（执行顺序1）：select_type为union，说明第四个select是union里的第二个select，最先执行【select name,id from t2】
第五行（执行顺序5）：代表从union的临时表中读取行的阶段，table列的
5 索引优化
5.1 索引单表优化案例
建表：
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 VARCHAR(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');
//查询
mysql> select \* from article;
+----+-----------+-------------+-------+----------+-------+---------+
| id | author_id | category_id | views | comments | title | content |
+----+-----------+-------------+-------+----------+-------+---------+
| 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| 3 | 1 | 1 | 3 | 3 | 3 | 3 |
+----+-----------+-------------+-------+----------+-------+---------+
3 rows in set (0.00 sec)
案例
要求：查询 category_id 为 1 且 comments 大于1 的情况下，views 最多的 article_id
//功能实现
mysql> SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
+----+-----------+
| id | author_id |
+----+-----------+
| 3 | 1 |
+----+-----------+
1 row in set (0.00 sec)
//explain分析
mysql> explain SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+
| 1 | SIMPLE | article | NULL | ALL | NULL | NULL | NULL | NULL | 3 | 33.33 | Using where; Using filesort |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+
1 row in set, 1 warning (0.00 sec)
结论：很显然，type是ALL，即最坏的情况。Extra里还出现了Using filesort，也是最坏的情况。优化是必须的
开始优化
新建索引（给WHERE语句后使用的字段添加索引）
创建方式：
create index idx_article_ccv on article(category_id,comments,views);ALTER TABLE 'article' ADD INDEX idx_article_ccv ( 'category_id , 'comments', 'views' );
索引用处不大，删除：DROP INDEX idx_article_ccv ON article;
结论：
- type变成了range，这是可以忍受的。但是extra里使用Using filesort仍是无法接受的。
- 但是我们已经建立了索引，为啥没用呢？
- 这是因为按照BTree索引的工作原理，先排序category_id，如果遇到相同的category_id则再排序comments,如果遇到相同的comments 则再排序views。
- 当comments字段在联合索引里处于中间位置时，因comments > 1条件是一个范围值(所谓range)，MySQL无法利用索引再对后面的views部分进行检索，即
range类型查询字段后面的索引无效。
改进
上次创建索引相比，这次不为comments字段创建索引
结论：type变为了ref，ref 中是 const，Extra 中的 Using filesort也消失了，结果非常理想
5.2 索引两表优化案例
建表：
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 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)));
//查询
mysql> select \* from class;
+----+------+
| id | card |
+----+------+
| 1 | 17 |
| 2 | 2 |
| 3 | 18 |
| 4 | 4 |
| 5 | 4 |
| 6 | 8 |
| 7 | 9 |
| 8 | 1 |
| 9 | 18 |
| 10 | 6 |
| 11 | 15 |
| 12 | 15 |
| 13 | 12 |
| 14 | 15 |
| 15 | 18 |
| 16 | 2 |
| 17 | 18 |
| 18 | 5 |
| 19 | 7 |
| 20 | 1 |
| 21 | 2 |
+----+------+
21 rows in set (0.00 sec)
mysql> select \* from book;
+--------+------+
| bookid | card |
+--------+------+
| 1 | 8 |
| 2 | 14 |
| 3 | 3 |
| 4 | 16 |
| 5 | 8 |
| 6 | 12 |
| 7 | 17 |
| 8 | 8 |
| 9 | 10 |
| 10 | 3 |
| 11 | 4 |
| 12 | 12 |
| 13 | 9 |
| 14 | 7 |
| 15 | 6 |
| 16 | 8 |
| 17 | 3 |
| 18 | 11 |
| 19 | 5 |
| 20 | 11 |
+--------+------+
20 rows in set (0.00 sec)
开始Explain分析：type都是all，需要优化（总有一个表来添加索引驱动）
- 左连接为左表加索引
删除索引：drop index y on class;
- 左连接为右表添加索引
删除索引：drop index Y on book;
- 案例：如果别人建的索引位置不对，只需要自己查询时调整左右表的顺序即可
结论：
- 第二行的type变为了ref，rows也变少了，优化比较明显。这是由左连接特性决定的。LEFT JOIN条件用于确定如何从右表搜索行，左边一定都有，
所以右边是我们的关键点，一定需要在右表建立索引（小表驱动大表）。 左连接，右表加索引同理：右连接，左表加索引
5.3 索引三表优化案例
建表：
CREATE TABLE IF NOT EXISTS phone(
phoneid INT(10) UNSIGNED NOT NULL AUTO\_INCREMENT,
card INT(10) UNSIGNED NOT NULL,
PRIMARY KEY(phoneid)
)ENGINE=INNODB;
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()\*20)));
//查询
mysql> select \* from phone;
+---------+------+
| phoneid | card |
+---------+------+
| 1 | 10 |
| 2 | 13 |
| 3 | 17 |
| 4 | 5 |
| 5 | 12 |
| 6 | 7 |
| 7 | 15 |
| 8 | 17 |
| 9 | 17 |
| 10 | 14 |
| 11 | 19 |
| 12 | 13 |
| 13 | 5 |
| 14 | 8 |
| 15 | 2 |
| 16 | 8 |
| 17 | 11 |
| 18 | 14 |
| 19 | 13 |
| 20 | 5 |
+---------+------+
20 rows in set (0.00 sec)
用上一节两个表，删除他们的索引：
三表查询语句应为：SELECT * FROM class LEFT JOIN book ON class.card = book.card LEFT JOIN phone ON book.card = phone.card;
创建索引：
- 应该为第一个LFET JOIN 的右表 book 建索引
alter table `book` add index Y(`card`);
- 应该为第二个LFET JOIN 的右表 phone 建索引
alter table `phone` add index z(`card`);
Explain分析：
后2行的 type 都是ref且总 rows优化很好，效果不错。因此索引最好设置在需要经常查询的字段中
结论：
- Join语句的优化
- 尽可能减少Join语句中的NestedLoop的循环总次数：“
永远用小结果集驱动大的结果集（比如：书的类型表驱动书的名称表）”。 - 优先优化NestedLoop的内层循环，保证Join语句中被驱动表上Join条件字段已经被索引。
- 当无法保证被驱动表的Join条件字段被索引且内存资源充足的前提下，不要太吝惜JoinBuffer的设置
5.4 索引失效
建表：
CREATE TABLE staffs(
id INT PRIMARY KEY AUTO\_INCREMENT,
`name` VARCHAR(24) NOT 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());
ALTER TABLE staffs ADD INDEX index_staffs_nameAgePos(`name`,`age`,`pos`);
索引失效案例：
- 1、全值匹配我最爱
- 2、
最佳左前缀法则（重要！）：如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过复合索引中间列。
中间列不能断：
- 3、不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描。
- 4、存储引擎不能使用索引中范围条件右边的列（范围之后全失效，范围列并不是做的查询而是排序）。
- 5、尽量使用覆盖索引（只访问索引的查询（索引列和查询列一致）），减少select *。
- 6、mysql在使用不等于（!=或者<>）的时候无法使用索引会导致全表扫描。
- 7、is null, is not null 也无法使用索引。
- 8、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;
INSERT INTO tbl_user(`name`,`age`,`email`)VALUES('1aa1',21,'[email protected]');
INSERT INTO tbl_user(`name`,`age`,`email`)VALUES('2bb2',23,'[email protected]');
INSERT INTO tbl_user(`name`,`age`,`email`)VALUES('3cc3',24,'[email protected]');
INSERT INTO tbl_user(`name`,`age`,`email`)VALUES('4dd4',26,'[email protected]');
//查询
mysql> select \* from tbl_user;
+----+------+------+-----------+
| id | name | age | email |
+----+------+------+-----------+
| 1 | 1aa1 | 21 | [email protected] |
| 2 | 2bb2 | 23 | [email protected] |
| 3 | 3cc3 | 24 | [email protected] |
| 4 | 4dd4 | 26 | [email protected] |
+----+------+------+-----------+
4 rows in set (0.00 sec)
创建索引：
CREATE INDEX idx_user_nameAge ON tbl_user(NAME,age);
索引成功使用：
索引失效：
总结：%写在最右边，如果非要写在最左边，就使用覆盖索引
- 9、字符串不加单引号索引失效。
Explain分析：
- 10、少用or，用它来连接时会索引失效
5.5 索引面试题分析
建表：
create table test03(
id int primary key not null auto\_increment,
c1 char(10),
c2 char(10),
c3 char(10),
c4 char(10),
c5 char(10)
);
insert into test03(c1,c2,c3,c4,c5) values ('a1','a2','a3','a4','a5');
insert into test03(c1,c2,c3,c4,c5) values ('b1','b2','b3','b4','b5');
insert into test03(c1,c2,c3,c4,c5) values ('c1','c2','c3','c4','c5');
insert into test03(c1,c2,c3,c4,c5) values ('d1','d2','d3','d4','d5');
insert into test03(c1,c2,c3,c4,c5) values ('e1','e2','e3','e4','e5');
//查看表结构
mysql> select \* from test03;
+----+------+------+------+------+------+
| id | c1 | c2 | c3 | c4 | c5 |
+----+------+------+------+------+------+
| 1 | a1 | a2 | a3 | a4 | a5 |
| 2 | b1 | b2 | b3 | b4 | b5 |
| 3 | c1 | c2 | c3 | c4 | c5 |
| 4 | d1 | d2 | d3 | d4 | d5 |
| 5 | e1 | e2 | e3 | e4 | e5 |
+----+------+------+------+------+------+
5 rows in set (0.00 sec)
建索引：
create index idx_test03_c1234 on test03(c1,c2,c3,c4);
//查看索引
mysql> show index from test03;
+--------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+--------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| test03 | 0 | PRIMARY | 1 | id | A | 2 | NULL | NULL | | BTREE | | |
| test03 | 1 | idx_test03_c1234 | 1 | c1 | A | 5 | NULL | NULL | YES | BTREE | | |
| test03 | 1 | idx_test03_c1234 | 2 | c2 | A | 5 | NULL | NULL | YES | BTREE | | |
| test03 | 1 | idx_test03_c1234 | 3 | c3 | A | 5 | NULL | NULL | YES | BTREE | | |
| test03 | 1 | idx_test03_c1234 | 4 | c4 | A | 5 | NULL | NULL | YES | BTREE | | |
+--------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
5 rows in set (0.00 sec)
1）逐一增加列
2）交换条件顺序不影响索引，但最好按照建索引顺序来写SQL
3) 限定范围
4）order by
5）group by
定值、范围还是排序，一般order by是给个范围
group by基本上都需要进行排序，会有临时表产生
建议：
- 对于单值索引，尽量选择针对当前query过滤性更好的索引。
- 在选择组合索引的时候，当前Query中过滤性最好的字段在索引字段顺序中，位置越靠左越好。
- 在选择组合索引的时候，尽量选择可以能够包含当前query中的where字句中更多字段的索引。
- 尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的。
5.6 总结
优化总结口诀
全值匹配我最爱， 最左前缀要遵守；
带头大哥不能死， 中间兄弟不能断；
索引列上少计算， 范围之后全失效；
LIKE 百分写最右， 覆盖索引不写 *；
不等空值还有OR， 索引影响要注意；
VAR 引号不可丢， SQL 优化有诀窍。
6 查询截取分析
6.1 小表驱动大表
EXISTS [ɪɡˈzɪsts]语法：SELECT ...FROM table WHERE EXISTS (subquery)
该语法可以理解为：将主查询的数据，放到子查询中做条件验证，根据验证结果（TRUE或FALSE）来决定主查询的数据结果是否得以保留
提示：
- EXSTS(subquey) 只返回TRUE或FALSE，因此子查询中的SELECT * 也可以是 SELECT 1 或select ‘X’，官方说法是实际执行时会忽略SELECT清单，因此没有区别。
- EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比，如果担忧效率问题，可进行实际检验以确定是否有效率问题。
- EXISTS子查询往往也可以用条件表达式，其他子查询或者JOIN来替代，何种最优需要具体问题具体分析
in和exists用法：
6.2 Order by 关键字排序优化
1、ORDER BY之后子句，尽量使用Index方式排序，避免使用FileSort方式排序
建表：
create table tblA(
#id int primary key not null auto\_increment,
age int,
birth timestamp not null
);
insert into tblA(age, birth) values(22, now());
insert into tblA(age, birth) values(23, now());
insert into tblA(age, birth) values(24, now());
create index idx_A_ageBirth on tblA(age, birth);
//查询
mysql> select \* from tblA;
+------+---------------------+
| age | birth |
+------+---------------------+
| 22 | 2021-04-04 19:31:45 |
| 23 | 2021-04-04 19:31:45 |
| 24 | 2021-04-04 19:31:45 |
+------+---------------------+
3 rows in set (0.00 sec)
mysql> show index from tblA;
+-------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| tbla | 1 | idx_A_ageBirth | 1 | age | A | 3 | NULL | NULL | YES | BTREE | | |
| tbla | 1 | idx_A_ageBirth | 2 | birth | A | 3 | NULL | NULL | | BTREE | | |
+-------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
2 rows in set (0.00 sec)
关注点：是order by之后会不会产生Using filesort
MySQL支持二种方式的排序，FileSort和lIndex，Index效率高，它指MySQL扫描索引本身完成排序。FileSort方式效率较低。
ORDER BY满足两情况，会使用Index方式排序：
- ORDER BY语句使用索引最左前列。
- 使用where子句与Order BY子句条件列组合满足索引最左前列。
2、尽可能在索引上完成排序操作，遵照建索引的最佳左前缀
3、如果不在索引列上，mysql的filesort有两种算法（自动启动）
- 双路排序
MySQL4.1之前是使用双路排序，字面意思就是两次扫描磁盘，最终得到数据，读取行指针和OrderBy列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读对应的数据输出。
从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。
取一批数据，要对磁盘进行了两次扫描，众所周知，I\O是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序
- 单路排序
从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序压的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间，因为它把每一行都保存在内存中了
- 结论及引申出的问题
由于单路是后出的，总体而言好过双路
但是用单路有问题，在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参数的设置
- Why？
5、小总结：
6.3 Group by 优化
group by实质是先排序后进行分组，遵照索引建的最佳左前缀。
当无法使用索引列，增大max_length_for_sort_data参数的设置 + 增大sort_buffer_size参数的设置。
where高于having，能写在where限定的条件就不要去having限定了
6.4 慢查询日志（重点）
介绍：
- MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。
- 具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上的语句。
- 由他来查看哪些SQL超出了我们的最大忍耐时间值，比如一条sql执行超过5秒钟，我们就算慢SQL，希望能收集超过5秒的sql，结合之前explain进行全面分析
操作说明：
默认情况下，MySQL数据库没有开启慢查询日速，需要我们手动来设置这个参数。
当然，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件。
查看是否开启及如何开启：
- 默认：
SHOW VARIABLES LIKE '%slow_query_log%';[ˈveəriəbls] - 开启：
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 =1
slow_query_log_file=/var/lib/mysqatguigu-slow.log
关于慢查询的参数slow_query_log_file，它指定慢查询日志文件的存放路径，系统默认会给一个缺省的文件host_name-slow.log（如果没有指定参数slow_query_log_file的话）
开启了慢查询日志后，什么样的SQL才会记录到慢查询日志里面呢？
这个是由参数long_query_time控制，默认情况下long_query_time的值为10秒，命令：SHOW VARIABLES LIKE 'long_query_time%';
可以使用命令修改，也可以在my.cnf参数里面修改。
假如运行时间正好等于long_query_time的情况，并不会被记录下来。也就是说，在mysql源码里是判断大于long_query_time，而非大于等于。
命名修改慢SQL阈值时间：set global long_query_time=3; [ˈɡləʊbl]
看不到修改情况的话，重开连接，或者换一个语句：show global variables like 'long_query_time';
记录慢SQL并后续分析:
假设我们成功设置慢SQL阈值时间为3秒（set global long_query_time=3;）。
模拟超时SQL：select sleep(4);
查询当前系统中有多少条慢查询记录：show global status like '%Slow_queries%'; [ˈsteɪtəs]
在配置文件中设置慢SQL阈值时间（永久生效）：
#[mysqld]下配置:
slow_query_log=1;
slow_query_log_file=/var/lib/mysql/atguigu-slow.log
long_query_time=3;
log_output=FILE;
日志分析工具mysqldumpslow
在生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具mysqldumpslow。
查看mysqldumpslow的帮助信息，mysqldumpslow --help。
常用mysqldumpslow帮助信息：
- s：是表示按照何种方式排序
- c：访问次数
- l：锁定时间
- r：返回记录
- t：查询时间
- al：平均锁定时间
- ar：平均返回记录数
- at：平均查询时间
- t：即为返回前面多少条的数据
- g：后边搭配一个正则匹配模式，大小写不敏感的
工作常用参考：
- 得到返回记录集最多的10个SQL：
mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log - 得到访问次数最多的10个SQL：
mysqldumpslow -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 /ar/lib/mysql/atguigu-slow.log | more
6.5 批量插入数据脚本
1、建表：
create database bigData;
use bigData;
//部门表
CREATE 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;
//员工表
CREATE 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 'abcdefghijklmnopqrstuvwxyz';
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));
set i=i+1;
end while;
return return_str;
end $$
- 随机产生部门编号
delimiter $$
create function rand_num() returns int(5)
begin
declare i int default 0;
set i=floor(100+rand()\*10);
return i;
end $$
4、创建存储过程
- 创建往emp表中插入数据的存储过程
delimiter $$
create procedure insert_emp(in start int(10),in max_num int(10)) #max\_num：表示插入多少条数据
begin
declare i int default 0;
set autocommit = 0; #关闭自动提交，避免写一个insert提交一次，50w条一次性提交
repeat
set i = i+1;
insert into emp(empno,ename,job,mgr,hiredate,sal,comm,deptno) values((start+i),rand_string(6),'salesman',0001,curdate(),2000,400,rand_num());
until i=max_num
end repeat;
commit;
end $$
- 创建往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 $$
5、调用存储过程
- 往dept表中插入数据
mysql> DELIMITER ; # 修改默认结束符号为（;），之前改成了##
mysql> CALL insert_dept(100, 10);
Query OK, 0 rows affected (0.01 sec)
- 往emp表中插入50万数据
mysql> DELIMITER ;
mysql> CALL insert_emp(100001, 500000);
Query OK, 0 rows affected (27.00 sec)
- 查看运行结果
mysql> select \* from dept;
+----+--------+---------+--------+
| id | deptno | dname | loc |
+----+--------+---------+--------+
| 1 | 101 | mqgfy | ck |
| 2 | 102 | wgighsr | kbq |
| 3 | 103 | gjgdyj | brb |
| 4 | 104 | gzfug | p |
| 5 | 105 | keitu | cib |
| 6 | 106 | nndvuv | csue |
| 7 | 107 | cdudl | tw |
| 8 | 108 | aafyea | aqq |
| 9 | 109 | zuqezjx | dpqoyo |
| 10 | 110 | pam | cses |
+----+--------+---------+--------+
10 rows in set (0.00 sec)
mysql> select \* from emp limit 10; #查看前10条数据（50W太多了）
+----+--------+-------+----------+-----+------------+---------+--------+--------+
| id | empno | ename | job | mgr | hiredate | sal | comm | deptno |
+----+--------+-------+----------+-----+------------+---------+--------+--------+
| 1 | 100002 | xmbva | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 108 |
| 2 | 100003 | aeq | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 109 |
| 3 | 100004 | cnjfz | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 105 |
| 4 | 100005 | wwhd | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 100 |
| 5 | 100006 | e | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 107 |
| 6 | 100007 | yjfr | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 108 |
| 7 | 100008 | xlp | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 102 |
| 8 | 100009 | mp | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 102 |
| 9 | 100010 | tcdl | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 107 |
| 10 | 100011 | akw | salesman | 1 | 2021-04-05 | 2000.00 | 400.00 | 106 |
+----+--------+-------+----------+-----+------------+---------+--------+--------+
10 rows in set (0.00 sec)
6.6 Show Profile进行sql分析（重中之重）
Show Profile是mysql提供可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优的测量
官网文档
默认情况下，参数处于关闭状态，并保存最近15次的运行结果
分析步骤：
- 1、是否支持，看看当前的mysql版本是否支持：
show variables like 'profiling';
默认是关闭，使用前需要开启
- 2、开启功能，默认是关闭，使用前需要开启：
set profiling=on;
- 3、运行SQL（随便运行用来测试）
mysql> select \* from emp group by id%10 limit 150000;
mysql> select \* from emp group by id%20 order by 5;
- 4、查看结果：
show profiles;
mysql> show profiles;
+----------+------------+-----------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------+
| 1 | 0.00204000 | show variables like 'profiling' |
| 2 | 0.55134250 | select \* from emp group by id%10 limit 150000 |
| 3 | 0.56902000 | select \* from emp group by id%20 order by 5 |
+----------+------------+-----------------------------------------------+
3 rows in set, 1 warning (0.00 sec)
- 5、诊断SQL，
show profile cpu,block io for query ID号;（ID号为第4步Query_ID列中数字）
mysql> show profile cpu,block io for query 3;
+----------------------+----------+----------+------------+--------------+---------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
| starting | 0.000049 | 0.000000 | 0.000000 | NULL | NULL |
| checking permissions | 0.000005 | 0.000000 | 0.000000 | NULL | NULL |
| Opening tables | 0.000012 | 0.000000 | 0.000000 | NULL | NULL |
| init | 0.000021 | 0.000000 | 0.000000 | NULL | NULL |
| System lock | 0.000009 | 0.000000 | 0.000000 | NULL | NULL |
| optimizing | 0.000003 | 0.000000 | 0.000000 | NULL | NULL |
| statistics | 0.000017 | 0.000000 | 0.000000 | NULL | NULL |
| preparing | 0.000008 | 0.000000 | 0.000000 | NULL | NULL |
| Creating tmp table | 0.000045 | 0.000000 | 0.000000 | NULL | NULL |
| Sorting result | 0.000004 | 0.000000 | 0.000000 | NULL | NULL |
| executing | 0.000002 | 0.000000 | 0.000000 | NULL | NULL |
| Sending data | 0.568704 | 0.546875 | 0.046875 | NULL | NULL |
| Creating sort index | 0.000048 | 0.000000 | 0.000000 | NULL | NULL |
| end | 0.000003 | 0.000000 | 0.000000 | NULL | NULL |
| query end | 0.000005 | 0.000000 | 0.000000 | NULL | NULL |
| removing tmp table | 0.000006 | 0.000000 | 0.000000 | NULL | NULL |
| query end | 0.000003 | 0.000000 | 0.000000 | NULL | NULL |
| closing tables | 0.000004 | 0.000000 | 0.000000 | NULL | NULL |
| freeing items | 0.000061 | 0.000000 | 0.000000 | NULL | NULL |
| cleaning up | 0.000015 | 0.000000 | 0.000000 | NULL | NULL |
+----------------------+----------+----------+------------+--------------+---------------+
20 rows in set, 1 warning (0.00 sec)
参数备注（写在代码中）：show profile cpu,block io for query 3;（如此代码中的cpu,block）
+ ALL：显示所有的开销信息。
+ BLOCK IO：显示块lO相关开销。
+ CONTEXT SWITCHES ：上下文切换相关开销。
+ CPU：显示CPU相关开销信息。
+ IPC：显示发送和接收相关开销信息。
+ MEMORY：显示内存相关开销信息。
+ PAGE FAULTS：显示页面错误相关开销信息。
+ SOURCE：显示和Source\_function，Source\_file，Source\_line相关的开销信息。
+ SWAPS：显示交换次数相关开销的信息。
-
6、
日常开发需要注意的结论（Status列中的出现此四个问题严重）- converting HEAP to MyISAM：查询结果太大，内存都不够用了往磁盘上搬了。
- Creating tmp table：创建临时表，拷贝数据到临时表，用完再删除
- Copying to tmp table on disk：把内存中临时表复制到磁盘，危险!
- locked：锁了
6.7 全局查询日志
永远不要在生产环境开启这个功能，只能在测试环境使用！
- 第一种：配置文件启用。在mysq l的 my.cnf 中，设置如下：
#开启
general_log=1
#记录日志文件的路径
general_log_file=/path/logfile
#输出格式
log_output=FILE
-
第二种：编码启用。命令如下：
set global general_log=1;set global log_output='TABLE';
此后，你所编写的sql语句，将会记录到mysql库里的geneial_log表，可以用下面的命令查看：
mysql> select \* from mysql.general_log;
+----------------------------+------------------------------+-----------+-----------+--------------+---------------------------------+
| event_time | user_host | thread_id | server_id | command_type | argument |
+----------------------------+------------------------------+-----------+-----------+--------------+---------------------------------+
| 2021-04-05 19:57:28.182473 | root[root] @ localhost [::1] | 5 | 1 | Query | select \* from mysql.general_log |
+----------------------------+------------------------------+-----------+-----------+--------------+---------------------------------+
1 row in set (0.00 sec)
7 MySQL锁机制
7.1 概述
定义：
锁是计算机协调多个进程或线程并发访问某一资源的机制。
在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂
例子：京东购物
打个比方，我们到京东上买一件商品，商品只有一件库存，这个时候如果还有另一个人买，那么如何解决是你买到还是另一个人买到的问题？
这里肯定要用到事务，我们先从库存表中取出物品数量，然后插入订单，付款后插入付款表信息，然后更新商品数量。在这个过程中，使用锁可以对有限的资源进行保护，解决隔离和并发的矛盾
锁的分类：
-
从对数据操作的类型（读\写）分
- 读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会互相影响。
- 写锁（排它锁）：当前写操作没有完成前，它会阻断其他写锁和读锁。
-
从对数据操作的粒度分
- 表锁
- 行锁
7.2 表锁（偏读）
特点：偏向MyISAM存储引擎，开销小，加锁快；无死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
读锁案例讲解1
案例分析
建表表
create table mylock (
id int not null primary key auto\_increment,
name varchar(20) default ''
) 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');
#查询
mysql> select \* from mylock;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 2 | b |
| 3 | c |
| 4 | d |
| 5 | e |
+----+------+
5 rows in set (0.00 sec)
手动增加表锁：lock table 表名字 read(write), 表名字2 read(write), 其他;
mysql> lock table mylock read;
Query OK, 0 rows affected (0.00 sec)
查看表上加过的锁：show open tables;
mysql> show open tables;
+--------------------+------------------------------------------------------+--------+-------------+
| Database | Table | In_use | Name_locked |
+--------------------+------------------------------------------------------+--------+-------------+
| performance_schema | events_waits_summary_by_user_by_event_name | 0 | 0 |
| performance_schema | events_waits_summary_global_by_event_name | 0 | 0 |
| performance_schema | events_transactions_summary_global_by_event_name | 0 | 0 |
| performance_schema | replication_connection_status | 0 | 0 |
| mysql | time_zone_leap_second | 0 | 0 |
| mysql | columns_priv | 0 | 0 |
| my | test03 | 0 | 0 |
| bigdata | mylock | 1 | 0 |
# In\_use为1时表示已上锁
释放锁：unlock tables;
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
# 再次查看
mysql> show open tables;
+--------------------+------------------------------------------------------+--------+-------------+
| Database | Table | In_use | Name_locked |
+--------------------+------------------------------------------------------+--------+-------------+
| performance_schema | events_waits_summary_by_user_by_event_name | 0 | 0 |
| performance_schema | events_waits_summary_global_by_event_name | 0 | 0 |
| performance_schema | events_transactions_summary_global_by_event_name | 0 | 0 |
| performance_schema | replication_connection_status | 0 | 0 |
| mysql | time_zone_leap_second | 0 | 0 |
| mysql | columns_priv | 0 | 0 |
| my | test03 | 0 | 0 |
| bigdata | mylock | 0 | 0 |
加读锁——为mylock表加read锁（读阻塞写例子）
读锁案例讲解2
为mylock表加write锁（MylSAM存储引擎的写阻塞读例子）
MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。