WHERE 子句中的 OR 语句,只要有条件列不是索引列,就会进行全表扫描。
10、字符串加索引
直接创建完整索引,这样可能会比较占用空间。
创建前缀索引,节省空间,但会增加查询扫描次数,并且不能使用覆盖索引。
倒序存储,再创建前缀索引,用于绕过字符串本身前缀的区分度不够的问题。
创建 hash 字段索引,查询性能稳定,有额外的存储和计算消耗,跟第三种方式一样,都不
支持范围扫描。
日志相关
11、MySQL 的 change buffer 是什么?
当需要更新一个数据页时,如果数据页在内存中就直接更新;而如果这个数据页还没有在内
存中的话,在不影响数据一致性的前提下,InnoDB 会将这些更新操作缓存在 change buffer
中。
这样就不需要从磁盘中读入这个数据页了,在下次查询需要访问这个数据页的时候,将数据
页读入内存,然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个
数据逻辑的正确性。
注意唯一索引的更新就不能使用 change buffer,实际上也只有普通索引可以使用。
适用场景:
- 对于写多读少的业务来说,页面在写完以后马上被访问到的概率比较小,此时 change
buffer 的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。
- 反过来,假设一个业务的更新模式是写入之后马上会做查询,那么即使满足了条件,将更
新先记录在 change buffer,但之后由于马上要访问这个数据页,会立即触发 merge 过程。
这样随机访问 IO 的次数不会减少,反而增加了 change buffer 的维护代价。
12、MySQL 是如何判断一行扫描数的?
MySQL 在真正开始执行语句之前,并不能精确地知道满足这个条件的记录有多少条。
而只能根据统计信息来估算记录数。这个统计信息就是索引的“区分度。
13、MySQL 的 redo log 和 binlog 区别?
14、为什么需要 redo log?
redo log 主要用于 MySQL 异常重启后的一种数据恢复手段,确保了数据的一致性。
其实是为了配合 MySQL 的 WAL 机制。因为 MySQL 进行更新操作,为了能够快速响应,
所以采用了异步写回磁盘的技术,写入内存后就返回。但是这样,会存在 crash 后 内存数
据丢失的隐患,而 redo log 具备 crash safe 的能力。
15、为什么 redo log 具有 crash-safe 的能力,是 binlog 无法替代的?
第一点:redo log 可确保 innoDB 判断哪些数据已经刷盘,哪些数据还没有
redo log 和 binlog 有一个很大的区别就是,一个是循环写,一个是追加写。也就是说 redo
log 只会记录未刷盘的日志,已经刷入磁盘的数据都会从 redo log 这个有限大小的日志文
件里删除。binlog 是追加日志,保存的是全量的日志。
当数据库 crash 后,想要恢复未刷盘但已经写入 redo log 和 binlog 的数据到内存时,binlog