一条SQL语句提交后，db2都做了什么？

一直在做 db2 数据仓库的运维工作，对一些常用操作已经非常熟悉，但是总感觉自己学到是仍然是操作的细节，而不是真正的知识。如果你问我，一条 SQL 语句提交后，db2 都做了哪些工作，我可能会有点慌，因为我不能肯定的回答出来。于是，我就搜索一些资料，结合自己的理解，总结一下关于 db2 体系结构，db2 内存模型，SQL语句的执行过程，希望对正在使用 db2 的你有所帮助。

为什么要学习架构？

如果仅满足于 select * from where 这种简单的查询，对于业务人员可能够用了，但对于程序员，这远远不够，系统初建成之后，应用的性能还可以，但随着数据的累积，一些查询会非常低效，会影响前端用户体验，如果不懂数据库架构和原理，是无法有效的调优的，也无法从根本上解决问题。相反如果了解数据库的架构，那么在最初设计数据库，设计表时就可以高瞻远瞩，把性能恶化从源头上消灭。

db2 体系结构

db2 是 c/s 架构，客户端发起 SQL 请求，服务器返回相应结果。
体系结构如下图所示：

在本地连接 db2 服务时使用共享内存和信号通信，远程连接 db2 服务器，则使用协议（例如命名管道 (NPIPE) 或 TCP/IP）进行通信。

可以这样形象地理解：如果把数据库比作大型超市，那么客户机就是消费者，请求的数据即是商品，缓冲区就是超市的货架，整个超市的空间就是数据库所用的内存，而仓库是数据的最终存储，即磁盘。

上图中的圆圈或圆圈组表示引擎分派单元（EDU），你可以理解为导购员，在计算机中叫进程或线程。如果消费者请求的商品（数据）在超市的货架上（缓冲区）中，则称为缓冲区命中，直接从货架（缓冲区）将商品拿给消费者，购物结束（花费时间较少）。否则，服务员（预取程序）需要根据仓库清单（索引）去后台仓库（磁盘）为消费者查找并取出商品，商品仍会先放在超市的货架上，再拿给消费者（花费时间较长）。

与实际情况不同的是，消费者购完商品后，商品并不真正的从货架上移出，而仍保留，一旦有人购买相同的商品时，可以直接从货架上取走从而节省时间，这是因为数据只要不删除，是可以重复读取的。

还有一种情况就是：如果两个消费者都想买同一类型的商品，恰好空间有限，同时只能有一个人占据商品所在的空间，他要检查商品来确定要不要购买，那么另一个人只能等前者确定购或者不购（回退）之后才能占据相应空间来做同样的事情，这就是死锁等待，如果超过规定的时间（死锁等待时间 dlchktime）那么这个消费者可能要报警了，这就是 911 死锁。

以上任何一个环节都有可能造成购物时间过长，消费者等待，从而导致前端用户体验极差，也就是我们常见的数据库性能下降问题。

超市的内部空间设计的好不好，直接影响购物的整体流程，因此要想打造高效地超市，就要先对超市的内部空间设计要有足够的了解，这就是 db2 的内存模型。

db2 的内存模型

理解 DB2 如何使用内存，可以防止过度分配内存，并有助于对内存的使用进行调优，从而获得更好的性能。下图为官网提供的 db2 内存模型：

db2 在 4 种不同的内存集（memory set）内拆分和管理内存。如上图所示，从上到下依次为：

1. 实例共享内存（instance shared memory）
2. 数据库共享内存（database shared memory）
3. 应用程序组共享内存（application group shared memory）
4. 代理私有内存（agent private memory）

每种内存集由各种不同的内存池（亦称堆）组成，下面依次做介绍。

1、实例共享内存

首先要理解什么是实例，从 DB2 的体系结构方面来看，实例实际上就是DB2 的执行代码和数据库对象的中间逻辑层。实例可以看成是关于所有的数据库及其对象的逻辑集合，实例为数据库运行提供一个环境。一般地，我们会那一个数据库实例用户如 xxxx_inst 用户，然后使用这个用户来安装数据库，并使用这个实例用户来启动或停止数据库服务。

DB2 数据库和实例之间的区别：数据库是物理的，我们的表、索引存放在数据库中要占物理存储的；而实例是逻辑的，是共享内存、进程和一些配置文件（实例目录）的集合。

每个 DB2 实例都有一个实例共享内存。实例共享内存是在数据库管理器启动（db2start）时分配的，并随着数据库管理器的停止（db2stop）而释放。这种内存集用于实例级的任务，例如监控、审计和节点间通信。下面的数据库管理器配置（dbm cfg）参数控制着对实例共享内存以及其中个别内存池的限