SQL审核自动化

很多游戏项目都是通过每周更新大版本来维持用户的粘性和活跃度，而更新版本必然伴随着数据库的新建create、改表alter的SQL。

运维或者dba负责审核这类sql是否合理、高效，因为很多开发同事特别是经验少的新人是不考虑sql性能、是否合乎MySQL的最佳实践。

经常很多建表语句漏加索引或者加错索引（不满足最左匹配等情况），需要等到开服后数据库负载过高引起告警才发现问题。

MySQL的配置中有一个日志是记录没有使用索引的sql，记录进slow log日志中，不过实际使用过程中，的确存在着很多合理的不使用索引的情况，所以这个日志一般不打开。

为了避免人工审阅的重复劳动，所以运维可以通过写程序、脚本来自动审核sql，而审核的条件一般如下：

1、表结构是否合法 //不合法当然不能通过
2、表名、列名长度超过 16  //主要跟我们自己的授权有关系
3、必须有 unsigned  //业务最容易忘记添加，当然如果一定要负值，那么就走人工审核;
4、必须为 InnoDB  //当然了，我已经忘记还有MyISAM了，统计日志表除外
5、int bigint(10) 不能小于 10  //大家见过int（1）的情况么？
6、varchar 长度小于 3000  // 这也算是一个人为规定，没有任何意义
7、text 字段个数不能大于 3  //人为规定而已
8、主键必须为 int 类型       //不int，真的会死人
9、索引不能有重复    //见过key（id）,key(id,uid)的情况吗？
10、索引个数不能大于 5 个（包括主键） //人为定义而已
11、索引字段必须为 not null，并且有 default 值  //参照高性能那本书说的，其实不一定影响性能
12、SQL 是否使用到索引   //不能用到索引的SQL，真的很惨
13、SQL 中不能有 *  //由于* 经常导致流量、O巨大，所以，也强制了
14、自增字段必须为 int 或者 bigint  //见过自增用smallint的吗？然后一下就溢出了
15、请不要使用MySQL的保留字(Reserved Words)  //写脚本，大家讨厌<`>符号么？

开发提交sql后，会直接调用后端审核程序，程序根据以上规则，进行审核，就极大的降低了运维、DBA的工作量。

当sql审核通过后，是否马上执行？

根据以下情况判断：

1、表小于10w行，小于10M空间大小，那么直接执行SQL;
2、如果不满足1，并且满足percona online-schema-change条件，那么通过osc工具，进行在线修改;
3、如果1、2都不行，走人工上线流程;