工程师对于设计过程有一个清晰但通常来说也是隐含的模型，这个隐含的模型是在项目设计开始时根据目标，必要条件，约束等设计出来的，我们可以在开始设计时将条件设计出一个决策树，将各种暂时能想到的决策用树的形式展示出来，正如本章开篇所说因为设计的理念是普通的搜索理论即巨大的组合空间搜索，我是这样理解这句话，设计就是各个模块的各种可能选择最优解的组合，在项目开始设计时，将我们能想到的各种解用决策树的形式展示出来，并给每个节点（每种设计可能）一个权重，从而取出目前的最优设计.而有了这个决策树的理性模型，就更方便的和项目组中的其它成员分析项目的设计.注意：理性模型不是设计决策，而是暂定的设计方案。
mysql的innoDB存储引擎提供了缓冲池innodb_buffer_pool_size来设置缓冲池的大小，其可以缓存索引，行数据，自适应哈希索引，插入缓冲等数据，InnoDB还使用缓冲池来帮助延迟写入，这样就能合并多个写入操作，然后一起顺序地回写。之前与另一个配置query_cache_size混淆，query_cache_size在8.0中已经废除，因为如果查询缓存中使用了很大的内存，缓存失效操作会成为一个严重的问题瓶颈导致系统僵死一会(更新表中的数据会导致该表的缓存失效)，因为这个操作是靠一个全局锁保护的，所有需要该操作的查询都要等待这个锁，而且无论是检测是否命中缓存，还是缓存失效检测都需要等待这个全局锁。以下是网上找的对于这两个缓存的定义.
Qcacche缓存的是SQL语句及对应的结果集，缓存在内存，最简单的情况是SQL一直不重复，那Qcache的命令率肯定是0
buffer pool中缓存的是整张表中的数据，缓存在内存，SQL再变只要数据都在内存，那么命中率就是100%。
数据库事务需要满足ACID（原子性、一致性、隔离性、持久性）四个特性。
在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为本地事务。几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。 但是在基于微服务的分布式应用环境下，越来越多的应用场景要求对多个服务的访问及其相对应的多个数据库资源能纳入到同一个事务当中，分布式事务应运而生。
关系型数据库虽然对本地事务提供了完美的ACID原生支持。 但在分布式的场景下，它却成为系统性能的桎梏。如何让数据库在分布式场景下满足ACID的特性或找寻相应的替代方案，是分布式事务的重点工作。
项目中大家喜欢用java自带的UUID工具类去生成唯一的数据库主键，这样做的原因是简单。但mysql的innodb存储引擎的主键是聚簇索引（一种索引类型，数据与索引数据放在一起），既然数据和索引数据放在一起，那么在数据插入或者更新的时候，那么在数据插入或者更新的时候，我们需要找到要插入的位置，再把数据写到特定的位置上，这就产生了随机的 IO，而innodb存储引擎采用的是B+树的结果存储索引，一旦发生了页分裂，就不可避免会做数据的移动，也会极大地损耗写入性能,但是如果使用mysql的自增，则在分库分表下无法保证主键id的唯一性，因此我们采用twitter的snowflake算法来生成分布式的唯一id。