高性能开发数据库执行规范标准

a、业务SQL性能优化规范

1、多表关联查询表个数原则上不超过三个，如果超过三个业务表的复杂的sql，需要拆分成多个SQL进行执行。

2、提供的业务接口，count计数的接口需要功能唯一，不要和聚合其他业务查询，目前count优化没有什么好的方案。

3、list查询SQL需要有起止时间和结束时间，默认起止时间和结束时间区间为2~6个月。

4、对数据库查询时间精确到秒级别的业务SQL，为了防止应用服务器和数据服务器时间误差造成的干扰，禁止从应用服务器中获取时间在数据库服务器上进行过滤计算。建议时间获取都从数据库服务器

5、外键关联字段在业务表创建时候强制创建索引。

6、联合索引创建的字段不能超过三个，防止大量无效的索引占用空间，造成索引效率低下。

7、严格禁止循环对数据库进行查询，建议批量查询操作提升性能。

8、返回结果集存在按时间先后顺序返回数据的，优先通过主键ID进行排序（正常情况下，ID是作为主键默认是有索引的，）

 ，尽量不要用时间进行排序（时间排序会带来file sort性能损耗，如果为此排序单独给时间字段创建索引，会进行索引空间的开销）。

b、业务表创建规范

1、创建新的表结构，必须有创建日期和修改日期（CREATE_TIME` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',MODIFY_TIME` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间'），创建日期和修改日期赋值均通过数据库自动触发，禁止任何程序代码进行赋值。

2、业务表宽度限制在30个字段以内。

3、表命名规则不超过四级，第一级库名，第二级业务分类，第三级业务名，第四级需求名；例如：BOSS_SUCCESS_GROUP_LEVEL。

4、业务分类或状态标识字段值域建议为10的整数倍，以便后续进行扩展。

5、业务主表中如果出现单个字段的数据存储值超过300，需要扩充子业务表进行存储。

6、业务数据不允许进行物理删除，需对数据处理进行逻辑删除。

c、业务开发过程中事物处理参考

1、处理异步请求的业务数据，需要考虑主从延迟或者数据库物隔离级别不一致的情况下，如何保证获取数据一致性。

2、对外提供接口或者访问外部接口，需要注意多个不同的事物是否存在对统一业务表进行写操作，防止双方互相锁造成的事物无法释放。

3、对业务数据进行UPDATE操作，WHERE条件必须提供主键ID进行限制。

4、批量插入的业务数据限制在100条之内，防止事物过大对数据库造成影响。

d、数据查询需要注意事项

1、当前业务范围之外的业务数据查询，禁止直接查询相应的数据，需要对方提供相应的服务。

2、提供给外部的访问接口，对数据条数进行限制，单次请求最大的条数限制在100条之内。

3、内部业务数据查询操作，每次请求的数据不能超过200条。