2.2.2 多表连接
- 【强制】禁止跨db的join语句。因为这样可以减少模块间耦合，为数据库拆分奠定坚实基础。
- 【强制】禁止在业务的更新类SQL语句中使用join，比如
update t1 join t2…。 - 【建议】不建议使用子查询，建议将子查询SQL拆开结合程序多次查询，或使用join来代替子查询。
- 【建议】线上环境，多表join不要超过3个表。
- 【建议】多表连接查询推荐使用别名，且SELECT列表中要用别名引用字段，数据库.表格式，如
select a from db1.table1 alias1 where …。 - 【建议】在多表join中，尽量选取结果集较小的表作为驱动表，来join其他表。
2.2.3 事务
- 【建议】事务中
INSERT|UPDATE|DELETE|REPLACE语句操作的行数控制在2000以内，以及WHERE子句中IN列表的传参个数控制在500以内。 - 【建议】批量操作数据时，需要控制事务处理间隔时间，进行必要的sleep，一般建议值5-10秒。
- 【建议】对于有
auto_increment属性字段的表的插入操作，并发需要控制在200以内。 - 【强制】程序设计必须考虑“数据库事务隔离级别”带来的影响，包括脏读、不可重复读和幻读。线上建议事务隔离级别为
repeatable-read。 - 【建议】事务里包含SQL不超过5个（支付业务除外）。因为过长的事务会导致锁数据较久，MySQL内部缓存、连接消耗过多等雪崩问题。
- 【建议】事务里更新语句尽量基于主键或
unique key，如update … where id=XX; 否则会产生间隙锁，内部扩大锁定范围，导致系统性能下降，产生死锁。 - 【建议】尽量把一些典型外部调用移出事务，如调用webservice，访问文件存储等，从而避免事务过长。
- 【建议】对于MySQL主从延迟严格敏感的select语句，请开启事务强制访问主库。
2.2.4 排序和分组
- 【建议】减少使用
order by，和业务沟通能不排序就不排序，或将排序放到程序端去做。order by、group by、distinct这些语句较为耗费CPU，数据库的CPU资源是极其宝贵的。 - 【建议】
order by、group by、distinct这些SQL尽量利用索引直接检索出排序好的数据。如where a=1 order by可以利用key(a,b)。 - 【建议】包含了
order by、group by、distinct这些查询的语句，where条件过滤出来的结果集请保持在1000行以内，否则SQL会很慢。
2.2.5 线上禁止使用的SQL语句
- 【高危】禁用
update|delete t1 … where a=XX limit XX;这种带limit的更新语句。因为会导致主从不一致，导致数据错乱。建议加上order by PK。 - 【高危】禁止使用关联子查询，如
update t1 set … where name in(select name from user where…);效率极其低下。 - 【强制】禁用procedure、function、trigger、views、event、外键约束。因为他们消耗数据库资源，降低数据库实例可扩展性。推荐都在程序端实现。
- 【强制】禁用
insert into …on duplicate key update…在高并发环境下，会造成主从不一致。 - 【强制】禁止联表更新语句，如
update t1,t2 where t1.id=t2.id…。
