临时工： 读书笔记--重读老书 《品悟性能优化》与 什么是合并设计

2024-4-16 有同学问我，合并设计这个问题，实际上我想起来这个事情应该是上个月的事情了，我提出一个问题，关于什么是合并设计的问题。

今天借着读书笔记来说说此时，再说合并设计前，我就的继续说这本书的高质量IT系统的正确认识，什么是高质量的IT 系统，高质量的IT 系统中数据库应该不会太LOW ，但高质量的数据库系统存在的项目，不一定是高质量的IT系统。这是一个必然和充分条件的关系。

很多系统中在需求分析的阶段就存在问题，如这本书中的这个章节的那个项目经理一样，不主动，不拒绝，不负责的三不渣男，只要有一个这些步骤的掌管核心工作的人，做了3不，那么这个系统的高质量就岌岌可危了。

在数据库优化的工作中，或者一个项目中对数据库提出需求的过程中，不少的任务和需求的优化都不是数据库可以决定的，经常有人说做好本职工作，但做好了本职工作，也未必这个工作的结果就能好，因为决定这个工作好不好的，并不在你，或决定性的部分不在你。

所以我们在工作中，出了把自己的工作做好以外，还需要做边际性的延伸，比如DBA 有没有必要，去听取需求分析，大概率是不需要的，但到了系统设计的阶段，到底需要不需要DBA 的介入，我认为是需要的，而系统开发和系统测试中，DBA 是必须要参加的，并根据相关的系统设计，提出在系统设计中与数据库有关的部分，提前考虑性能的问题。

如决定系统中使用的数据库由MYSQL为主，那么数据量，历史数据归档，表设计，宽表，索引设计，查询设计，等这些部分都是与这个部分相关，保证系统稳定性的部分。

而如果使用POSTGRESQL 可能这方面在主机的架构，高可用使用配置，默认schema 的设计，查询中避免出现需要marjor join 非等值的情况，等等都是需要我们注意的事情。

同时在系统开发中，JAVA 程序如何处理链接，保持链接，废弃链接，以及最大链接数据的需求等等，都可能与分库有关，或者与系统的硬件配置有关。如果此间不考虑清楚，提出问题，那么硬件的同学也不会考虑太多，后期扩展性的问题，尤其在项目初期，考虑不周的情况，为后续数据库的垂直扩展造成的麻烦。

写到这里，合并设计，这里我记得是之前在群里提出了一个关于索引的问题，我给出了一个术语合并设计。记得当时提出的是，一个数据库系统的主键系统，需要进行多个字段联合使用才能作为主键。

DBA 的同学对这个持有不同的观点，有的认为是很正常的，有的认为对性能影响较大。这些同学对于这些观点的产生，本身也是基于自身的属性来提出的，比如MYSQL的DBA 可能不太会同意，多字段主键的行为，因为这的确与数据库的数据DML 性能有关，而ORACLE PG的同学对于多字段主键的事情本身，可能就不是那么敏感，行不行可能也只是当时的一念之差。

而这里提出的合并设计，主要针对的是超出DBA 角度的观点，来提高一个维度来提出主键设计。

1 主键设计与需求有关，为什么会产生多个字段，作为联合主键的事情，来源是什么，很少DBA 会考虑这个问题。从需求来看分析，多字段形成的主键是否有必要。是否可以采用不同的方案，比如主键与业务逻辑无关的情况，那么多主键的设计就不是必须的。

或者采用多键值通过算法进行唯一值计算的方案，来将多个键值通过程序的手段，变成一个字段的值，通过这个值称为主键，来进行主键的设计。

而多字段称为主键中，还有一问题就是这些字段的值的变化，导致主键不唯一的情况，那么此时是我们用方案1 多主键 还是 2 多主键合并成 单键值的方案。这就需要推敲了。

2 多键值主键设计中，最大的问题是什么，如果这三个键值都是固定的大小，当然是好的，如果这里面有字符的问题，那么多主键是否还是一个好的设计，这必然提出疑问。

3 多主键设计中，唯一值算法的问题，算法简单，则可能有导致碰撞，那么可能我们需要更好的哈希函数，更好的hash算法，和更好的数据结构。

最终的目的是我们在发现多字段主键设计中存在问题的根源，并消灭它，而不是怪开发，怪自己的命运不济。so wake up