mysql开发规范 一.基础规范(1) 使用INNODB存储引擎(2) 表字符集使用UTF8(3) 所有表都需要添加注释(4) 单表数据量建议控制在5000W以内(5) 不在数据库中存储图、文件等大数据(6) 禁止在线上做数据库压力测试二.命名规范(1) 库名表名字段名必须有固定的命名长度，12个字符以内(2) 库名、表名、字段名禁止超过32个字符。须见名之意(3) 库名、表名、字段名禁止使用MySQL保留字(4) 临时库、表名必须以tmp为前缀，并以日期为后缀(5) 备份库、表必须以bak为前缀，并以日期为后缀create_time：添加时间update_time:更新时间status:状态（0-否/失败/条件不成立，1-是/成功/条件成立）author:作者/操作人/管理员ip:ip信息fdate:每日信息20190428month:月份201904year:年份2019week:周201902周例如活动类的表命名：active_xxxx, active_bbbb这种方式同一张表，不同的类型区分：zz_aaaa, zz_bbb, zz_cccc, zz_dddd,    bb_ccccc, bb_dddddd三.库、表、字段开发设计规范(1) 禁止使用分区表(2) 拆分大字段和访问频率低的字段，分离冷热数据(3) 用HASH进散表，表名后缀使进制数，下标从0开始(4) 按日期时间分表需符合YYYYMM[HH]格式(5) 采用合适的分库分表策略。例如千库十表、十库百表等(6) 尽可能不使用TEXT、BLOB类型(7) 用DECIMAL代替FLOAT和DOUBLE存储精确浮点数(8) 越简单越好：将字符转化为数字、使用TINYINT来代替ENUM类型(9) 所有字段均定义为NOT NULL(10) 使用UNSIGNED存储非负整数(11) INT类型固定占用4字节存储(12) 使用timestamp存储时间(13) 使用INT UNSIGNED存储IPV4(14) 使用VARBINARY存储大小写敏感的变长字符串(15) 禁止在数据库中存储明文密码，把密码加密后存储(16) 用好数值类型字段Tinyint (1Byte)smallint (2Byte)mediumint (3Byte)int (4Byte)bigint (8Byte)(17) 存储ip最好用int存储而非char(15)(18) 不允许使用ENUM(19) 避免使用NULL字段NULL字段很难查询优化，NULL字段的索引需要额外空间，NULL字段的复合索引无效(20) 少用text/blob，varchar的性能会比text高很多，实在避免不了blob，请拆表(21) 数据库中不允许存储大文件，或者照片，可以将大对象放到磁盘上，数据库中存储它的路径四.索引规范1、索引的数量要控制：(1) 单张表中索引数量不超过16个(2) 单个索引中的字段数不超过5个(3) 对字符串使用前缀索引，前缀索引长度不超过8个字符(4) 建议优先考虑前缀索引，必要时可添加伪列并建立索引2、主键准则(1) 表必须有主键(2) 不使用更新频繁的列作为主键(3) 尽量不选择字符串列作为主键(4) 不使用UUID MD5 HASH这些作为主键(数值太离散了)(5) 默认使非空的唯一键作为主键(6) 建议选择自增或发号器3、重要的SQL必须被索引，比如：(1) UPDATE、DELETE语句的WHERE条件列(2) ORDER BY、GROUP BY、DISTINCT的字段4、多表JOIN的字段注意以下：(1) 区分度最大的字段放在前面(2) SQL优先考虑覆盖索引(3) 避免冗余和重复索引(4) 索引要综合评估数据密度和分布以及考虑查询和更新比例5、索引禁忌(1) 不在低基数列上建立索引，例如“性别”(2) 不在索引列进行数学运算和函数运算6、尽量不使用外键(1) 外键用来保护参照完整性，可在业务端实现(2) 对父表和子表的操作会相互影响，降低可用性7、索引命名：非唯一索引必须以 idx_字段1_字段2命名，唯一所以必须以uniq_字段1_字段2命名，索引名称必须全部小写8、新建的唯一索引必须不能和主键重复9、索引字段的默认值不能为NULL，要改为其他的default或者空。NULL非常影响索引的查询效率10、反复查看与表相关的SQL，符合最左前缀的特点建立索引。多条字段重复的语句，要修改语句条件字段的顺序，为其建立一条联合索引，减少索引数量11、能使用唯一索引就要使用唯一索引，提高查询效率五.SQL规范(1) sql语句尽可能简单大的sql想办法拆成小的sql语句(2) 事务要简单，整个事务的时间长度不要太长(3) 避免使用触发器、函数、存储过程(4) 降低业务耦合度，为sacle out、sharding留有余地(5) 避免在数据库中进数学运算(MySQL不擅长数学运算和逻辑判断)(6) 不要用select *，查询哪几个字段就select 这几个字段(7) sql中使用到OR的改写为用 IN() (or的效率没有in的效率高)(8) in里面数字的个数建议控制在1000以内(9) limit分页注意效率。Limit越大，效率越低。可以改写limit，比如例子改写：select id from tlimit 10000, 10; => select id from t where id > 10000 limit10;(10) 使用union all替代union(11） 避免使大表的JOIN(12) 使用group by 分组、自动排序(13) 对数据的更新要打散后批量更新，不要一次更新太多数据(14) 减少与数据库的交互次数(17) SQL语句不可以出现隐式转换，比如 select id from 表 where id='1'(18) IN条件里面的数据数量要少， 500个以内，使用exist代替in，exist在一些场景查询会比in快(19) 能不用NOT IN就不用NOT IN(20) 在SQL语句中，禁止使用前缀是%的like(21) 不使用负向查询，如not in/like(22) 关于分页查询：程序里建议合理使用分页来提高效率limit，offset较大要配合子查询使用(23) 禁止在数据库中跑大查询(24) 使预编译语句，只传参数，比传递SQL语句更高效；一次解析，多次使用；降低SQL注入概率(25) 禁止使order by rand()(26) 禁单条SQL语句同时更新多个表

浅谈Mysql索引的最左匹配原则 最左匹配原则最左匹配原则就是指在联合索引中，如果你的 SQL 语句中用到了联合索引中的最左边的索引，那么这条 SQL 语句就可以利用这个联合索引去进行匹配.例如某user表现有索引(name_age_email)CREATE INDEX name_age_email ON user (`name`,`age`,`email`)现在测试如下sql语句：explain select * from user where name='tom' and age=21 and email ='test@email.com'; 结果：这样可以利用到定义的联合索引（name_age_email）,用上name，age，emailexplain select * from user where name='tom' and age=21; 结果：这样可以利用到定义的联合索引（name_age_email）,用上name，ageexplain select * from user where age=21 and name='tom'; 结果：这样可以利用到定义的联合索引（name_age_email）,用上name，age(mysql有查询优化器)explain select * from user where name='tom'; 结果：这样可以利用到定义的联合索引（name_age_email）,用上nameexplain select * from user where age=21 and email ='test@email.com'; 结果： 这样不可以利用到定义的联合索引（name_age_email） explain select * from user where name='tom' and email ='test@email.com'; 结果：这样可以利用到定义的联合索引（name_age_email）,用上name索引，但是age和email索引用不到也就是说通过最左匹配原则你可以定义一个联合索引，但是使得多中查询条件都可以用到该索引,避免了重复建索引造成的资源浪费，索引不是建的越多越好！下面几种情况时索引也会停止匹配：当遇到范围查询(>、<、between、like)就会停止匹配。也就是：select * from user where name='tom' and age>20 and email ='test@email.com'; #这样name,age可以用到（name_age_email），email索引用不到 这条语句只有name,age 会用到索引，email都不能用到索引。这个原因可以从联合索引的结构来解释。2.但是如果是建立(name,email,age)联合索引，则name,age,email都可以使用索引，因为优化器会自动改写为最优查询语句CREATE INDEX name_age_email ON user (`name`,`email`,`age`)explain select * from user where name='tom' and age>20 and email ='test@email.com'; 结果：如果是建立(name,email,age)联合索引，则a,b,c都可以使用索引优化器改写为select * from user where name='tom' and email ='test@email.com' and age>20;{dotted startColor="#ff6c6c" endColor="#1989fa"/}通过以上sql分析：索引index1:(a,b,c)，只会走a、a,b、a,b,c 三种类型的查询，其实这里说的有一点问题，a,c也走，但是只走a字段索引，不会走c字段，c肯定是无序了，所以c就没法走索引，数据库会觉得还不如全表扫描c字段来的快。以index （a,b,c）为例建立这样的索引相当于建立了索引a、ab、abc三个索引。一个索引顶三个索引当然是好事，毕竟每多一个索引，都会增加写操作的开销和磁盘空间的开销。