MySQL开发手册
使用MySQL的原则
l 尽量不在数据库中做运算。计算后移至业务层。
l 尽量避免使用存储过程、触发器、函数等
l 弱化外键，由程序保证约束和逻辑的正确性。
l 将不常使用的字段以及大字段拆分到独立附属表中
l 适当时牺牲范式、适度冗余。冗余常用字段，减少关联查询。
l 获取大量数据时，建议分批次获取数据。
基础规范
l 所有表、字段、索引都需要添加注释
l 线上数据库和测试数据库尽可能保持一致
l 禁止明文存储机密数据(部分数据可逆运算)
l 不在数据库中存储图片、视频、文件等。
l 日志类型的表可以考虑按创建时间水平切割，定期归档历史数据
命名规范
l 库名、表名、字段名、索引名使用小写字母，以下划线分割，见名知意
l 库名、表名、字段名尽可能简洁，不超过32个字符。
l 存储实体数据的表，名称使用名词，单数
l 禁止使用MySQL保留字，如desc，order，select等
l 索引的命名规范
索引名使用小写字母、数字，采用下划线分割
普通索引名称以idx_为前缀，之后顺序跟随索引的字段名，字段名以下划线分割。
唯一索引以ux_为前缀
位图索引以bx_为前缀
函数索引以fx_为前缀
l 合理使用前缀。
表的前缀一般用系统或模块的名称缩写，
schema设计
库表
l 拆分大字段和访问频率低的字段，分离冷热数据。
l 每个表中考虑添加如下几个有用的字段。
记录的修改时间 ：update_time
记录的修改人：modifyBy
记录的修改版本：ver（version）
删除标记字段：flag
记录的创建时间：create_time
主键
l 使用独立于业务的AUTO_INCREMENT列做代理主键
l 分库分表场景下使用全局Id做代理主键。
l 主键名称叫id就很好，没有必要使用诸如product_type_id之类的，因为表本身已经表达了它是哪一个类型的id。
字段
l 使用更小的类型。字段类型在满足需求条件下越小越好，使用UNSIGNED存储非负数值，实际使用时候存储负数场景不多。性别、状态、是否、小范围枚举使用tinyint。
l 使用TINYINT来代替ENUM类型。千万别用CHAR/VARCHAR来存储枚举数据。
l 尽量避免字段为NULL，并设置DEFAULT缺省值。建议用0、空串、当前时间或特殊值代替NULL值。如果确定要用NULL，给出合理的理由。
索引
l 索引是双刃剑。加快定位、改善查询，去重，避免排序；减慢插入和更新，占用磁盘空间。
什么时候不要创建索引？
l 更新非常频繁的字段不适合创建索引。避免频繁更新的字段进入索引，增加IO负担。
l 不在低基数列上建立索引，例如“性别”
l 特别小的表，不需要建立索引。
l 不会出现在WHERE子句中字段不要创建索
创建索引的原则
合适的字段
l 出现在WHERE、DISTINCT、多表join、ORDER BY、GROUP BY子句中的字段。
l 字段内容不是频繁变化的。
l 索引列不能包含有NULL值的列，不要让含NULL的字段进入组合索引，建议给索引字段设置默认值。
SQL语句规范
l 避免select *。即使获取所有列，也不要用select *。只获取必要的数据（字段）
l 避免大表join。高并发DB不建议进行两个表以上的JOIN。
l 避免在数据库中进行数学运算
l 不用like'%xxx'模糊查询，尽量少用like ‘xxx%’
like “value%”可以使用索引，但是like “%value%”不会使用索引，走的是全表扫描。
这在数据量小的表，不存在性能问题，但是对于海量数据，全表扫描是非常可怕的事情。
所以，对于业务需求，考虑使用MySQL全文索引，或者使用solr或者es是个不错的方案。
l 避免在查询条件中对字段进行数学运算、函数调用、隐式类型转换等，导致使用不到索引。
l 拒绝3B，大SQL、大事务、大批量
l 当只要一行数据时使用LIMIT 1
l 通常情况下，子查询的性能比较差，建议改造成JOIN写法
l 减少表连接，减少复杂SQL，拆分成简单SQL
l 禁止单条SQL语句同时更新多个表
l 减少与数据库交互次数，尽量采用批量SQL语句
346
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
