[MySQL实战45讲]MySQL笔记之索引

谁践踏了优雅 2021-10-15 10:01 434阅读 0赞

#### B+树索引和Hash索引区别 ####

哈希索引适合等值查询，但是无法进行范围查询

哈希索引没办法利用索引完成排序

哈希索引不支持多列联合索引的最左匹配规则

如果有大量重复键值的情况下，哈希索引的效率会很低，因为存在哈希碰撞问题

#### 索引失效的情况 ####

1.  对于创建的多列索引（复合索引），不是使用的第一部分就不会使用索引
2.  对于使用 like 查询， 查询如果是 ‘%aaa’ 不会使用索引，而 ‘aaa%’ 会使用到索引
3.  如果条件中有 or， 有条件没有使用索引，即使其中有条件带索引也不会使用，换言之， 就是要求使用的所有字段，都必须单独使用时能使用索引。
4.  如果列类型是字符串，那么一定要在条件中使用引号引用起来，否则不使用索引。
5.  .如果mysql估计使用全表扫描要比使用索引快,则不使用索引
6.  索引字段使用函数则不使用索引

#### 先重建索引，再重建主键索引 ####

不合理，先重建索引没问题，但是主键索引，无论删除还是创建，都会将整个表重建，所以重建索引就做了无用功。

更新索引最好的办法就是刷新引擎

> alter table T engine=InnoDB

#### 唯一索引和普通索引区别 ####

数据库更新时，并不一定会直接更新，而是会将更新放在change buffer中，等下一次读取该内存页或者定时任务执行时，才将更新同步到磁盘中。

1.  如果这个记录要更新的目标页在内存中，那么基本没有区别
2.  这个记录要更新的目标页不在内存中，那么唯一性索引需要将数据也读入内存，判断索引是否冲突，然后更新。
    
    > 对于普通索引，直接将更新记录记录在change buffer中即可。
    > 
    > 将数据从磁盘读入内存涉及随机 IO 的访问，是数据库里面成本最高的操作之一。change buffer 因为减少了随机磁盘访问，所以对更新性能的提升是会很明显的。
    > 
    > 对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时 change buffer 的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。
    > 
    > 假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记 录在 change buffer，但之后由于马上要访问这个数据页，会立即触发 purge 过程。这样随机访问 IO 的次数不会减少，反而增加了 change buffer 的维护代价。所以，对于这种业务模式来说，change buffer 反而起到了副作用。

#### redo log 和 change buffer区别 ####

redo log主要节省的是随机写磁盘的IO消耗(转成顺序写)，多个事务合并为一个事务落盘。

change buffer主要节省的则是随机读磁盘的IO消耗。多次读取磁盘至内存合并为一次读取。