2.2.2 多表衔接

1. 【强制】制止跨db的join句子。由于这样可以减少模块间耦合，为数据库拆分奠定坚实基础。
2. 【强制】制止在业务的更新类SQL句子中运用join，比方update t1 join t2…。
3. 【主张】不主张运用子查询，主张将子查询SQL拆开结合程序多次查询，或运用join来替代子查询。
4. 【主张】线上环境，多表join不要超越3个表。
5. 【主张】多表衔接查询推荐运用别号，且SELECT列表中要用别号引用字段，数据库.表格局，如select a from db1.table1 alias1 where …。
6. 【主张】在多表join中，尽量选取结果集较小的表作为驱动表，来join其他表。

2.2.3 业务

1. 【主张】业务中INSERT|UPDATE|DELETE|REPLACE句子操作的行数操控在2000以内，以及WHERE子句中IN列表的传参个数操控在500以内。
2. 【主张】批量操作数据时，需求操控业务处理间隔时间，进行必要的sleep，一般主张值5-10秒。
3. 【主张】对于有auto_increment属性字段的表的刺进操作，并发需求操控在200以内。
4. 【强制】程序设计有必要考虑“数据库业务阻隔级别”带来的影响，包括脏读、不可重复读和幻读。线上主张业务阻隔级别为repeatable-read。
5. 【主张】业务里包含SQL不超越5个（付出业务除外）。由于过长的业务会导致锁数据较久，MySQL内部缓存、衔接耗费过多等雪崩问题。
6. 【主张】业务里更新句子尽量基于主键或unique key，如update … where id=XX; 否则会发生间隙锁，内部扩展确定规模，导致系统功能下降，发生死锁。
7. 【主张】尽量把一些典型外部调用移出业务，如调用webservice，拜访文件存储等，然后防止业务过长。
8. 【主张】对于MySQL主从推迟严格灵敏的select句子，请敞开业务强制拜访主库。

2.2.4 排序和分组

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会很慢。

2.2.5 线上制止运用的SQL句子

1. 【高危】禁用update|delete t1 … where a=XX limit XX;这种带limit的更新句子。由于会导致主从不一致，导致数据错乱。主张加上order by PK。
2. 【高危】制止运用关联子查询，如update t1 set … where name in(select name from user where…);功率极端低下。
3. 【强制】禁用procedure、function、trigger、views、event、外键约束。由于他们耗费数据库资源，下降数据库实例可扩展性。推荐都在程序端完成。
4. 【强制】禁用insert into …on duplicate key update…在高并发环境下，会造成主从不一致。
5. 【强制】制止联表更新句子，如update t1,t2 where t1.id=t2.id…。