数据库sql编写规范

一 DML语句

1. SELECT语句必须指定具体字段名称，禁止写成*。因为select *会将不该读的数据也从MySQL里读出来，造成磁盘和网卡压力，尤其在有text或者blob字段的时候。
2. SELECT语句不要使用UNION，推荐使用UNION ALL，并且UNION子句个数限制在5个以内。因为union all不需要去重，节省数据库资源，提高性能。
3. in值列表限制在500以内。例如select… where userid in(….500个以内…)，这么做是为了减少底层扫描，减轻数据库压力从而加速查询。
4. 事务里批量更新数据需要控制数量，进行必要的sleep，做到少量多次。
5. 除静态表或小表（100行以内），DML语句必须有where条件，且使用索引查找。
6. 生产环境禁止使用hint，如sql_no_cache，force index，ignore key，straight join等。因为hint是用来强制SQL按照某个执行计划来执行，但随着数据量变化我们无法保证自己当初的预判是正确的，因此我们要相信MySQL优化器！
   • 如果遇到执行计划和设想的不符合，请第一时间联系DBA
7. where条件里等号左右字段类型必须一致，否则无法利用索引。
8. SELECT|UPDATE|DELETE|REPLACE要有WHERE子句，且WHERE子句的条件必需使用索引查找。
9. 生产数据库中强烈不推荐大表上发生全表扫描，但对于100行以下的静态表可以全表扫描。查询数据量不要超过表行数的25%，否则不会利用索引。
10. WHERE 子句中禁止只使用全模糊的LIKE条件进行查找，必须有其他等值或范围查询条件，否则无法利用索引。
11. 索引列不要使用函数或表达式，否则无法利用索引。如where user_id+2=100，可以改写成 where user_id = 100-2。
12. 分页查询，当limit起点较高时，可先用过滤条件进行过滤。如select a,b,c from t1 limit 10000,20;优化为: select a,b,c from t1 where id>10000 limit 20;。
13. 当表的规模超过千行时，不建议做count(*)，尤其是一个经常被使用的表，建议在程序端的做好数据插入和删除的统计工作，再在一个统计表中更新记录，避免随着运行时间的增加，在上亿的表上做count(*)

二 多表连接

1. 禁止跨db的join语句。因为这样可以减少模块间耦合，为数据库拆分奠定坚实基础。
2. 禁止在业务的更新类SQL语句中使用join，比如update t1 join t2…。
3. 不建议使用子查询，建议将子查询SQL拆开结合程序多次查询，或使用join来代替子查询。
4. 线上环境，多表join不要超过3个表。
5. 在多表join中，尽量选取结果集较小的表作为驱动表，来join其他表。

三 事务

1. 批量操作数据时，需要控制事务处理间隔时间，进行必要的sleep，一般建议值5-10秒。
2. 对于有auto_increment属性字段的表的插入操作（单事物），并发需要控制在200以内。
3. 事务里包含SQL不超过5个（支付业务除外）。因为过长的事务会导致锁数据较久，MySQL内部缓存、连接消耗过多等雪崩问题。
   • 即TPS / QPS越接近1越好
4. 尽量把一些典型外部调用移出事务，如调用webservice，访问文件存储等，从而避免事务过长。

四 排序和分组

1. 减少使用order by，和业务沟通能不排序就不排序，或将排序放到程序端去做。order by、group by、distinct这些语句较为耗费CPU，数据库的CPU资源是极其宝贵的。
2. order by、group by、distinct这些SQL尽量利用索引直接检索出排序好的数据。如where a=1 order by可以利用key(a,b)。
3. 包含了order by、group by、distinct这些查询的语句，where条件过滤出来的结果集请保持在1000行以内，否则SQL会很慢。尽量使用limit保持行数，内部会根据返回的结果集和buffer大小选择不同的排序算法。

五 线上禁止使用的SQL语句

1. 禁止使用关联子查询，如update t1 set … where name in(select name from user where…);效率极其低下。
2. 禁用procedure、function、trigger、views、event、外键约束。因为他们消耗数据库资源，降低数据库实例可扩展性。推荐都在程序端实现。
3. 禁止联表更新语句，如update t1,t2 where t1.id=t2.id…。