各位新朋友～记得先点蓝字关注我哦～
大家好，今天跟大家介绍关于MSSQL数据库开发管理，先跟大家解释一下开发规范实际存在的价值。
开发规范的实际意义
一套系统是否能够安全、稳定、好用，开发和测试非常重要，而数据库是整个系统使用的核心，所以数据库的设计变得尤其重要。这里通过定义系统开发过程中数据库开发应该遵从的规范和标准,严格的开发标准和规范可以使整个数据库系统运行稳定，并且对长期的数据库优化维护起到很重要的作用，在系统立项阶段就需要DBA参与进来协助完成数据库选型和架构设计，同时明确要求开发、测试、运维人员按规定进行开发、测试和验收工作。
数据库开发规范
开发规范内容分别针对表、索引、语句、操作几个方向进行规范
“
创建库表规范
【 强 制 】
1、事务隔离级别采用Read Commited。
2、所有表、字段均有中文注释。
3、每张表都要建立主键。
4、表达是与否概念的字段，必须使用is_xxx的方式命名，数据类型是tinyint（ 1 表示是，0 表示否）。
5、表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
正例：getter_admin， task_config， level3_name
反例：GetterAdmin， taskConfig， level_3_name
6、表名不使用复数名词。
7、禁用保留字，如 desc、range、match、delayed 等，请参考官方保留字。
8、主键索引名为pk_字段名；唯一索引名为uk_字段名；普通索引名则为idx_字段名。
9、如果存储的字符串长度几乎相等，使用char 定长字符串类型。
10、varchar 是可变长字符串，不预先分配存储空间，长度不要超过5000，如果存储长度大于此值，定义字段类型为text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
【 推 荐 】
1、单库控制在2T（SQL Server）或100张表。
2、单表控制在3000W条记录或10GB。
3、单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。
4、单表字段控制在30以内。
5、表建议包含三字段：id,gmt_create,gmt_modified
6、表的命名最好是加上“业务名称_表的作用”。
正例：tiger_task tiger_reader mpp_config
7、库名与应用名称尽量一致。
8、如果修改字段含义或对字段表示的状态追加时， 需要及时更新字段注释。
9、字段允许适当冗余，以提高性能，但是必须考虑数据同步的情况。冗余字段应遵循：
1） 不是频繁修改的字段。
2） 不是 varchar 超长字段，更不能是 text 字段。
正例：商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存储类目名称，避免关联查询。
10、数据库名称和表名使用小写字母。方便日后数据库迁移。保证生产环境和测试环境、开发环境的数据库名称一致。
【 参 考 】
合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。
“
创建索引规范
【 强 制 】
1、业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。
2、超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询时，保证被关联的字段需要有索引。
3、频繁执行的重要SQL必须创建索引。
UPDATE、DELETE语句的WHERE条件列，ORDER BY、GROUP BY、DISTINCT的字段，多表JOIN的字段 建议设置索引。
4、在varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。
5、页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
【 推 荐 】
1、单张表中索引数量不超过5个。
2、单个复合索引中的字段数不超过5个。
3、不使用更新频繁的列作为索引。
4、如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现sort 的情况，影响查询性能。
正例：where a=? and b=? order by c; 索引：a_b_c
反例：索引中有范围查找，那么索引有序性无法利用，如：WHERE a>10 ORDER BY b; 索引a_b 无法排序。
5、利用非聚集索引来进行查询操作， 避免回表。
6、建非聚集包含列索引的时候，区分度最高的在最左边。
正例：如果where a=? and b=? ，a 列的几乎接近于唯一值，那么只需要单建idx_a索引即可。
【 参 考 】
创建索引时避免有如下极端误解：
1）误认为一个查询就需要建一个索引。
2）误认为索引会消耗空间、严重拖慢更新和新增速度。
3）误认为唯一索引一律需要在应用层通过“先查后插”方式解决。
“
高性能SQL脚本编写指导
【 强 制 】
1、要求所有的SQL提交测试前，查看执行计划 ，避免全表扫描，避免生成临时表。
2、禁止不同类型字段做比较，避免隐式转换。
3、避免使用大表的JOIN，同时避免3张表以上的join，小表驱动大表原则。
4、禁止单条SQL语句同时更新多个表。
5、禁用select * 。
6、Insert 语句必须显示指定字段名。
7、禁止使用嵌套子查询（3级以上），使用join代替。
8、避免%%模糊匹配、where后字段使用函数。
9、尽量使用union all而非union来去重和降低排序。
10、避免大事务操作，及时commit。
11、用in替代or。
12、禁止直接进行truncate操作、不带where条件的update/delete操作。
【 推 荐 】
1、避免在数据库中进行数学运算，尽量在程序端做处理，传给数据库。
2、尽量将大SQL拆分成小SQL。
3、In后面的内容尽量控制在200以内。
4、减少数据库交互次数，例如多个values语法合并。
5、查询条件中，规避将计算或聚合函数作用到索引字段上。
6、查询应尽量使用缓存，尽量不要使用内部函数，内部函数不会调用缓存。可以使用变量的方式替代。
7、join时需要连接字段创建索引，建议连接字段的类型和字符集一样。
“
操作规范
所有影响数据库数据的操作都需要做备份。
大查询可放查询库、从库操作。
禁止直接进行truncate操作、不带where条件的update/delete操作。
涉及业务上的修改/删除数据，在得到业务方、CTO的邮件批准后方可执行，执行前提前做好备份，必要时可逆。
所有上线需求必须走工单系统，口头通知视为无效。
在对大表做表结构变更时，如修改字段属性会造成锁表，并会造成从库延迟，从而影响线上业务，必须在凌晨0:00后业务低峰期执行。
促销活动或高并发情况等应提前与DBA当面沟通，进行流量评估，比如提前一周增加机器内存或扩展架构，防止DB出现性能瓶颈。
批量清洗数据，需要开发和DBA共同进行审查，应避开业务高峰期时段执行，并在执行过程中观察服务状态。
“
注意事宜（严禁）
禁止在数据库中存放文件、语音、视频、图片。
禁止直接在线上生产数据库进行开发、测试操作。
禁止未经过测试的代码直接上线生产环境。
禁止数据库中存储明文密码。
禁止程序使用弱密码、管理账户、大权限用户连接数据库。
禁止在数据库中存储大量的备份数据、业务代码。
禁止未告知DBA的情况下进行任何线上数据库的变更操作，如数据导出导入，权限调整，DDL/DML等，如有重大活动、任务需及时告知DBA。
禁止在线上做数据库压力测试。
“
总结
针对数据库的开发，一定要按照数据库开发规范，设计系统架构图（包含数据库架构图）、数据字典，并且要经过多轮的基准压力测试、业务逻辑压力测试进行反复设计优化，达到SQL高效执行、业务响应速度快、系统运行稳定等要求，此规范实用大多数mssql数据开发（特殊业务需求除外）。
