1 命名规范mysql
普通索引：idx_字段名sql
惟一索引：ux_字段名数据库
全部数据库对象名称必须使用小写字母并用下划线分割缓存
禁止使用mysql保留关键字 ---若是表名中包含关键字查询时，须要将其有单引号括起来安全
见名识意，而且最后不要超过32个字符服务器
临时库表以tmp_为前缀并以日期为后缀，备份表以bak_为前缀并以日期为后缀mysql优化
全部存储相同数据的列名和列类型必须一致--通常做为关联列，若是查询时关联列类型不一致会自动进行数据类型隐式转换，会形成列上的索引失效，致使查询效率下降并发
2 数据库基本设计规范数据库设计
没有特殊要求下，全部表必须使用innodb存储引擎--支付事务、行级锁、更好的恢复性、高并发下性能更好函数
数据库和表的字符集统一使用utf8---统一字符集能够避免因为字符集转换产生的乱码，不一样的字符集进行比较前须要进行转换会形成索引失效
全部表和字段都须要添加注释--使用comment从句添加表和列的备注进行数据字典的维护
尽可能控制单表数据量的大小，建议控制在500万之内，过大会形成修改表结构、备份、恢复都会有很大的问题。能够用历史数据归档应用于日志数据，分库分表应用于业务数据等手段
谨慎使用mysql分区表--分区表在物理上表现为多个文件，在逻辑上表现为一个表，跨分区查询效率可能更低，建议采用物理分表的方式管理大数据
尽可能作到冷热数据分离，减少表的宽度--mysql限制每一个表最多存储4096列，而且每一行数据在大小不能超过65535字节 减小磁盘IO--保证热数据的内存缓存命中率，避免读入无用的冷数，常常一块儿使用的列放到一个表中避免更多的关联操做。
禁止在表中创建预留字段--没法确认存储的数据类型，对预留字段类型的修改会对表进行锁定
禁止在数据库中存储图片，文件等大的二进制数据---IO操做耗时，一般存储于文件服务器，数据库只存储文件地址信息
禁止在线上作数据库压力测试
禁止从开发环境、测试环境直接链接生成环境数据库
2 数据库字段设计规范
优先选择符合存储须要的最小的数据类型-- 字段大，创建索引空间大，IO次数多，索引性能差
1 将字符串转换成数字类型存储如：IP地址-插入数据前先用inet_aton把ip地址转为整型，节省空间，显示数据时使用inet_ntoa把整型ip地址转为地址显示便可
2 对于非负型的数据 如 自增id IP 要优先使用无符号整型来存储，无符号相对于有符号能够多出一倍的存储空间
SIGNED INT -2147483648~2147483647
UNSIGNED INT 0~4294967295
VARCHAR(N)中的N表明的是字符数，而不是字节数
使用UTF8存储255个汉字 Varchar(255)=765个字节。过大的长度会消耗更多的内存
避免使用text、blob数据类型，最多见的text类型能够存储64K的数据---能够分离到单独的扩展表中
mysql内存临时表不支持text/blob大数据类型，若是查询中包含这样的数据，在排序等操做时，就不能使用内存临时表，必须使用磁盘临时表进行。mysql还要进行二次查询，会使sql性能变得不好，不须要text列的数据时不要对该列进行查询
text/blob类型只能使用前缀索引，而且text列上是不能有默认值的
避免使用enum类型--修改enum值须要使用alter语句-enum类型的order by 操做效率低，须要额外操做，禁止使用数值做为enum的枚举值
尽量把全部列定义为not null--索引null列须要额外的空间来保存，因此要占用更多的空间；进行比较和计算时要对null值作特别的处理
使用timestamp 4个字节 或 datetime类型8个字节 存储时间
TIMESTAMP 存储的时间范围 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07。
TIMESTAMP 占用4字节和INT相同，但比INT可读性高
超出TIMESTAMP取值范围的使用DATETIME类型存储
同财务相关的金额数据必须使用decimal类型
非精准浮点：float,double
精准浮点：decimal
Decimal类型为精准浮点数，在计算时不会丢失精度。占用空间由定义的宽度决定，每4个字节能够存储9位数字，而且小数点要占用一个字节。可用于存储比bigint更大的整型数据。
4 索引设计规范
限制每张表上的索引数量，不超过5个，索引能够增长查询效率，一样也会下降插入和更新的效率，有些状况下会下降查询效率
由于mysql优化器在选择如何优化查询时，会根据统一信息，对每个能够用到的索引来进行评估，以生成出一个最好的执行计划，若是同时有不少个索引均可以用于查询，就会增长mysql优化器生成执行计划的时间，一样会下降查询性能
禁止给表中的每一列都创建单独的索引---使用联合索引查询
每一个索引组织表innodb必须有个主键--数据的存储的逻辑顺序和索引的顺序是相同的，每一个表均可以有多个索引，可是表的存储顺序只能有一种innodb是按照主键索引的顺序来组织表的。
不要使用更新频繁的列做为主键，不要使用uuid md5 hash 字符串列做为主键--没法保证数据的顺序增长
主键建议使用自增ID值
5 常见索引列建议
出如今select update delete 语句的where 从句中的列
包含在order by group by distinct中的字段
多表join的关联列
创建联合索引效果更好
6 索引列的顺序 -区分别最高的放在联合索引的最左侧 ，区分度=列中不一样值的数量/列的总行数
尽可能把字段长度小的列放在联合索引的左侧
7 避免创建冗余索引和重复索引
重复索引示例：primary key(id)、index(id)、unique index(id)
冗余索引示例：index(a,b,c)、index(a,b)、index(a)
8 优先考虑覆盖索引--就是包含了全部查询字段（where select order bjy group by ）的索引
避免lnnodb表进行索引的二次查询
9 索引规范
尽可能避免使用外键约束，但要在表与表之间的关联键上创建索引，外键建议在业务端实现参照完整性
外键会影响父表和子表的写操做从而下降性能
10 数据库开发规范
建议使用预编译语句进行数据库操做-减小编译所须要的时间，还能够解决动态sql所带来的sql注入问题 只传参数，比传递sql语句更高效，相同语句能够一次解析，屡次使用，提升处理效率
避免数据类型的隐式转换 id=''
充分利用表上已经存在的索引-避免使用双%号的查询条件
一个sql只能利用到复合索引中的一列进行范围查询-如：有 a,b,c列的联合索引，在查询条件中有a列的范围查询，则在b,c列上的索引将不会被用到，在定义联合索引时，若是a列要用到范围查找的话，就要把a列放到联合索引的右侧
使用left join或 not exists来优化not in操做 由于not in 也一般会使用索引失效。
数据库设计进，应要对之后扩展进行考虑
程序链接不一样的数据库使用不一样的帐号，跨库查询
为数据库迁移和分库分表留出余地
下降业务耦合度
避免权限过大而产生的安全风险
禁止使用select * 使用select 字段 查询
禁止使用不含字段一表的insert语句
避免使用子查询，能够把子查询优化为join操做 通用子查询在in子句中，且子查询中为简单sql进才能够转化为关联查询进行优化
子查询结果信没法使用索引，一般子查询的结果集会被存储到临时表中，不管是内存临时表仍是磁盘临时表都不会存在索引。
避免使用JOIN关联太多的表－关联缓存大小能够由join_buffer_size参数进行设置，最多容许关联61个表，建议不超过5个。
减小同数据库的交互次数-批量操做合交多个相同的操做到一块儿，能够提升处理效率
对应同一列进行or判断时，使用in代替or,in 的值不要超过500个，能够更有效的利用索引，or不多能利用到索引
禁使用order by rand()进行随机排序
where从句中禁止对列进行函数转换和计算：没法使用索引
在明显不会有重复值时使用union all 而不是union
union 会把两个结果集的全部数据放到临时表中后再进行去重操做，union all 不会再对结果集进行去重操做
拆分复杂的大sql为多个小sql:大sql逻辑上比较复杂，须要占用大量cpu进行计算；mysql一个sql只能使用一个cpu进行计算，拆分的可能经过并行执行来提升处理效率
11 数据库操做行为规范
超100万行的批量写操做，要分批屡次进行操做；大批量写操做产生大量日志。特别是对于row格式。
大批量修改数据，必定是在一个事务中进行的，这就会形成表中大批量数据进行锁定，从而致使大量的阻塞
对于大表使用pt-online-schema-change修改表结构：避免大表修改产生的主从延迟，避免在对表字段进行修改时进行锁表，pt-online-schema-change首先创建一个与原表结构相同的新表，而且在新表上进行表结构的修改，而后再把原表中的数据复制到新表中，并在原表中增长一些触发器。把原表中新增的数据也复制到新表中，在行全部数据复制完成以后，把新表命名成原表，并把原表删除掉。
禁止为程序使用的帐号赋予super权限-只能留给DBA处理问题帐号使用。
对于程序链接数据库帐号，遵循权限最小原则