本文主要是介绍[MySQL实战45讲]MySQL笔记之索引，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
B+树索引和Hash索引区别
哈希索引适合等值查询，但是无法进行范围查询
哈希索引没办法利用索引完成排序
哈希索引不支持多列联合索引的最左匹配规则
如果有大量重复键值的情况下，哈希索引的效率会很低，因为存在哈希碰撞问题
索引失效的情况
-
对于创建的多列索引（复合索引），不是使用的第一部分就不会使用索引
-
对于使用 like 查询， 查询如果是 ‘%aaa’ 不会使用索引，而 ‘aaa%’ 会使用到索引
-
如果条件中有 or， 有条件没有使用索引，即使其中有条件带索引也不会使用，换言之， 就是要求使用的所有字段，都必须单独使用时能使用索引。
-
如果列类型是字符串，那么一定要在条件中使用引号引用起来，否则不使用索引。
-
.如果mysql估计使用全表扫描要比使用索引快,则不使用索引
-
索引字段使用函数则不使用索引
先重建索引，再重建主键索引
不合理，先重建索引没问题，但是主键索引，无论删除还是创建，都会将整个表重建，所以重建索引就做了无用功。
更新索引最好的办法就是刷新引擎
alter table T engine=InnoDB
唯一索引和普通索引区别
数据库更新时，并不一定会直接更新，而是会将更新放在change buffer中，等下一次读取该内存页或者定时任务执行时，才将更新同步到磁盘中。
-
如果这个记录要更新的目标页在内存中，那么基本没有区别
-
这个记录要更新的目标页不在内存中，那么唯一性索引需要将数据也读入内存，判断索引是否冲突，然后更新。
对于普通索引，直接将更新记录记录在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消耗。多次读取磁盘至内存合并为一次读取。
这篇关于[MySQL实战45讲]MySQL笔记之索引的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
