一：数据库字段设计规范
1.优先选择合适存储最小的数据类型
（1）将字符串转化为数字类型存储
Inet_aton('255.255.255.255') = 4294967295
Inet_ntoa(4294967295) = '255.255.255.255'
(2) 对于非负数据采用无符号整型进行存储
singned int -2147483648~2147483647
UNSIGNED int(无符号整型) 0-4294967295
(3) varchar(n) 中的n代表的是字符数，而不是字节数
过多的长度会消耗更多的内存
（4）避免使用text, blob 数据类型
建议把blob或是text列分离到单独的扩展表中
text或 blob类型只能使用前缀索引
（5）比免使用enum 数据类型
修改enum 值需要使用Alter 语句
Enum 类型的order By 操作效率低，需要额外操作
禁止使用数值作为enum 的枚举值
（6）尽可能把所有列定义为not null
索引null 列需要额外的空间来保存，所有要占用更多的空间
进行比较和计算是要对null值做特别的处理
（7）字符串存储日期类型的数据（不正确的做法）
缺点1：无法用日期函数进行计算和比较
缺点2：用字符串存储日期要占用更多的空间
使用timestamp（年月日类型 4个字节） 或 datetime(年月日 8个字节)
timestamp 占用4个字节和INt 相同，但比int 可读性高
超出timestamp取值范围的使用datetime类型
（8）同财务相关的金额类数据，必须使用decimal 类型
decimal 类型为精准浮点数，在计算时不会丢失进度
占用空间有定义的宽度决定
可用于存储比bigint 更大的整数数据
二：索引设计规范
- 限制每张表索引数量，建议单张表索引不超过5个。
- 索引并不是越多越好，索引可以提高效率，同样也可以降低效率。
- 禁止给表中的每一列建立索引。
4．每个INnodb表必须有一个主键
（1）不使用更新频繁的列作为主键，不使用多列主键。
（2）不使用UUID,MD5，HASH字符串列作为主键（不能保证最后生成的 大于之前的，插到已有数据前边，造成大量IO 操作）
2．常见索引列建议。
1.select update, delete 语句的where 从句中的列。
2 包含在order by group by, distinct中的字段。
- 多表JOIN 关联列。
3. 如何选择索引列的顺序
1.区分度最高的列放在联合索引的最左侧
2.尽量把字段长度小的列放在联合索引的最左侧
3.使用最频繁的列放到联合索引的左侧
避免建立冗余的索引和充分索引
Primary key(id),index(id),unique index(id)
Index(a,b,c), index(a,b), index(a)
2.对于频繁的查询优先使用覆盖索引
避免Innodb表进行索引的二次查询。
可以把随意IO 变为顺序IO加快查询效率。
3.尽量避免使用外键（外键约束）
外键可用于保证数据的参照完整性，但建议在业务端实现。
外键 会影响父表和子表的写操作从而降低性能。
- 避免 数据类型的隐式转换
隐式转换会导致索引失效。
Select name，phone from customer where id = ‘111’(Id 为整形)
- 充分利用表上已经存在的索引，
- 避免使用 双% 的查询条件， a like ‘%123王%’
- 一个sql 只能利用到复合索引中的一类进行范围查询
- 使用 left join 或not exists 来优化 not in 操作
程序 连接不同的数据库 使用不同的账号，禁止 跨库查询
- 为 数据库迁移 和分库 分表留出余地
- 降低业务耦合度
- 避免权限过大而产生安全风险
禁止使用select * 必须使用 select 字段列 查询
消耗更多的cup 和IO 以及网络带宽资源
无法使用覆盖索引
可减少表结构变更带来的影响
禁止使用不包含字段列表的insert 语句
Insert into t values(‘a’,’b’);
Insert into t(c1, c2) values(‘a’,’b’)
可减少表结构变更带来的影响（新增减少字段）
避免使用子查询，可以吧子查询优化为join 操作
子查询的结果集无法使用索引
字查询会产生临时表（不会存在索引）操作，如果子查询数据量大则严重影响效率
消耗过多的CPU 及IO 资源
避免使用 join 关联太多的表
每join 一个表占用一部分内存
会产生临时表操作，影响查询效率
Mysql
最多允许65 ，建议最多5个
减少 同数据库的交互次数。
数据库更适合处理批量操作
合并多个相同的操作到一起，可以提高 处理效率
使用 in 代替 or (同一类)
In 值不要超过500 个
In 操作可以有效利用索引
禁止使用 order by rand() 进行随机排序
会把表中所有的复合条件的数据 装载 到内存中进行排序
会 消耗大量的cpu 和IO 及内存资源
推荐在程序中获取一个随机值，然后从数据库中获取数据的方式
Where 从句中禁止对列进行函数转换和计算
对列进行函数或计算会导致无法使用索引
Where date（createtime） = ‘20160901’
在明显不会 有重复值（能接受的情况）是使用 union all 而不是union
Union 会把所有数据放到临时表中后再进行操作
Union all 不会再对结果集进行去重操作
三：数据库操作规范
超100 万行的批量写操作，要分批多次进行操作
大批量操作可能会造成严重的主从延迟
Binlog 日志为row 格式时会产生大量的日志
避免产生大事务操作
2.对于大表使用 pt-online-schema-change修改表结构
避免大表修改产生的主从延迟
避免在对表字段进行修改是进行锁表
- 禁止为程序使用账户赋予super权限
当达到最大连接数限制时，还允许1个super权限的用户连接
Super 权限只能留给DBA处理问题的账户使用
- 对于程序连接数据账号。遵循权限最小原则
程序使用数据库账号只能在一个DB下使用，不准跨库。
程序 使用的账户原则上不准有drop 权限
四：MYsql 分区
注意：谨慎使用mysql 分区表
- 分区表在物理上表现为多个文件，在逻辑上表现为一个表。
- 谨慎选择分区键，跨分区查询效率可能更低
- 建议采用物理分区的方式管理大数据
分区前提： show plugins 查看mysql 服务器是否支持分区（active表示 支持分区）
2.mysql 分区表的特点
1.在逻辑上为一个表，在物理上存储在多个文件中。
3.常用分区方法：
- 按Hash 分区（整形的直接 通过hash 函数，非整型的数据转成整型的）
特别：根据MOD(分区键，分区数) 的值吧数据行存储到表的不同分区中
数据可以平均分布在各个分区中
Hash分区的键值必须是一个int类型的值，或是通过函数可以转为int 类型
- 按范围分区Range
特点：根据分区键值得范围把数据行存储到表的不同分区中
多个分区的范围要联系，但是不能重复
默认情况下使用values less than 属性，即每个分区不包括制定的那个值
- List 分区
特别：按分区键键取值的类别进行分区
同范围分区一样，个分区的列表值不能重复
每一行数据必须能找到对应的分区列表，否则数据插入失败
