程序设计方法论-数据库设计

结绳记事，总结、思考，方有成长~

本人普通开发一枚，平常的工作就是接需求，设计，开发，测试，上线。而其中的设计，更多的指的就是偏向于数据库的设计。虽然现在DDD(领域驱动)大火，但还在学习阶段，鉴于当前的设计方式，进行了总结回顾，以便进行任何业务场景的开发，都有章可循。

设计包含逻辑数据库设计 和 物理数据库设计，下面分别展开。

逻辑数据库设计：构建需求对应的数据模型。根据需求文档，其中结构化的内容抽取出来，创建数据库的实体关系图（ER图），这个环节并不仅仅是“研发”参与的，还需要和“产品”同学一起，这样“产品”、“研发”更容易形成共识，减少沟通障碍，避免了让“研发”根据手机壳颜色变化的无厘头需求。

物理数据库设计：将逻辑设计在数据库中实现，比如将逻辑设计转换为物理表、选择索引、分析事物。这个环节就要考虑实体中查询场景，使用哪些字段查询，如果通过索引提高查询效率，以及是否涉及到的表之间的同步更新操作，这些内容就需要在需求文档PRD中深入挖掘，思考。
接下来将重点介绍索引的创建。
我们一般使用InnoDB引擎（默认主键即聚簇索引），基于主键的唯一查找和小范围查找是最高效的。例如，如果有很频繁的基于USERID的查找，或者对USERID的小范围遍历，那么USERID作为主键就是最高效的方式。因为数据是以USERID为顺序进行存储的。
而如果以自增ID为主键，USERID作为唯一索引或者普通索引，那么实际查询过程是这样的：首先根据USERID对应的索引找到索引记录，然后利用存储在索引中的主键值去查找主键，最终定位到记录。如果是范围查找，那么虽然索引是有序的，但最终会按照主键值去检索数据，由于主键值并不是连续的，这将产生很多物理随机读。因此这样查询代价会很高。结合下面的图，更容易理解

左侧代表的是MySQL默认的InnoDB引擎的“聚簇索引” 和 “非聚簇索引”，右侧是MySQL的MyISAM引擎，现在已经很少用了，可以忽略。我们知道“聚簇索引”的叶子节点，存储的是物理记录的指针，也就是索引顺序和物理存储顺序是一致的，找到了索引记录就找到了对应的数据。但“非聚簇索引”的叶子节点，存储的则是行的“主键值”，这意味着查询要先通过二级索引找到“主键值”，再根据主键值在聚簇索引中找到对应的行记录。性能当然比主键索引要差。

举个例子：我们平常使用字典，都会有一个目录，便于我们找到对应的内容，这个默认的目录（比如拼音），就类比InnoDB的聚簇索引，但并不是所有的场景都适合根据拼音去查询，有时候还需要根据“偏旁”、“笔画”来查询，而“偏旁”、“笔画”这样的索引对应的索引值，是“拼音”索引的位置，所以需要根据“偏旁”索引，先找到“拼音”索引的位置，再根据拼音索引来找到具体的内容。

很不幸，我所参与的项目基本都是以自增ID作为“主键”，业务主键作为“唯一索引”，而自增ID基本不会用到，所以基于业务主键的查询，都是走的“二级索引”，泪奔~

不过可以通过“覆盖索引”来避免这种情况，即查找的字段就是构建索引的字段，这样的查询直接在索引中就能获取，就避免了回表查询。