1 命名规范
所有数据库对象名称必须使用小写字母并用下划线分割
禁止使用mysql保留关键字 ---如果表名中包含关键字查询时，需要将其有单引号括起来
见名识意，并且最后不要超过32个字符
临时库表以tmp_为前缀并以日期为后缀，备份表以bak_为前缀并以日期为后缀
所有存储相同数据的列名和列类型必须一致--一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低
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首先建立一个与原表结构相同的新表，并且在新表上进行表结构的修改，然后再把原表中的数据复制到新表中，并在原表中增加一些触发器。把原表中新增的数据也复制到新表中，在行所有数据复制完成之后，把新表命名成原表，并把原表删除掉。