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

B+树索引和Hash索引区别

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

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

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

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

索引失效的情况

2. 对于创建的多列索引（复合索引），不是使用的第一部分就不会使用索引

3. 对于使用 like 查询， 查询如果是 ‘%aaa’ 不会使用索引，而 ‘aaa%’ 会使用到索引

4. 如果条件中有 or， 有条件没有使用索引，即使其中有条件带索引也不会使用，换言之， 就是要求使用的所有字段，都必须单独使用时能使用索引。

5. 如果列类型是字符串，那么一定要在条件中使用引号引用起来，否则不使用索引。

6. .如果mysql估计使用全表扫描要比使用索引快,则不使用索引

7. 索引字段使用函数则不使用索引

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

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

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

alter table T engine=InnoDB

唯一索引和普通索引区别

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

2. 如果这个记录要更新的目标页在内存中，那么基本没有区别

3. 这个记录要更新的目标页不在内存中，那么唯一性索引需要将数据也读入内存，判断索引是否冲突，然后更新。

   对于普通索引，直接将更新记录记录在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消耗。多次读取磁盘至内存合并为一次读取。