diff --git "a/MySQL\351\253\230\347\272\247\347\257\207/MySQL\347\264\242\345\274\225\345\217\212\350\260\203\344\274\230\347\257\207.md" "b/MySQL\351\253\230\347\272\247\347\257\207/MySQL\347\264\242\345\274\225\345\217\212\350\260\203\344\274\230\347\257\207.md" index 7d6b879..f60bba3 100644 --- "a/MySQL\351\253\230\347\272\247\347\257\207/MySQL\347\264\242\345\274\225\345\217\212\350\260\203\344\274\230\347\257\207.md" +++ "b/MySQL\351\253\230\347\272\247\347\257\207/MySQL\347\264\242\345\274\225\345\217\212\350\260\203\344\274\230\347\257\207.md" @@ -841,8 +841,9 @@ InnoDB从磁盘中读取数据 `最小单位` 是数据页。而你想得到的 ![image-20220621135737422](MySQL索引及调优篇.assets/image-20220621135737422.png) -**3. 顺序读取** + +**3. 顺序读取** image-20220621135909197 # 第8章_索引的创建与设计原则 @@ -1429,6 +1430,15 @@ This function has none of DETERMINISTIC...... 主从复制，主机会将写操作记录在bin-log日志中。从机读取bin-log日志，执行语句来同步数据。如果使 用函数来操作数据，会导致从机和主键操作时间不一致。所以，默认情况下，mysql不开启创建函数设置。 +%% eason: 所有写操作都会记录到主表的binlog中作为指令集，然后同步到从库的binlog中执行 +​**binlog的三种格式**​ +- ​**STATEMENT模式**​：记录原始SQL语句（如`INSERT ... SELECT ...`） +- ​**ROW模式**​：记录数据行的实际变更（如某行字段从A变为B） +- ​**MIXED模式**​：动态选择上述两种模式 +如果采用statement模式，那么可能由于函数里的一些内容（比如日期函数等），会导致主从不一致%% + +%%eason: 从库一方面是作为备份作用，另一方面是分流select压力，大部分都是select查询使用场景%% + * 查看mysql是否允许创建函数： ```mysql @@ -1509,24 +1519,20 @@ CALL insert_stu(1000000); image-20220623154615702 -> 业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。（来源：Alibaba） 说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的。 +> ==业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。（来源：Alibaba） 说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的。== #### 2. 频繁作为 WHERE 查询条件的字段 - -某个字段在SELECT语句的 WHERE 条件中经常被使用到，那么就需要给这个字段创建索引了。尤其是在 数据量大的情况下，创建普通索引就可以大幅提升数据查询的效率。 +==某个字段在SELECT语句的 WHERE 条件中经常被使用到，那么就需要给这个字段创建索引了。==尤其是在数据量大的情况下，创建普通索引就可以大幅提升数据查询的效率。 比如student_info数据表（含100万条数据），假设我们想要查询 student_id=123110 的用户信息。 #### 3. 经常 GROUP BY 和 ORDER BY 的列 - -索引就是让数据按照某种顺序进行存储或检索，因此当我们使用 GROUP BY 对数据进行分组查询，或者使用 ORDER BY 对数据进行排序的时候，就需要对分组或者排序的字段进行索引 。如果待排序的列有多个，那么可以在这些列上建立组合索引 。 +索引就是让数据按照某种顺序进行存储或检索，因此==当我们使用 GROUP BY 对数据进行分组查询，或者使用 ORDER BY 对数据进行排序的时候，就需要对分组或者排序的字段进行索引。==如果待排序的列有多个，那么可以在这些列上建立组合索引 。 #### 4. UPDATE、DELETE 的 WHERE 条件列 - 对数据按照某个条件进行查询后再进行 UPDATE 或 DELETE 的操作，如果对 WHERE 字段创建了索引，就能大幅提升效率。原理是因为我们需要先根据 WHERE 条件列检索出来这条记录，然后再对它进行更新或删除。**如果进行更新的时候，更新的字段是非索引字段，提升的效率会更明显，这是因为非索引字段更新不需要对索引进行维护。** #### 5.DISTINCT 字段需要创建索引 - 有时候我们需要对某个字段进行去重，使用 DISTINCT，那么对这个字段创建索引，也会提升查询效率。 比如，我们想要查询课程表中不同的 student_id 都有哪些，如果我们没有对 student_id 创建索引，执行 SQL 语句： @@ -1548,12 +1554,11 @@ SELECT DISTINCT(student_id) FROM `student_info`; 你能看到 SQL 查询效率有了提升，同时显示出来的 student_id 还是按照递增的顺序 进行展示的。这是因为索引会对数据按照某种顺序进行排序，所以在去重的时候也会快很多。 #### 6. 多表 JOIN 连接操作时，创建索引注意事项 - 首先， `连接表的数量尽量不要超过 3 张` ，因为每增加一张表就相当于增加了一次嵌套的循环，数量级增 长会非常快，严重影响查询的效率。 其次， `对 WHERE 条件创建索引` ，因为 WHERE 才是对数据条件的过滤。如果在数据量非常大的情况下， 没有 WHERE 条件过滤是非常可怕的。 -最后， `对用于连接的字段创建索引` ，并且该字段在多张表中的 类型必须一致 。比如 course_id 在 student_info 表和 course 表中都为 int(11) 类型，而不能一个为 int 另一个为 varchar 类型。 +==最后， `对用于连接的字段创建索引` ，并且该字段在多张表中的 类型必须一致 。比如 course_id 在 student_info 表和 course 表中都为 int(11) 类型，而不能一个为 int 另一个为 varchar 类型。== 举个例子，如果我们只对 student_id 创建索引，执行 SQL 语句： @@ -1569,11 +1574,23 @@ WHERE name = '462eed7ac6e791292a79'; 这里我们对 name 创建索引，再执行上面的 SQL 语句，运行时间为 0.002s 。 #### 7. 使用列的类型小的创建索引 - image-20220623175306282 -#### 8. 使用字符串前缀创建索引 + + + + + + + + + + +%%eason: 操作越快，索引占用存储空间越小 +主键也尽量小一点，因为所有二级索引都会存储一份主键的值%% + +#### 8. 使用字符串前缀创建索引 image-20220623175513439 创建一张商户表，因为地址字段比较长，在地址字段上建立前缀索引 @@ -1583,7 +1600,7 @@ create table shop(address varchar(120) not null); alter table shop add index(address(12)); ``` -问题是，截取多少呢？截取得多了，达不到节省索引存储空间的目的；截取得少了，重复内容太多，字 段的散列度(选择性)会降低。怎么计算不同的长度的选择性呢？ +问题是，截取多少呢？截取得多了，达不到节省索引存储空间的目的；截取得少了，重复内容太多，字段的散列度(选择性)会降低。怎么计算不同的长度的选择性呢？ 先看一下字段在全部数据中的选择度： @@ -1622,51 +1639,52 @@ LIMIT 12; ``` 因为二级索引中不包含完整的address列信息，所以无法对前12个字符相同，后边的字符不同的记录进行排序，也就是使用索引列前缀的方式 `无法支持使用索引排序` ，只能使用文件排序。 +%%eason: 前缀索引虽然对时间和空间都有优势，但是牺牲了排序性能%% **拓展：Alibaba《Java开发手册》** -【 强制 】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本 区分度决定索引长度。 +【 强制 】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度。 -说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90% 以上 ，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度来确定。 +==说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90% 以上 ，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度来确定。== #### 9. 区分度高(散列性高)的列适合作为索引 +`列的基数` 指的是某一列中不重复数据的个数，比方说某个列包含值 `2, 5, 8, 2, 5, 8, 2, 5, 8`，虽然有`9`条记录，但该列的基数却是3。也就是说**在记录行数一定的情况下，列的基数越大，该列中的值越分散；列的基数越小，该列中的值越集中。**这个列的基数指标非常重要，直接影响我们是否能有效的利用索引。最好为列的基数大的列建立索引，为基数太小的列的简历索引效果可能不好。 -`列的基数` 指的是某一列中不重复数据的个数，比方说某个列包含值 `2, 5, 8, 2, 5, 8, 2, 5, 8`，虽然有`9`条记录，但该列的基数却是3。也就是说**在记录行数一定的情况下，列的基数越大，该列中的值越分散；列的基数越小，该列中的值越集中。**这个列的基数指标非常重要，直接影响我们是否能有效的利用索引。最好为列的基数大的列简历索引，为基数太小的列的简历索引效果可能不好。 +==可以使用公式`select count(distinct a) / count(*) from t1` 计算区分度，越接近1越好，一般超过33%就算比较高效的索引了。== -可以使用公式`select count(distinct a) / count(*) from t1` 计算区分度，越接近1越好，一般超过33%就算比较高效的索引了。 - -扩展：联合索引把区分度搞(散列性高)的列放在前面。 +==扩展：联合索引把区分度搞(散列性高)的列放在前面。== #### 10. 使用最频繁的列放到联合索引的左侧 - 这样也可以较少的建立一些索引。同时，由于"最左前缀原则"，可以增加联合索引的使用率。 -#### 11. 在多个字段都要创建索引的情况下，联合索引优于单值索引 +#### 11. ==在多个字段都要创建索引的情况下，联合索引优于单值索引== ### 3.3 限制索引的数目 - image-20220627151947786 -### 3.4 哪些情况不适合创建索引 -#### 1. 在where中使用不到的字段，不要设置索引 -WHERE条件 (包括 GROUP BY、ORDER BY) 里用不到的字段不需要创建索引，索引的价值是快速定位，如果起不到定位的字段通常是不需要创建索引的。举个例子： + + + + +%%eason: 索引占空间，影响INSERT UPDATE DELETE性能%% +%%eason: MySQL通过优化器来优化查询，期间涉及对可以使用的索引进行评估，生成一个最好的执行计划，如果同时存在多个可以用的索引，会增加MySQL优化器生成执行计划的时间，降低查询性能%% +### 3.4 哪些情况不适合创建索引 +#### 1. 在where中使用不到的字段，不要设置索引 +WHERE条件 (包括 GROUP BY、ORDER BY) 里用不到的字段不需要创建索引，索引的价值是快速定位，如果起不到定位的字段通常是不需要创建索引的。举个例子： ```mysql SELECT course_id, student_id, create_time FROM student_info WHERE student_id = 41251; ``` - 因为我们是按照 student_id 来进行检索的，所以不需要对其他字段创建索引，即使这些字段出现在SELECT字段中。 #### 2. 数据量小的表最好不要使用索引 - 如果表记录太少，比如少于1000个，那么是不需要创建索引的。表记录太少，是否创建索引 `对查询效率的影响并不大`。甚至说，查询花费的时间可能比遍历索引的时间还要短，索引可能不会产生优化效果。 举例：创建表1： - ```mysql CREATE TABLE t_without_index( a INT PRIMARY KEY AUTO_INCREMENT, @@ -1675,7 +1693,6 @@ b INT ``` 提供存储过程1： - ```mysql #创建存储过程 DELIMITER // @@ -1696,7 +1713,6 @@ CALL t_wout_insert() ``` 创建表2： - ```mysql CREATE TABLE t_with_index( a INT PRIMARY KEY AUTO_INCREMENT, @@ -1706,7 +1722,6 @@ INDEX idx_b(b) ``` 创建存储过程2： - ```mysql #创建存储过程 DELIMITER // @@ -1727,7 +1742,6 @@ CALL t_with_insert(); ``` 查询对比： - ```mysql mysql> select * from t_without_index where b = 9879; +------+------+ @@ -1751,10 +1765,10 @@ mysql> select * from t_with_index where b = 9879; > 结论：在数据表中的数据行数比较少的情况下，比如不到 1000 行，是不需要创建索引的。 #### 3. 有大量重复数据的列上不要建立索引 - 在条件表达式中经常用到的不同值较多的列上建立索引，但字段中如果有大量重复数据，也不用创建索引。比如在学生表的"性别"字段上只有“男”与“女”两个不同值，因此无须建立索引。如果建立索引，不但不会提高查询效率，反而会`严重降低数据更新速度`。 举例1：要在 100 万行数据中查找其中的 50 万行（比如性别为男的数据），一旦创建了索引，你需要先 访问 50 万次索引，然后再访问 50 万次数据表，这样加起来的开销比不使用索引可能还要大。 +%%eason: 顺序读取 100 万行数据可能仅需 ​**10,000 次 I/O**​（假设每页 100 行），比索引的 ​**50 万次随机 I/O**​ 更快%% 举例2：假设有一个学生表，学生总数为 100 万人，男性只有 10 个人，也就是占总人口的 10 万分之 1。 @@ -1770,7 +1784,6 @@ CREATE TABLE student_gender( ``` 如果我们要筛选出这个学生表中的男性，可以使用： - ```mysql SELECT * FROM student_gender WHERE student_gender = 1; ``` @@ -1778,25 +1791,20 @@ SELECT * FROM student_gender WHERE student_gender = 1; > 结论：当数据重复度大，比如 高于 10% 的时候，也不需要对这个字段使用索引。 #### 4. 避免对经常更新的表创建过多的索引 - 第一层含义：频繁更新的字段不一定要创建索引。因为更新数据的时候，也需要更新索引，如果索引太多，在更新索引的时候也会造成负担，从而影响效率。 第二层含义：避免对经常更新的表创建过多的索引，并且索引中的列尽可能少。此时，虽然提高了查询速度，同时却降低更新表的速度。 #### 5. 不建议用无序的值作为索引 - -例如身份证、UUID(在索引比较时需要转为ASCII，并且插入时可能造成页分裂)、MD5、HASH、无序长字 符串等。 +例如身份证、UUID(在索引比较时需要转为ASCII，并且插入时可能造成页分裂)、MD5、HASH、无序长字符串等。 #### 6. 删除不再使用或者很少使用的索引 - 表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响。 #### 7. 不要定义夯余或重复的索引 - ① 冗余索引 举例：建表语句如下 - ```mysql CREATE TABLE person_info( id INT UNSIGNED NOT NULL AUTO_INCREMENT, @@ -1810,7 +1818,7 @@ CREATE TABLE person_info( ); ``` -我们知道，通过 idx_name_birthday_phone_number 索引就可以对 name 列进行快速搜索，再创建一 个专门针对 name 列的索引就算是一个 冗余索引 ，维护这个索引只会增加维护的成本，并不会对搜索有 什么好处。 +我们知道，通过 idx_name_birthday_phone_number 索引就可以对 name 列进行快速搜索，再创建一个专门针对 name 列的索引就算是一个冗余索引 ，维护这个索引只会增加维护的成本，并不会对搜索有什么好处。 ② 重复索引 @@ -1825,10 +1833,9 @@ INDEX idx_c1 (col1) ); ``` -我们看到，col1 既是主键、又给它定义为一个唯一索引，还给它定义了一个普通索引，可是主键本身就 会生成聚簇索引，所以定义的唯一索引和普通索引是重复的，这种情况要避免。 +我们看到，col1 既是主键、又给它定义为一个唯一索引，还给它定义了一个普通索引，可是主键本身就会生成聚簇索引，所以定义的唯一索引和普通索引是重复的，这种情况要避免。 # 第09章_性能分析工具的使用 - 在数据库调优中，我们的目标是 `响应时间更快, 吞吐量更大` 。利用宏观的监控工具和微观的日志分析可以帮我们快速找到调优的思路和方式。 ## 1. 数据库服务器的优化步骤 @@ -1860,7 +1867,6 @@ SHOW [GLOBAL|SESSION] STATUS LIKE '参数'; ``` 一些常用的性能参数如下： - * Connections：连接MySQL服务器的次数。 * Uptime：MySQL服务器的上线时间。 * Slow_queries：慢查询的次数。 @@ -1903,7 +1909,7 @@ SHOW STATUS LIKE 'Innodb_rows_%'; 一条SQL查询语句在执行前需要查询执行计划，如果存在多种执行计划的话，MySQL会计算每个执行计划所需要的成本，从中选择`成本最小`的一个作为最终执行的执行计划。 -如果我们想要查看某条SQL语句的查询成本，可以在执行完这条SQL语句之后，通过查看当前会话中的`last_query_cost`变量值来得到当前查询的成本。它通常也是我们`评价一个查询的执行效率`的一个常用指标。这个查询成本对应的是`SQL 语句所需要读取的读页的数量`。 +如果我们想要查看某条SQL语句的查询成本，可以在执行完这条SQL语句之后，通过查看当前会话中的==`last_query_cost`变量值来得到当前查询的成本。它通常也是我们`评价一个查询的执行效率`的一个常用指标。这个查询成本对应的是`SQL 语句所需要读取的读页的数量`。== 我们依然使用第8章的 student_info 表为例： @@ -1957,16 +1963,18 @@ mysql> SHOW STATUS LIKE 'last_query_cost'; +-----------------+-----------+ ``` -你能看到页的数量是刚才的 20 倍，但是查询的效率并没有明显的变化，实际上这两个 SQL 查询的时间 基本上一样，就是因为采用了顺序读取的方式将页面一次性加载到缓冲池中，然后再进行查找。虽然 页 数量（last_query_cost）增加了不少 ，但是通过缓冲池的机制，并 没有增加多少查询时间 。 +你能看到页的数量是刚才的 20 倍，但是查询的效率并没有明显的变化，实际上这两个 SQL 查询的时间 基本上一样，就是因为==采用了顺序读取的方式将页面一次性加载到缓冲池中，然后再进行查找。虽然 页 数量（last_query_cost）增加了不少 ，但是通过缓冲池的机制，并 没有增加多少 +查询时间 。== +==[[#附录：数据页加载的三种方式]]== **使用场景：**它对于比较开销是非常有用的，特别是我们有好几种查询方式可选的时候。 -> SQL查询时一个动态的过程，从页加载的角度来看，我们可以得到以下两点结论： +> ==SQL查询时一个动态的过程，从页加载的角度来看，我们可以得到以下两点结论：== > -> 1. `位置决定效率`。如果页就在数据库 `缓冲池` 中，那么效率是最高的，否则还需要从 `内存` 或者 `磁盘` 中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。 -> 2. `批量决定效率`。如果我们从磁盘中对单一页进行随机读，那么效率是很低的(差不多10ms)，而采用顺序读取的方式，批量对页进行读取，平均一页的读取效率就会提升很多，甚至要快于单个页面在内存中的随机读取。 +> ==1. `位置决定效率`。如果页就在数据库 `缓冲池` 中，那么效率是最高的，否则还需要从 `内存` 或者 `磁盘` 中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。== +> ==2. `批量决定效率`。如果我们从磁盘中对单一页进行随机读，那么效率是很低的(差不多10ms)，而采用顺序读取的方式，批量对页进行读取，平均一页的读取效率就会提升很多，甚至要快于单个页面在内存中的随机读取。== > -> 所以说，遇到I/O并不用担心，方法找对了，效率还是很高的。我们首先要考虑数据存放的位置，如果是进程使用的数据就要尽量放到`缓冲池`中，其次我们可以充分利用磁盘的吞吐能力，一次性批量读取数据，这样单个页的读取效率也就得到了提升。 +> ==所以说，遇到I/O并不用担心，方法找对了，效率还是很高的。我们首先要考虑数据存放的位置，如果是进程使用的数据就要尽量放到`缓冲池`中，其次我们可以充分利用磁盘的吞吐能力，一次性批量读取数据，这样单个页的读取效率也就得到了提升。== ## 4. 定位执行慢的 SQL：慢查询日志