减低io: 1. 次数 2. 单次的量
show variables like "%innodb%";
- 为什么B+树?
二叉树插入数据高度不可控,影响整体IO次数,影响数据访问效率.
innoDB默认读取16KB数据
在单个节点存储尽可能多数据,降低树的高度 - 存储引擎
myISAM数据和索引分开存储
myISAM和innoDB使用B+树,MEMORY使用hash表
innoDB支持自适应hash(自动选择)
使用最多是主键索引和组合索引 - 为什么不是hash表?
- 需要好的hash算法. 不合适会hash冲突和hash碰撞,会导致数据散列不均匀,会退化成链表
- 不支持范围查询.范围查询需要挨个对比,效率太低
- 需要大量的内存空间
- B+树
每个节点存储: 1. 键值,即表中记录的主键 2. 指针,存储了节点地址信息 3. 数据,即表记录中除主键外的数据
叶子节点两两指针相互连接(符合磁盘的预读特性),顺序查询性能更高
B+树有2个头指针,一个指向头节点,一个指向关键字最小的叶子节点
2种查找:1.对于主键的范围查找和分页查找 2.从根节点开始的随机查找
非叶子节点不存储数据,只存储key.叶子节点存储key和数据. 千万级别3-4层 - 聚簇索引
插入数据时,必须将数据与索引列绑定,主键,唯一键或6字节rowid
innoDB存在聚簇索引和非聚簇索引 - 分库分布
mycat,shardingsphere(推荐),drds(阿里云) -
索引
InnoDB普通索引的叶子节点存储主键值。
MyISAM的索引叶子节点存储记录指针
image.png
- 回表
select * from name="aaa";
（1）先通过普通索引定位到主键值；
（2）再通过聚集索引定位到行记录；
这就是所谓的回表查询，先定位主键值，再定位行记录，它的性能较扫一遍索引树更低
需要回表的都是非聚簇索引 - 索引覆盖
select id from name="aaa";
从索引的叶子节点就能获取全量查询列的过程
常见的方法是：将被查询的字段，建立到联合索引里去
索引覆盖场景
场景1：全表count查询优化
image
原表为：
user(PK id, name, sex)；
直接：
select count(name) from user;
不能利用索引覆盖。
添加索引：
alter table user add key(name);
就能够利用索引覆盖提效。
场景2：列查询回表优化
select id,name,sex ... where name='shenjian';
这个例子不再赘述，将单列索引(name)升级为联合索引(name, sex)，即可避免回表。
场景3：分页查询
select id,name,sex ... order by name limit 500,100;
将单列索引(name)升级为联合索引(name, sex)，也可以避免回表。
- 最左前缀
MySQL优化器会选择合适的顺序执行.and -
索引下推
show variables like "%opt%";
索引下推（index condition pushdown ）简称ICP，在Mysql5.6的版本上推出，用于优化查询。
image.png
唯一缺点需要在磁盘上多做数据筛选,数据是排序的,整体IO大大减少,所以性能提升- 在不使用ICP的情况下，在使用非主键索引（又叫普通索引或者二级索引）进行查询时，存储引擎通过索引检索到数据，然后返回给MySQL服务器，服务器然后判断数据是否符合条件 。
- 在使用ICP的情况下，如果存在某些被索引的列的判断条件时，MySQL服务器将这一部分判断条件传递给存储引擎，然后由存储引擎通过判断索引是否符合MySQL服务器传递的条件，只有当索引符合条件时才会将数据检索出来返回给MySQL服务器 。
直接根据查询条件获取数据,不需要server做任何的数据筛选(原先是在服务层,索引下推直接在搜索引擎层) -
索引条件下推优化可以减少存储引擎查询基础表的次数，也可以减少MySQL服务器从存储引擎接收数据的次数
image.png
优化器:cbo基于成本的优化,rbo基于规则的优化
-
sql优化中join 条件谓词下推
先把需要的所有字段都拿出来,然后再做关联(大数据量更好)
当表中所有字段都是索引列的时候,无论进行怎样的查询都会用到索引
不需要索引字段加索引
key
SQL调优
表结构,数据量,执行计划
网友评论