MySQL索引及数据库性能分析工具介绍

一、索引

概念及本质

索引是帮助mysql高效获取数据的数据结构，本质是数据结构

优缺点

优点：降低数据库的IO成本，（唯一索引）保障数据唯一性，减少查询中分组和排序的时间

缺点：创建维护索引要耗费时间、占用磁盘空间，降低表更新速度。

索引分类

从功能逻辑上说，分为：普通索引、唯一索引、单列索引、主键索引、全文索引。
从物理实现方式，分为：聚簇索引、非聚簇索引。
从作用字段个数，分为：单列索引、联合索引

聚簇索引

概念及特点

即主键索引

1. 根据 主键值 的大小进行记录和页的排序：

• 页内的记录按照主键的大小顺序排成一个单向链表
• 每个存放用户记录的页根据主键大小顺序排成一个双向链表
• 存放目录记录的页分为不同层次，同层的页根据目录页记录的主键值大小顺序排成一个双向链表

2. B+树的每个叶子节点存储的是完整的用户记录

优缺点

优点：

1. 提高（基于主键的）查询、排序、范围查找的速度。
2. 随机IO变为顺序IO，节省IO操作

缺点：

1. 插入速度严重依赖于插入顺序（造成页分裂），主键设置为自增时可以使数据插入变为顺序插入，速度最快。
2. 更新主键代价高（导致整条用户记录的移动），可设置为不可更新。
3. 二级索引访问需要两次索引查找，第一次找到聚簇索引，第二次根据聚簇索引找到数据

二级索引（辅助索引、非聚簇索引）

1.根据二级索引的大小进行记录和页排序
2.每个叶子节点存储了索引信息和主键信息
3.查询用到二级索引时可能会进行回表操作

联合索引

1.多个字段共同作为一个索引
2.根据联合索引中第一个字段排序、第一个字段相等时根据第二个字段排序，以此类推来排列每条记录和页
3.只生成1棵B+树

不同存储引擎中的索引方案

B树索引适用的存储引擎

索引/存储引擎	MyISAM	InnoDB	Memory
B-Tree	支持	支持	支持

MyISAM、InnoDB默认索引B+树，Memory默认hash索引

MyISAM

• 使用B+树作为索引结构，叶子节点的data域存放的是数据记录的地址
• 所有的索引都是非聚簇索引

InnoDB

1. 根页面位置万年不动
2. 内节点中目录项记录的唯一性
3. 一个页面最少存储两条记录

MyISAM与InnoDB对比

1. InnoDB聚簇索引查询时，只需要查询一次。MyISAM无聚簇索引，全是非聚簇的，查询时需要回表。
2. InnoDB的数据文件就是索引文件，MyISAM的数据和索引是分离的两个文件，索引文件保存数据地址
3. InnoDB的非聚簇索引data域存的主键，MyISAM存的数据地址
4. 因为MyISAM存的数据地址，回表操作快
5. InnoDB要求表必须有主键，MyISAM可以没有。

mysql8.0索引新特性

1. 支持降序索引

alter table tablename add index （a，b desc）

2. 支持隐藏索引

索引被隐藏，即对优化器不可见。但索引的内容依然会根据数据变化更新。
如果索引需要长时间隐藏，建议删除

索引设计原则

适合建立索引的场景

1. 字段的数值有唯一性限制
2. 频繁作为where查询的字段
3. 经常group by和order by的列
4. update、delete的where条件列
5. distinct字段需要创建索引
6. 多表join连接
   a.连接表数量不要超过3张
   b.对where查询条件创建索引
   c.对于连接的字段创建索引
7. 使用列的类型小的创建索引
8. 使用字符串前缀创建索引
   确定前缀截取长度：计算字段在全部数据中的选择度：

select count(distinct address) /count(*) from shop;

9. 区分度高（散列行高）的列适合作为索引
10. 使用最频繁的列放到联合索引的左侧
11. 在多个字段都要创建索引的情况下，联合索引由于单值索引

不适合建立索引的场景

1. where中使用不到的字段
2. 数据量小的表
3. 有大量重复数据的列
4. 避免对经常更新的表创建过多索引
5. 不建议用无序的值作为索引
6. 删除不再使用或者很少使用的索引
7. 不要定义冗余或重复的索引
   ①冗余索引：单列索引与联合索引的第一列重复
   ②重复索引：对某一列同时设置为主键、普通索引

二、数据库性能分析

数据库服务器的优化步骤

1. 观察服务器状态，是否存在周期性波动，存在则考虑调整缓存-加缓存更改缓存失效策略，否则考虑第二项
2. 开启慢查询，如果sql执行时间长，分析慢sql，进行sql优化，如果sql等待时间长，调优服务器参数，如果依然无法解决考虑第三项
3. sql查询是否达到瓶颈，做读写分离（主从架构）、分库分表（垂直分库、垂直分表、水平分表）
   小结： 对sql的优化成本最低效果最显著

性能分析工具

查看服系统性能参数

SHOW [GLOBAL|SESSION] STATUS LIKE '参数';

统计SQL的查询成本：last_query_cost

使用场景：它对于比较开销是非常有用的，特别是我们有好几种查询方式可选的时候。

定位执行慢的 SQL：慢查询日志

开启慢查询

mysql > set global slow_query_log='ON';

慢查询日志分析工具：mysqldumpslow

查看 SQL 执行成本：SHOW PROFILE

※分析查询语句：EXPLAIN

EXPLAIN四种输出格式

传统格式 ， JSON格式 ， TREE格式 以及 可
视化输出。

1. json格式
   json格式的内容最详细。含有成本“cost_info”

"cost_info": {
"read_cost": "1840.84",
"eval_cost": "193.76",
"prefix_cost": "2034.60",
"data_read_per_join": "1M"
}

• read_cost 是由下边这两部分组成的：
  IO 成本
  检测 rows × (1 - filter) 条记录的 CPU 成本
• eval_cost 是这样计算的：
  检测 rows × filter 条记录的成本。
  prefix_cost 就是单独查询 s1 表的成本，也就是：
• read_cost + eval_cost
  data_read_per_join 表示在此次查询中需要读取的数据量。

2. tree格式
   根据查询的 各个部分之间的关系 和 各部分的执行顺序来描述如何查询。

mysql监控分析视图-Sys schema视图

1. 主机相关：以host_summary开头，主要汇总了IO延迟的信息。
2. Innodb相关：以innodb开头，汇总了innodb buffer信息和事务等待innodb锁的信息。
3. I/o相关：以io开头，汇总了等待I/O、I/O使用量情况。
4. 内存使用情况：以memory开头，从主机、线程、事件等角度展示内存的使用情况
5. 连接与会话信息：processlist和session相关视图，总结了会话相关信息。
6. 表相关：以schema_table开头的视图，展示了表的统计信息。
7. 索引信息：统计了索引的使用情况，包含冗余索引和未使用的索引情况。
8. 语句相关：以statement开头，包含执行全表扫描、使用临时表、排序等的语句信息。
9. 用户相关：以user开头的视图，统计了用户使用的文件I/O、执行语句统计信息。
10. 等待事件相关信息：以wait开头，展示等待事件的延迟情况。