这篇文章是基于几年工作经验以及网络上一些资料写就而成，主要是总结一下关于数据库和表设计方面的一些规范和原则，不涉及理论纯实践经验，仅供参考。一般而言，规范总是会限制一些功能，以牺牲功能的灵活性和丰富性来换取数据以及基于数据库的系统的安全和可维护性。因此，关于建立规范，需要以理解其作用和用意为前提，而不要受其拘泥而被捆绑了手脚。闲话少叙，正文如下：
基础规范
- 谨慎选择存储引擎
一般有两种选择InnoDB和MyISAM，但选择哪一个需要慎重
- InnoDB：支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高
- MyISAM：表强调的是性能，其执行数度比 InnoDB 类型更快，支持全文索引，支持GIS数据：Point，Line，Polygon，Surface等；MyISAM内置了一个计数器，count(*)时它直接从计数器中读，而InnoDB必须扫描全表。
- 限定字符编码utf-8 或utf8-mb4
- utf-8：万国码，无需转码，无乱码风险
- utf8-mb4：utf8mb4是utf8的超集，emoji表情以及部分不常见汉字在utf8下会表现为乱码
- 表和字段添加注释
- 尽可能不使用存储过程、视图、触发器等
一般的企业应用或互联网应用中，不应该在数据库中写入领域业务逻辑，这样一来不便于代码维护，而来也不利于系统的横向扩展 - 主键策略
一般情况下，强烈推荐表一定要包含主键，主键要选择较短的数据类型， Innodb引擎普通索引都会保存主键的值，较短的数据类型可以有效的减少索引的磁盘空间，提高索引的缓存效率
- 自增 数据行写入可以提高插入性能，可以避免page分裂，减少表碎片提升空间和内存的使用
- 单点
- 序列
- 随机不重复字符串
- 一般不使用外键
外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sql 的性能，甚至会造成死锁。高并发情况下容易造成数据库性能，大数据高并发业务场景数据库使用以性能优先。如果有外键完整性约束，需要应用程序控制
命名规范
- 库名称
- 生产环境：xxx
- 备份库：xxx_bak
- 开发环境：xxx_dev
- 测试环境：xxx_test
- 表名称和字段名
- 小写，下划线分割
- 不超过32个字符
- 必须见名知意
- 禁止拼音英文混用
- 索引
- 非唯一索引名idx_xxx
- 唯一索引名uniq_xxx
业务规范
- 手机号用varchar(20)
手机号可能涉及到区号或者国家代号，可能出现+-86等字符，因此不可以varchar(11) - 金额用decimal(20, 4)
- 时间统一用datetime，如有必要再用timestamp
