数据库设计三大规范 数据库设计规范( 三 )


【建议】SELECT|UPDATE|DELETE|REPLACE必须有WHERE子句,WHERE子句的条件必须按索引搜索 。
【强制】对于生产数据库中的大型表,强烈不建议使用全表扫描,但对于10个信息资源网络中少于0行的静态表,可以使用全表扫描 。查询量不应超过表行的25%,否则索引将不会被利用 。
【强制】在W信息资源网的HERE条款中,禁止仅使用模糊的LIKE条件进行搜索 。必须有其他等价或范围查询条件,否则索引不能使用 。
[建议]不要在索引列中使用函数或表达式,否则无法使用索引 。比如其中length(name)='Admin '或者其中user_id+2=10023 。
[建议]减少or语句的使用,将or语句优化为union,然后对每个where条件建立索引 。例如,其中a=1或b=2被优化为其中a = 1 … union …其中b = 2,key (a),key (b) 。
【建议】对于分页查询,当限制起点较高时,可以先用过滤条件过滤 。从t1限值10000,20中选择a,b,c;优化是:从t1中选择a,b,c其中id > 10000限制20; 。
2.多表连接
[Force]禁止跨db join语句 。这样可以减少模块之间的耦合,为数据库拆分打下坚实的基础 。
【强制】禁止在业务更新SQL语句中使用join,如update t1 join t2…
[建议]不建议使用子查询 。建议反汇编子查询SQL,并将其与程序结合起来进行多次查询,或者使用join代替子查询 。
【建议】在线环境下,多表连接不要超过3个表 。
【建议】多表连接查询推荐使用别名,字段、数据库、表格式都要在选择列表中用别名引用,比如SELECT a from db1 . table 1 Alias 1 where…
【建议】在多表连接中,尽量选择结果集较小的表作为连接其他表的驱动表 。
3.事务
【建议】一个事务中INSERT|UPDATE|DELETE|REPLACE语句的行数应控制在2000以内,WHERE子句中传递给IN列表的参数数应控制在500以内 。
【建议】批量操作数据时,要控制好交易间隔,进行必要的睡眠 。一般推荐值为5-10秒 。
【建议】对于带有auto_increment属性字段的表的插入操作,并发应该控制在200以内 。
【强制】编程必须考虑“数据库事务隔离级别”的影响,包括脏读、不可重复读和幻影读 。推荐的在线事务隔离级别是可重复读取 。
【建议】交易中包含的SQL不超过5条(支付业务除外) 。因为过长的事务会导致过长的数据锁、MySQL内部缓存、过多的连接消耗等雪崩问题 。
【建议】事务中的Update语句尽量基于主键或唯一键,比如Update…where id = XX;否则会产生间隙锁,内部会放大锁定范围,导致系统性能下降和死锁 。
【建议】尽量将一些典型的外部调用移出事务,比如调用webservice、访问文件存储等,避免事务过长 。
【建议】对于MySQL主从延迟严格敏感的select语句,请打开事务强制访问主库 。
4.排序和分组
【建议】减少order by的使用,与业务沟通不进行排序,或者将排序放在程序端 。order by、group by和distinct语句消耗CPU,数据库的CPU资源极其宝贵 。
【建议】order by、group by、distinct等SQL应尽量使用索引直接检索排序后的数据 。例如,在a=1的情况下,order by可以使用key(a,b) 。
[建议]它包含order by、group by和distinct语句 。由where条件过滤的结果集应该保持在1000行以内,否则SQL会很慢 。
5.在线禁止的SQL语句
【高风险】禁用更新|删除t1 …其中a = xx限制xx;这个update语句有限制 。因为会导致主的不一致,造成数据混乱 。按主键添加订单 。
【高风险】禁止使用关联的子查询,如update t1 set…where name in(select name from user where…);效率极低 。
[强制]禁用过程、函数、触发器、视图、事件和外键约束 。因为它们消耗数据库资源并降低数据库实例的可伸缩性 。所有建议都在程序端实现 。
【强制】禁用insert into…on duplicate key update…在高并发环境下,会造成主从不一致 。
[Force]禁止关联的表更新语句,例如update t1,t2,其中t1.id=t2.id…
觉得有用的朋友帮忙转发一下吧!后面会分享更多关于devops和DBA的内容,感兴趣的朋友可以关注一下~
【数据库设计三大规范 数据库设计规范】


推荐阅读