Article / 文章中心

最强MySQL数据库设计规范...(三)

发布时间:2022-02-16 点击数:222

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…。