前言
关系型数据库是当前广泛应用的数据库类型，关系数据库计划是对数据举行组织化和结构化的过程，核心题目是关系模型的计划。对于数据库规模较小的情况，我们可以比较轻松地处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们每每会发现我们写出来的SQL语句是很笨拙并且服从低下的。表结构计划不完善，导致业务需求和可扩性非常差。因此，就有须要学习和把握数据库的规范化流程，以指导我们更好的计划数据库的表结构，减少冗余的数据，借此可以提高数据库的存储服从，数据完整性和可扩展性。下面分别从表计划规范和索引计划规范两个方面给大家分享一下关系数据库该怎样计划。
表计划规范
1. 表存储引擎建议使用InnoDB。
2. 表字符集选择UTF8 ，如果需要存储emoj表情，需要使用UTF8mb4。
3. 计划表的时候需要给表和每个字段添加中文注释。方便大家在查看表时，知道表是干什么用的，以及每个字段都是什么寄义。
4. 尽量少使用存储过程、视图、触发器、事件等。尽量简朴使用数据库，让他做自己擅长的事情，把一些复杂的运算放在业务层来实现。
5. 单表存储数据量控制在千万级以下，预估表数据大小，提前做好分区规划。
6. 建表时，最好建一个唯一标识ID字段，用来唯一的区分一行数据。
7. 建表时，表字段尽量少而精，控制在20~50个字段之间，纯int不超50，纯char不超20。
8. 建表时，尽量将字段设置为非空，并设置默认值。
9. 建表时，字段需为NULL时，需设置字段默认值，默认值不为NULL。
10. 建表时，如果字段等价于外键，应在该字段加索引。
11. 建表时，不同表之间的相同属性值的字段，列类型，类型长度，是否非空，是否默认值，需保持一致，否则无法正确使用索引举行关联对比。
12. 建表时，尽量避免使用Text/Blob大字段类型，若在必须使用且读取频率低的情况下，则将该字段拆分到一个单独的表中，让我们在读取表其它字段的时候大大的低落IO资源斲丧，从而使性能得到较大的提升。
13. 变长字符串尽量使用VARCHAR。
14. 不在数据库中存储图片、文件。将这些大文件存储交给文件系统来实现，数据库只保存文件的映射关系即可。
索引计划规范
1. 每张表必须有一个唯一主键。由于Innodb存储引擎是基于主键结构来组织数据的，如果在创建表时没有表现的指定主键，lnnodb存储引擎自己会按照如下方式选择或者创建主键。查看表中是否有非空的唯一索引，如果有，则该字段列即为主键。如果没有，会自动创建一个6字节大小的主键。
2. 关联另外一张表的主键的字段需要创建索引。
好比：账号设备表t_account_device中的字段n_account_id 关联 账号表t_account的n_id字段，则n_account_id字段需要创建索引，以加速关联查询时的查找速率，提高查询性能。
3. 避免在唯一性太差的字段上创建索引。好比：性别字段、状态字段、类型字段等。由于这种索引字段中每个值都包罗大量的数据，那么存储引擎在根据索引访问数据的时候会带来大量的随机IO，乃至有些时候还会带来大量的重复IO。
4. 需要在频仍作为条件查询且唯一性较高的字段上创建索引。提高数据查询检索的服从最有效的办法就是减少需要访问的数据量，而通过给频仍作为查询条件的字段创建索引，正是减少查询IO量的最有效办法。另外选择唯一性较高的字段，可以使访问的数据量很少，查询服从更高。
5. 避免在更新非常频仍的字段上创建索引。由于索引中的字段被更新的时候，不仅仅需要更新表中的数据，同时还要更新索引数据，以确保索引信息是准确的。这会导致IO 访问量的较大增加，不仅仅影响更新的相应时间，还会影响整个存储系统的资源斲丧，加大整个存储系统的负载。
6. 避免在不会出现在条件查询中的字段上创建索引。这样不仅不会加快查询速率，提高查询服从，还会造成在插入或者更新表数据时，性能的减慢，要创建公道必须的索引。
7. BLOB 和TEXT 类型的字段列只能创建前缀索引。这两种类型存储的数据值可能都比较大，而INNODB的索引会限制单独Key的最大长度为767字节，超过这个长度必须创建小于等于767字节的前缀索引。
8. 需要创建组合索引时，把唯一性高的字段放在索引的前面。这样能够更加有效的过滤数据。
上一篇：SQL优化这十条，口试的时候你都答对了吗？ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
楼主
