前几天大连下了几十年不遇的大雪，尽管给上下班造成了不少麻烦，然而小朋友们却十分高兴，在小区里打雪仗，堆雪人。
小区的商店里居然在大卖滑雪板，一时间静谧的山谷小区竟成了游乐场，给在疫情下压抑了一年多，不能出门游览的人们免费送了一个雪乡数日游。
明天是日本人的休假日“成人の日”，所以给日本客户做技术支持的我也就在家劳动里，趁此工夫和大家持续聊聊对于数据库的那些事儿。
上次咱们谈到了“ 随机 I /O”的寻道工夫是如何对数据块读写产生的的影响，明天咱们来聊聊聪慧的工程师们想了那些办法来解决或者说改善这些问题的。
先说“ 随机 I /O”对写操作的影响的解决办法，这里的“写”专门指数据块更新（“UPDATE”和“DELETE”）时的写操作，“INSERT”当然也收到随机 I / O 的影响，然而波及到的数据块查找算法和更新时不同，
咱们明天不在这里赘述了。当然如果有同学想认真理解一下“INSERT”是的数据块查找动作，能够留言，咱们在当前找机会详述。
因为更新（“UPDATE”和“DELETE”）操作是依据“Where”条件对特定的数据块进行写操作，所以对这些数据块更新时将不可避免产生“ 随机 I /O”，那么如何解决这个看似没法解决的问题呢。
大家一起来思考 5 分钟。
对了，就是先把这些更新数据块的操作写到一个文件 — Redo Log 中。
那么为什么下面的办法就能够解决“ 随机 I /O”问题呢，因为这是一个把“ 随机 I /O”转化为“ 间断 I /O”的办法。
上面咱们先来说一下什么是“ 间断 I /O”，在上一篇文章里咱们晓得了 HDD 硬盘的寻道办法，所以如果写操作不是针对特定的数据块，而是间接寻道到 Redo Log 文件的最初，而后间断写多个扇区的话，
那么“ 随机 I /O”中节约掉的寻道工夫将会大大放大。这就是传统的 HDD 硬盘的“ 间断 I /O”。
那么问题来了，数据块的变动被写到了 Redo Log 中，仿佛并没有达到咱们的目标，把变动更新到数据块中去。
不错，咱们只是进行了上面的解决，就通知 APPLICATION 数据库更新结束了。
1. 把更新对象数据块读到内存。2. 把更新写到内存中的数据块。3. 当满足肯定条件货或有 Commit 申请时，把更新以“** 间断 I /O**”写到 Redo Log。4. 通知 APPLICATION 说数据库更新结束了。那什么时候写数据块呀？呵呵，这个能够用后盾 Process 偷偷的做就能够呀。
当初把后面说的简略的总结一下：为了改善 HDD 硬盘的“ 随机 I /O”对更新（“UPDATE”和“DELETE”）解决的影响，所以引进了“Redo Log”，用“Redo Log”文件的“ 间断 I /O”代替“ 随机 I /O”。
是不是感觉听起来怪怪的，以前只据说“Redo Log”是备份回复数据用的，没听说过还有这个作用呀？
对的，这是“Redo Log”的另外一个重要的作用，然而用“ 间断 I /O”改善“ 随机 I /O”的因素也的确是一个重要的思考。
这也是为什么以 ORACLE 为主的 RDBMS 关系数据库都波及了 REDO LOG，并且把写 LOG 文件放在写数据文件之前。
说完了“ 随机 I /O”对写操作的影响的解决办法，上面咱们来聊聊它对读操作（SELECT）的影响的解决办法。
因为数据被存在数据库里（“INSERT”）以及前期的更新（“UPDATE”和“DELETE”），体现的都是数据的原始价值，既数据被平安的保留了起来。
而对数据的查问（“SELECT”）则体现了数据的附加价值，既数据能够依据各种各样的需要被检索进去，为了价值更高的行为或决策提供根据。
所以任何一款数据库对 SELECT 的优化的是重中之重，具体方法也是八仙过海，各显神通。
基于以上的起因和我本身常识的有余，明天就不能都一一阐明了，咱们只是从如何缩小“ 随机 I /O”的观点来简略的阐明一下。
以 ORACLE 为主的关系数据库用以下两个办法缩小“ 随机 I /O”：
1. 利用内存缓存（Buffer Cache）来寄存被读进来数据块，并且共享给所有 PROCESS。这样就能够尽可能的升高同一数据块的重复读入。
把这个思维倒退到极致就是例如 HANA 之类的内存数据库。当然还有相似 Redis 之类的中间件数据库，他能够帮忙 Mysql 之类的内存缓存算法不欠缺的数据库提供额定的内存缓存性能。2. 把同一列，而不是同一行的数据存在一个数据块里，以不便 SUM，AVG 之类的集计解决。
利用这个思路做成的数据库就是驰名的 数据仓库（Data Warehouse）。起初 ORACLE 在 12c 以上的版本里提出了“In Memory”概念，其实就是在传统的“行存储”数据库的内存里，独自开拓出一块内存区域，在这个区域里数据以“列存储”的形式提供给 SELECT 拜访。这个理念也被起初的 TiDB 以“KiFlash”形式采纳了。明天就写到这里吧。
下篇文章聊聊多个 PROCESS 同时更新一条数据记录时解决形式。
2021/01/11 @ Dalian