Mysql-其他篇

mysql还有一些内容之前的篇幅没有提到，统一在这篇文章里补充一下。

三种log

undo log

前面我们学到了，每次修改数据都会生成undo log，它记录的是与操作相反的逻辑日志。主要作用是回滚和MVCC。

binlog

记录对数据库表结构和数据进行变更操作的sql语句日志，主要作用是复制和恢复，像读写分离中使用的主从复制就是借助于binlog实现的。binlog记录的是逻辑变化，即语句的原始逻辑。

redo log

数据库对数据进行修改不是直接在磁盘里修改的，而是先把数据页加载到内存中，在内存中对数据页进行相应的操作，之后，会在redo log里记录对数据页做了哪些修改。内存中数据页flush到磁盘前叫做脏页，会异步写到磁盘内，但是为了防止内存页刷磁盘这一步因数据库意外故障而导致修改失效，redo log可以保障内存恢复到故障前的状态。因为和页，磁盘相关，redo log记录是物理变化，即在某个数据⻚上做了什么修改。

内存中对于读写都是有缓冲池的。对于写缓冲change buffer来说，数据都是先加载到change buffer中，避免每次都直接操作磁盘，缓冲池中修改的部分会定期刷磁盘。或者，在一些别的情形下也会主动刷磁盘。比如，有一个后台线程，会认为数据库空闲时；数据库缓冲池不够用时；数据库正常关闭时；redo log写满时等等。

redo log和binlog的一些区别

• redo log记录的物理变化如果在内存中被写到磁盘里了，那么对应的log会被之后添加的新log覆盖，所以redo log记录的不是所有历史数据的变更
• redo log的日志是循环写的，会覆盖之前的日志，binlog是追加写，不会覆盖以前的日志。
• binlog是server层产生的，而redo log是InnoDB引擎产生的。
• redo log和binlog是存在于一个事务中的，redo log在事务开始时写入，写入成功后事务变成prepare状态，事务提交前写入binlog，写入成功并提交事务后事务变成commit状态，这个操作叫做两阶段提交。两阶段提交保证redo log和binlog必须同时成功，事务才算执行成功。

隐式转换

试想一下，一张表table有个字符串字段a并且设置了索引，假设存在数据a='1'那么
select * from table where a = 1
这句sql，能不能命中索引？

反过来，如果字段a类型是int类型
select * from table where a = '1'
又能不能命中索引呢？

答案是前者不能命中索引，后者可以命中索引。因为当索引字段类型和查询值类型不同时，mysql内部会进行隐式转换，隐式转换的规则如下：

隐式转换规则

• 两个参数至少有一个是 NULL 时，比较的结果也是 NULL，例外是使用 <=> 对两个 NULL 做比较时会返回 1，这两种情况都不需要做类型转换
• 两个参数都是字符串，会按照字符串来比较，不做类型转换
• 两个参数都是整数，按照整数来比较，不做类型转换
• 十六进制的值和非数字做比较时，会被当做二进制串
• 有一个参数是 TIMESTAMP 或 DATETIME，并且另外一个参数是常量，常量会被转换为 timestamp
• 有一个参数是 decimal 类型，如果另外一个参数是 decimal 或者整数，会将整数转换为 decimal 后进行比较，如果另外一个参数是浮点数，则会把 decimal 转换为浮点数进行比较
• 所有其他情况下，两个参数都会被转换为浮点数再进行比较

根据规则我们可以知道，上述的问题实际上是将两个不同的参数转换成了浮点数来比较。前者为什么不能使用到索引，因为左侧本来是字符串类型的字段索引，现在转成了浮点数来比较，而又有很多字符串都可以转成浮点数1，比如'1a','1b'，这对于索引树来说是没法定位的，也就没法使用索引了。反过来，第二种情况，左侧的值是固定的，不需要关心右边是哪一种字符串转的浮点数，都可以通过左侧唯一的值来找到索引。