为什么要使用索引

类似于字典目录，根据字的偏旁能快速找到目标字

索引就是用来提升数据查询效率的，但是如果数据表数据并不多，使用索引可能事倍功半

默认不使用索引是采用全表扫描的方式

什么样的信息能成为索引？

主键、唯一键等让数据有一定区分性的字段都能成为索引

日常开发中经常被用来表关联、排序（order by/group by）等的字段也适用创建索引

索引的数据结构

索引的数据结构大致是：b-tree（B树）、b+-tree（B+树）、hash、BitMap

mysql不支持BitMap索引，基于InnoDB和MyISAM的mysql不显示支持hash索引

B+树是主流的索引数据结构

B+树相较B树更优秀，降低IO次数，主要数据都存储在叶子节点中

hash索引：

• 查询的是比较快，根据查询关键字（索引键）得到hash值后能快速定位

• hash仅能满足“=”、 “in”这类精确计算，不能使用范围查询

• 无法被用来避免数据的排序操作

• 不能使用部分索引键查询

• 不能避免表扫描

• 遇到大量hash值相等的情况后性能不一定比B树的效率高

  这些弊端导致hash索引不能成为主流索引的主要原因

BitMap基于位图，分为红黄蓝绿，存储是很方便，但是最大的弊端是使用BitMap索引是，为了防止对数据的修改，会根据位图对数据进行锁（锁的力度较大），所以不适合高并发的操作

InnoDB和MyISAM

InnoDB是密集索引，InnoDB的索引和表数据都存储在同一个物理文件中 .ibd文件

MyISAM是稀疏索引，MyISAM的索引和表数据时分两个物理文件存储的 .MYI存储索引，.MYD存储数据

MyISAM和InnoDB两者的应用场景： 1) MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。 2) InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。

SQL优化

优化的思路大致如下：

1. 根据慢日志定位慢查询sql
2. 使用expain等工具分析sql
3. 修改sql或者尽量让sql走索引/添加索引

通过慢日志入口开始优化

通过以下sql可以查看到mysql相关查询参数：

show VARIABLES like '%quer%';

show status like '%slow_queries%';

可以看到当前mysql未被重启之前，根据上面的慢查询记录机制记录的慢查询次数

重启后清零

explain执行计划

mysql中的explain关键字查询sql执行计划，关键字段如下

• type

  查询速度从最优到最差从左到右

  system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>all

  开发常见中当发现看执行计划发现type是index/all时，我们就需要考虑优化了

• extra

  开发常见两种需要优化的类型：

  Using filesort：标识Mysql无法利用表内部索引完成排序，而是用外部索引可能在内存或者磁盘上进行排序

  Using temporary：标识mysql在对查询结果排序时使用临时表

• key

  可以看到使用的是哪个列上面的索引

并不是说使用主键索引就是最快的，密集索引在索引节点上除了存储主键、关键信息外，它还存储了其它列，而稀疏索引的索引节点上只存储了主键、关键信息，所以在查询时加载速度等，稀疏索引会更快，也可能导致使用主键索引并没有使用唯一索引的速度快。

可以使用force index (索引名称)来看看哪个索引是最快的，根据实际情况指定索引查询

联合索引

最左匹配原则

索引越多越好吗？

1. 数据量小的表不需要建立索引，建立会增加额外的索引开销
2. 数据变更需要维护索引，因此更多的索引意味着更多的维护成本
3. 更多的索引意味着需要更多的空间

• Previous
  Today Study 20190530
• Next
  Today Study 20190610