Update 高性能实践篇.md

lvminghui · web-flow · commit 3daa8f830e9b · 2020-04-16T20:56:48.000+08:00
diff --git a/docs/高性能实践篇.md b/docs/高性能实践篇.md
@@ -168,8 +168,7 @@ MySQL数据库提供的功能很全面，但并不是所有的功能性能都高
 
 存储字节越小，占用空间越小。尽量选择合适的整型，如下图所示。
 
-<img src="C:\Users\吕明辉\AppData\Roaming\Typora\typora-user-images\各字节类型占用的空间.png"  style="zoom:80%;" />
-
+<img src="https://github.com/lvminghui/Java-Notes/blob/master/docs/typora-user-images/各字节类型占用的空间.png" style="zoom: 80%;" />
 建议：
 
 * 主键列，无负数，建议使用INTUNSIGNED或者BIGINTUNSIGNED；预估字段数字取值会超过42亿，使用BIGINT类型。
@@ -243,8 +242,7 @@ InnoDB自适应哈希索引是为了提升查询效率，InnoDB存储引擎会
 
 如下图所示为一个简单的、标准的 B+tree，每个节点有 K 个键值和 K+1 个指针。
 
-<img src="C:\Users\吕明辉\AppData\Roaming\Typora\typora-user-images\B+树.png" style="zoom:80%;" />
-
+<img src="https://github.com/lvminghui/Java-Notes/blob/master/docs/typora-user-images/B+树.png" style="zoom: 80%;" />
 B+Tree索引能够快速访问数据，就是因为存储引擎可以不再需要通过全表扫描来获取数据，而是从索引的根结点（通常在内存中）开始进行二分查找，根节点的槽中都存放了指向子节点的指针，存储引擎根据这些指针能快速遍历数据。
 
 叶子节点存放的 <key+data> ，对于真正要存放哪些数据还得取决于该 B+Tree 是聚簇索引（Clustered Index）还是辅助索引（Secondary Index）。
@@ -377,9 +375,7 @@ Range使用了records_in_range函数估算每个值范围的rows，结果依赖
 ### 案例二
 
 优化前有一个索引idx_global_id。图中的这条SQL语句的where条件包括一个sub_id的等值查询和一个global_id的范围查询。执行一次需要2.37秒。从下一页的执行计划中，我们可以看到虽然查询优化器使用了唯一索引uniq_subid_globalid，但是由于idx_global_id的干扰，实际只使用了前面的4个长度就access，剩余8个长度都被filter了。
-
-<img src="C:\Users\吕明辉\AppData\Roaming\Typora\typora-user-images\查询优化.png" style="zoom:80%;" />
-
+<img src="https://github.com/lvminghui/Java-Notes/blob/master/docs/typora-user-images/查询优化.png" style="zoom: 80%;" />
 从优化后的执行计划中可以看到，使用了forceindex来强制使用唯一索引。正如上文列举的，相似的命令还有ignoreindex忽略索引，straght_join强制优化器按特定的顺序使强制优化器按特定的顺序使用数据表，high_priority 或 low_priority 两个命令来控制 SQL 的执行优先权。
 
 ### ICP,MRR,BKA
@@ -434,6 +430,24 @@ MySQL 可以通过设置一些参数，将运行时间长或者非索引查找
 * 参数 log_throttle_queries_not_using_indexes，表示每分钟记录到慢查询文件中未使用索引的 SQL 语句上限，0 表示没限制。
 * 参数 max_execution_time，用来控制 SELECT 语句的最大执行时间，单位毫秒，超过此值MySQL 自动 kill 掉该查询。
 
+
+
+<img src="https://github.com/lvminghui/Java-Notes/blob/master/docs/typora-user-images/慢查询例子.png" style="zoom: 80%;" />
+如上图所示是一个慢查询的例子，通过这个例子你可以看到慢查询文件中记录了哪些信息。包括了慢SQL产生的时间，SQL源自的IP和对应的数据库用户名，以及访问的数据库名称；查询的总耗时，被lock 的时间，结果集行数，扫描的行数，以及字节数等。当然还有具体的 SQL 语句。
+
+分析慢查询常用的工具有：
+
+explain；
+
+Mysql dump slow，官方慢查询分析工具；
+
+pt-query-digest，Percona公司开源的慢查询分析工具；
+
+vc-mysql-sniffer，第三方的慢查询抓取工具；
+
+pt-kill，Percona公司开源的慢查询kill工具，常用于生产环境的过载保护。
+
+这里重点介绍pt-query-digest，它是用于分析MySQL慢查询的一个常用工具，先对查询语句的条件进行参数化，然后对参数化以后的查询进行分组统计，统计出各查询的执行时间、次数、占比等，同时把分析结果输出到文件中。也可以结合 Anemometer 工具将慢查询平台化展示。
 ## 如何优化SQL
 
 1. 全表扫描还是索引扫描。对于小表来说，二者IO调用次数和返回时间相差不大；但对于大表，如果全表扫描，那么查询返回的时间就会很长，就需要使用索引扫描加快查询速度。但并不是要求DBA根据每一种查询条件组合都要创建索引，索引过多也会降低写入和修改的速度，而且如果导致表数据和索引数据比例失调，也不利于后期的正常维护。
