简介
我们知道查询优化问题其实是一个搜索问题。基于代价的优化器 ( CBO ) 由三个模块构成：计划空间、搜索算法和代价估计 [1] ，分别负责“看到”最优执行计划和“看准”最优执行计划。如果不能“看准”最优执行计划，那么优化器基本上就是瞎忙活，甚至会产生严重的影响，出现运算量特别大的 SQL ，造成在线业务的抖动甚至崩溃。
在上图中，代价估计用一个多项式表示，其系数 c 反应了硬件环境和算子特性，而数值 n 则由查询条件基于统计信息计算而得到。
现在主流的评估模型
历史数据归档的问题
大部分业务数据的读写特征，都是最新产生的数据会更频繁的被读取或者更新，而更久之前的数据(如1年之前的聊天记录，或者订单信息）则很少会被访问， 而随着业务运行时间的增加，数据库系统中会沉淀大量很少甚至不会被访问到的数据，这部分数据和最新产生的数据混合在一起会产生一系列问题：
历史数据和最新的数据存储在一个数据数据库系统中，导致磁盘空间不足。
大量数据共享数据库内存缓存空间，磁盘IOPS等，导致性能问题。
数据量太大导致数据备份时间过长甚至失败
Page cleaner
刷脏流程
主要的代码和流程在参考文档 3，4 这种已经讲解的比较清楚了，一个 Coordinator 线程负责处理刷脏请求，计算刷脏的量，然后分配给几个 Worker 线程去刷不同的 Buffer Pool Instance, 完成刷脏后，Coordinator 线程进入下一轮刷脏。
Coordinator 和 Worker 之间通过 page_cleaner->slots[i]->state 来协同，page_cleaner_st
这么快到2020年底了，看到Oracle 21c文档中的一些功能，想想AliSQL在2020年也做了不少事情，也有必要总结分享一下。为了让大家更好地知道有哪些特性，可以在哪些业务场景中使用到，也是为了2021年更好的向前发展。在年初时计划的一些企业级功能基本上都实现了，并且在过程中特别强调了功能的场景通用性，不再是从某个行业某个特定业务或应用场景设计（比如电商秒杀），而是从云上众多用户的不同场景出发，并且不需要用户应用或SQL改造配合（直接一个开关就可以开启的），还要求在RD
传统的关系型数据库有着悠久的历史，从上世纪60年代开始就已经在航空领域发挥作用。因为其严谨的强一致保证以及通用的关系型数据模型接口，获得了越来越多的应用，大有一统天下的气势。这期间，涌现出了一批佼佼者，其中有优秀的商业化数据库如Oracle，DB2，SQL Server等，也有我们耳熟能详的开源数据库MySQL及PostgreSQL。这里不严谨的将这类传统数据库统称为SQL数据库。
SQL to NoSQL
2000年以后，随着互联网应用的出现，很多场景下，并不需要传统关
背景
MySQL默认的存储引擎是InnoDB，而引入Secondary Engine，用来实现同时支持多引擎，在同一个MySQL Server上挂多个存储引擎，在支持InnoDB的同时，还可以把数据存放在其他的存储引擎上。
全量的数据都存储在Primary Engine上，某些指定数据在Secondary Engine 上也存放了一份，然后在访问这些数据的时候，会根据系统参数和cost选择存储引擎，提高查询效率。
在最新版本8.0.22上还支持了启动和停止某个Seconda
InnoDB的二级索引创建进入的主要函数为row_merge_build_indexes()，其整个过程大致可以分为三个步骤：扫描主建索引row_merge_read_clustered_index()、按照新的key排序row_merge_sort()、建立新的索引树row_merge_insert_index_tuples()。我们将按照这三个步骤来介绍二级索引的创建过程。
扫描主键索引——row_merge_read_clustered_index()
由于在Inno
本文介绍 B-tree 物理结构的并发控制，主要讨论设计 B-tree 加锁规则时需要解决几个问题。
参考论文《A Survey of B-Tree Locking Techniques》
InnoDB 的相关实现参考这篇月报：http://mysql.taobao.org/monthly/2020/06/02/
lock 和 latch 的区别
B-tree 索引的并发控制需要考虑两个方面：
事务 transaction 并发访问数据内容时的并发控
什么是statement digest
在MySQL中，performance_schema库中存储server执行过程中各种”event”相关的数据，通过这些数据，可以从多维度分析数据库的性能，比如SQL执行，文件I/O，锁等待等。
一些数据表会存储执行过的SQL语句和其digest，比如表events_statements_summary_by_digest中的第二个和第三个列，digest其实是一个MD5 hash值，接下来简单介绍下digest的生成过程。
My
MySQL version (8.0)
It’s quite common for database kernel engineers to debug the lock related issue. Hence
it’s import for us to understand the lock information from debugger.
Basic Data Structure
There are two major data structures we ne
