一、使用InnoDB存储引擎web
支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高sql
二、推荐使用utf8mb4字符集数据库
无需转码，无乱码风险, 支持emoji表情以及部分不常见汉字缓存
三、表、字段必须加注释并发
方便他人理解字段意思。svg
四、不在数据库作计算函数
禁止使用存储过程、视图、触发器、Event。高并发
在并发量大的状况下，这些功能极可能将数据库拖跨，业务逻辑放到服务层具有更好的扩展性，可以轻易实现“增机器就加性能”性能
五、禁止存储文件大数据
文件存储在文件系统，数据库里存URI
六、控制单表数据量
单表记录控制在千万级
一、库名、表名、字段名：小写，下划线风格
非惟一索引名idx_xxx，惟一索引名uniq_xxx
二、表必须有主键，例如自增主键
主键递增，数据行写入能够提升插入性能
主键要选择较短的数据类型，Innodb引擎普通索引都会保存主键的值，较短的数据类型能够有效的减小索引的磁盘空间，提升索引的缓存效率
保证明体的完整性，惟一性
三、不要使用外键，若是有外键约束，用应用程序控制
外键会致使表与表之间耦合，update与delete操做都会涉及相关联的表，十分影响sql 的性能，甚至会形成死锁。高并发状况下容易形成数据库性能降低，大数据高并发业务场景数据库使用以性能优先
一、把字段定义为NOT NULL而且提供默认值
null的列使索引/索引统计/值比较都更加复杂，对MySQL来讲更难优化
null 这种类型MySQL内部须要进行特殊处理，增长数据库处理记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的处理性能会下降不少
null值须要更多的存储空间，不管是表仍是索引中每行中的null的列都须要额外的空间来标识
对null 的处理时候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in这些操做符号。如：where name!=’zhangsan’，若是存在name为null值的记录，查询结果就不会包含name为null值的记录
二、不要使用TEXT、BLOB类型
会浪费更多的磁盘和内存空间，非必要的大量的大字段查询会淘汰掉热数据，致使内存命中率急剧下降，影响数据库性能,若是必需要使用则独立出来一张表，用主键来对应，避免影响其它字段索引效率
三、不要使用小数存储货币
建议使用整数，小数容易致使钱对不上
四、必须使用varchar存储手机号
手机号会去作数学运算么？
五、为提升效率能够牺牲范式设计，冗余数据
不是频繁修改的字段
不是 varchar 超长字段，更不能是 text 字段
一、禁止在更新十分频繁、区分度不高的属性上创建索引
更新会变动B+树，更新频繁的字段创建索引会大大下降数据库性能
“性别”这种区分度不大的属性，创建索引是没有什么意义的
二、创建组合索引，必须把区分度高的字段放在最左边
若是 where a=? and b=? ， a 列的几乎接近于惟一值，那么只须要单建 idx_a 索引便可
三、 页面搜索严禁左模糊或者全模糊
索引文件具备 B-Tree 的最左前缀匹配特性，若是左边的值未肯定，那么没法使用此索引, 若是须要请走搜索引擎来解决
一、禁止使用SELECT *，只获取必要的字段，须要显示说明列属性
消耗cpu，io，内存，带宽
不能有效的利用覆盖索引
使用SELECT *容易在增长或者删除字段后出现程序BUG, 不具备扩展性
二、使用INSERT INTO t_xxx VALUES(xxx)，必须显示指定插入的列属性
容易在增长或者删除字段后出现程序BUG
三、务必请使用“同类型”进行比较，不然可能全表扫面
SELECT name FROM t_user WHERE phone=1333333333 会致使全表扫描.
四、禁止在WHERE条件的上使用函数或者计算
解读：SELECT naem FROM t_user WHERE date(create_datatime)=’2017-12-15’ 会致使全表扫描
推荐的写法是：SELECT name FROM t_user WHERE create_datatime>= ‘2017-02-15 ’ and create_datatime < ‘2017-02-16 ‘
五、禁止负向查询，以及%开头的模糊查询
负向查询条件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，会致使全表扫描
%开头的模糊查询，会致使全表扫描
六、不要大表使用JOIN查询，禁止大表使用子查询
会产生临时表，消耗较多内存与CPU，极大影响数据库性能
七、OR改写为IN()或者UNION
缘由很简单or不会走索引
八、简单的事务
事务就像程序中的锁同样粒度尽量要小
九、不要一次更新大量数据
数据更新会对行或者表加锁，应该分为屡次更新