一、背景
这是电商数据库设计及优化学习笔记的一个部分，这个部分主要是数据库设计规范的内容。
二、数据库设计规范
- 主要分为逻辑设计和物理设计
- 在实际工作中在进行逻辑设计时也会进行相应的物理设计。
- 物理设计包括设计表名、字段名、字段类型等等。
- 在公司中工作时如果公司中已经有的数据库设计规范，那么一定要按照公司中的规范来设计数据库，如果公司还没有规范，要尽快建立起规范。
- 在本次项目中的规范：
*数据库命名规范：
用数据库命名策略，帮助我们从数据库名称就能了解数据库的内容以及作用。
*数据库基本设计规范：
常见的数据库的设计方式
*数据库索引设计规范：
提供了一些索引选择的常规方式和索引优化的建议和技巧。
*数据库字段设计规范：
正常情况下该如何选择字段的类型
*SQL开发规范
帮助开发人员编写更好的SQL语句
*数据库操作行为规范
统一运维标准，减少因为运维因素而导致的数据库故障
6.本项目中数据库规范的具体内容
6.1 数据库命名规范：
所有的数据库名、列名必须使用小写字母，每个词语之间用下划线进行分割；
所有的数据库名称禁止使用MySQL保留关键字；
数据库对象的命名要能做到见名识义，最好不要超过32个字符；
表名列名太长了不仅不方便使用，还会增加网络传输开销。临时库表必须以tmp为前缀，以日期为后缀；
备份库，备份表必须以bak为前缀并以日期为后缀；
所以存储相同数据的列名和列类型必须一致；
6.2 数据库存储规范：
所有表必须使用Innodb存储引擎；
如今的mysql版本来说，所有的新开发的应用，如果没有特殊需求都应该使用Innodb存储引擎。
这是mysql5.6以后的默认引擎，支持事务，行级锁，具有更好的恢复性，高并发下性能更好数据库和表的字符集统一使用UTF8
原因：兼容性好。统一可以避免由于字符集不统一而产生乱码。 mysql中 UTF8汉字占用3个字节，ASCLL码占用1个字节。所有的表和字段都要添加注释；
在建表时使用comment从句添加表和列的备注。这样做的目的是从一开始就进行数据字典的维护。
尽量控制单表数据量大小，建议控制在500w行以内
但是500w不是数据库的限制，限制取决于存储设备和文件系统。 控制大小的方法：可以用历史数据归档和分库分表（主要用于业务数据上）等手段。谨慎使用mysql分区表；
分区表在物理上表现为多个文件，逻辑上表现为一个表。 使用分区表要谨慎选择分区键，跨分区查询效率可能更低。 建议采用物理分表的方式管理大数据尽量做到冷热数据分离，减少表的宽度；
是为了减少磁盘io，保证热数据的内存缓存命中率。 更有效地利用缓存，避免读入无用的冷数据。 经常一起使用的列放到同一个表中禁止在表中使用预留字段
预留字段的命名很难做到见名识义 预留字段无法确认存储的数据类型，所以无法选择合适的类型 对预留字段类型的修改会对表进行锁定
修改字段类型的成本远大于增加字段禁止在数据库中存储图片，文件等二进制数据
正确的做法是图片 文件存储到服务器中，在数据库中存储地址禁止在线上做数据库压力测试环境；
禁止从开发环境、测试环境、来直接连接生产环境的数据库；
6.3 索引设计规范：
索引对数据库的查询性能非常重要 不要滥用索引
限制每张表上索引的数量，建议单张表索引不超过5个；
索引不是越多越好，索引可以提高效率，同样可以降低效率 禁止给表中的每一列都建立单独的索引每个Innodb表必须有一个主键
不能使用更新频繁的列作为主键，不适用多列主键。 不使用UUID,MD5,HASH，字符串列作为主键。 主键建议选择使用自增ID值避免建立冗余索引和重复索引
对于频繁查询优先考虑使用覆盖索引
好处：避免Innodb表进行索引的二次查找，可以把随机IO变为顺序IO，加快查询效率尽量避免使用外键约束
外键可用于保证数据的参照完整性，但建议在业务端实现，外键会影响父表和子表的写操作从而降低性能常见索引列建议
select、update、delete语句的where从句中的列 包含order by、group by、distinct中的字段
多表join的关联列索引列的顺序
索引是从左到右来使用的 索引作用：查询时可以通过索引进行查找，减少磁盘随机IO，增加磁盘性能
区分度最高的列放在联合索引的最左侧
主键，值唯一的列
尽量把字段长度小的列放在联合索引的最左侧
使用最频繁的列放在最左侧
6.4 数据库字段设计规范
优先选择符合存储需要的最小的数据类型
将字符串转化为数字类型来存储 对于非负整数来说，优先使用无符号整型数据进行存储
VARCHAR(n)中的n代表的是字符数，而不是字节数 使用UTF8存储汉字Varchar（255）=765个字节
过大的长度会消耗更多的内存尽量避免在表中使用TEXT,BLOB数据类型
建议把blob或者text列分离到单独的扩展列表中 text或者blob类型只能使用前缀索引避免使用ENUM数据类型
修改ENUM值需要使用ALTER语句 ENUM类型的ORDER BY操作效率低 禁止使用数值作为ENUM的枚举值尽可能把所有列定义为NOT NULL
索引NULL列需要额外的空间来保存，所以需要占用更多的空间 进行比较和计算时对NULL做特别处理不要用字符串存储日期型的数据，使用TIMSTAMP或DATETIME
缺点： 1、无法使用日期函数进行计算和比较 2、占空间同财务相关的金额类数据，必须使用decimal类型
double和float是非精准数据类型，decimal是精准数据类型，在计算时不会丢失精度，其占用的空间由定义的宽度决定，可用于存储比bigint更大的数。
* 6.5 数据库SQL开发规范*建议使用编译语句进行数据库操作
优点1：除了第一次进行预编译外，其他时间进行语句调用时，只传递相关参数就可以了，比每次都传递SQL更节省带宽，性能更高。
优点2：使用预编译时可以进行一次解析，多次使用。 可以防范SQL注入的风险避免数据类型的隐式转换
隐式转换会导致索引丢失充分利用表上已经存在的索引
避免使用双%好的查询条件 一个SQL只能利用到符合索引中的一列进行范围查询 使用left join 或 not exists来优化not
in在数据库开发时应该考虑到以后的数据库拓展
程序连接不痛的数据库要使用不同账号，禁止跨库查询
为数据库迁移和分库分表留出余地 降低业务耦合度禁止使用 SELECT *，必须使用SELECT <字段列表>查询
消耗更多的CPU和IO以及带宽 无法使用覆盖索引 可减少表结构的变更带来的影响禁止使用不含字段列表的INSERT语句
可减少表结构的变更带来的影响禁止使用子查询，可以把子查询转化为关系查询 join操作
子查询性能差 子查询的结果集无法使用索引 或影响临时表操作，如果查询数据量大则严重影响效率 消耗过多的CPU以及IO资源避免使用JOIN关联太多的表
每join一个表会多占用一部分内存 会产生临时表操作，影响查询效率。 MySQL最毒允许关联61个表，建议不超过5个减少同数据库进行交互次数
数据库更适合处理批量操作 合并多个相同操作到一起，可以提高处理效率 使用in代替or 但in的值不要超过500个
in操作可以有效地利用索引禁止使用order by rand()进行随机排序
对MYSQL性能会有很大影响，会吧所有符合条件的数据装到内存中，然后在排序，会消耗大量CPU IO
以及内存资源，推荐在程序中获取一个随机值，然后从数据库中获取数据的方式禁止在Where从句中对列进行函数转换和计算
会导致索引无法使用在明显不会有重复值时使用UNION ALL 而非UNION
UNION会把所有的数据放到临时表中后再去重操作 UNION ALL 不会再对结果集进行去重操作拆分复杂的大SQL为多个小SQL
Mysql一个SQL只能使用一个CPU计算，如果计算逻辑过于复杂，会影响查询性能，拆分后可以通过并行执行来提高效率6.6 数据库行为操作规范
超过100万行的批量操作，要分批多次进行操作
对于大表使用pt-online-schema-change修改
对大表数据结构的修改一定要谨慎，会造成严重的锁表操作，尤其是产生环境，是不能忍受的 这样做的好处:避免大表修改产生的主从延迟
避免在对表字段进行修改时禁止为程序使用的账户赋予super权限
对于程序连接数据库账号，遵循权限最小原则
不准跨库 不准有DROP权限
三、小结
数据库设计规范在数据分析阶段，用数据依赖的概念分析和表示各项数据项之间的关系。在设计概念结构阶段，用规范化理论消除初步ER图冗余的联系。有ER图像数据模型转化阶段，用模式分解的概念和方法指导设计。
本项目的设计规范涉及了以下几个方面：
数据库命名规范;
数据库基本设计规范;
数据库索引设计规范;
数据库字段设计规范;
SQL开发规范；
数据库操作行为规范。
开发过程中应该严格遵循数据库设计规范进行设计。