MySQL调优

1、回顾下索引的使用

text 复制代码

什么是索引?
   索引是一种让你能在 MySQL中 快速实现数据查询的这样一种数据结构
如果是将这个MySQL存储的数据必做一本书  那么我们的索引 就是这本书的目录 我们要查询这本书的目录 那么通过这个索引就能很快的定位这个位置

前面我们讲MySQL的时候 我们说 这个MySQL本身是基于文件系统的 简单的说就是 存储到文件中的 
我们的文件是存储到 硬盘上的  硬盘上就涉及到IO操作

IO的本身的效率就很低

就拿读取数据来说 我们的IO读取这个数据 包括了 磁盘的旋转 和 磁盘的寻道

磁盘的旋转的时间很短  磁盘的寻道时间很长  这个其实就是IO效率低的原因

那么我们说了 索引其实就是一种数据结构 通过这个数据结构就能快速的去定位数据的位置  所以他能提升这个效率

索引在什么时候创建呢?
  当我们在开发系统的时候 明确的感觉到这个数据的查询 需要很长的时间的时候 那么这个时候 我们就需要创建这个索引来 进行效率的提升  索引的创建不是随便创建的 一定是依赖于SQL语句的查询条件来创建的 也就是说 应该先有SQL语句 再有索引  那么有人就有疑问了 那么这个SQL语句什么时候是慢的呢? 可以通过执行计划(Explain)来追踪SQL语句评判这个SQL语句的执行下利率的高低


索引是不是 创建的越多越好呢?
  当然不是  索引一旦创建 就意味着 需要数据来进行同步 这个同步 也是需要消耗这个计算机资源的、索引创建的越多 那么SQL语句在执行的时候 需要的分析 也就越多....所以这样也能降低效率
  
  回顾下 SQL语句的运行流程是啥?
  
  JDBC--->连接MySQL服务器---->发送SQL语句---->SQL粗优化---->分析SQL语句--->计算出花费值(cost)--->选择花费值小的路径---->执行SQL语句
  
  一个SQL语句是否做索引是不是固定的? 不是固定的  (表的数据量、索引的最左前缀原理、条件值有关)

2、索引的分类

text 复制代码

单值索引
  我们的索引的列只有一个的时候 这个称为单值索引
  在innodb引擎下 我们的表在生成的时候 自动会生成 主键索引

联合索引
  索引的列有多个列构成这种称为联合索引

create  table t_user(
  id integer primary key auto_increment,
  name varchar(100),
  age int,
  position int,
  index index1(name),
  index index2(name,age),
  index index3(name,age,position)
)

alter table t_user add index index1(name)
alter table t_user add index index2(name,age)
alter table t_user add index index3(name,age,position)

3、索引的底层原理为什么是B+树

3.1、索引的底层为什么不是二叉树

text 复制代码

二叉树的特点是小数在左边 大数在右边  如果这个数据是递增的话 那么在二叉树中的排列就如上图所示 

这个索引本身也是存储到 硬盘上的  要读取这个数据的话 是不是也涉及到  IO操作  那么如果遍历的节点过多就意味着 

IO的次数可能变多，所以在极端的情况下 这个二叉树的效率是很低的 就类似咋们的全表扫描 

而且我们在单体的架构中 推荐使用的就是 自增长作为主键 恰好就是这个极端情况  所以这个二叉树并不适合做索引

3.2、索引的底层为什么不是红黑树

text 复制代码

这个红黑树和二叉树相比较而言 红黑树做索引的效率要高一些 ，但是红黑树的平衡也不彻底如果是数据量过大的话 那么依然存在要遍历很多节点的问题  这个效率本身也不高  这就是为什么不使用红黑树来做索引的底层

3.3、索引的底层为什么不是B树

text 复制代码

在B树种有个深度这个概念 

深度的意思是:每个节点上能存的数据的个数 = 深度-1

B树有什么特点呢?

B树打破了传统树一个节点 只能存储 一个数据的问题  在一个节点上能存储多个数据  而且这多个数据是有大小顺序的

他充分的利用 一个节点 存储多个数据的这个特性 来让我们找数据的时候 遍历更少的节点 从而提高这个数据的查询效率

但是这个B树是有一个致命的缺陷的?

B树最大的缺点就是不擅长做范围内的查询 .....

3.4、索引的底层为什么是B+树

text 复制代码

B+树的特点：
   所有的数据都存储到了 叶子节点
   节点和节点之间存在双向链表
   B+树中存在冗余节点  这个冗余节点的存储 其实就是典型的 以空间换时间 使用冗余节点来快速定位我们需要查询的数据的位置
   B+树还解决了 B树不擅长做范围内查询的这个问题
   假设当前的索引的列为NULL 那么这个数据是存储到 B+树上的那一个位置的呢?  如果索引的列为空 那么这个数据将存储到叶子节点的最左侧
   假设SQL语句是这样写的 select * from t_user where index is null?  这个SQL是否会走索引呢? 不会 因为这个是不能通过冗余节点去定位这个位置的

4、索引的最左前缀原理

5、各种场景的调优问题

from t_user where index is null? 这个SQL是否会走索引呢? 不会因为这个是不能通过冗余节点去定位这个位置的