需求:数据加载慢(卡)
其实是SQL的优化
学习路线:
(选择数据库)-》业务分析(表,字段)-》逻辑设计(范式-》关系表,反范式-》宽表)
-》物理设计(选择存储引擎》数据类型》对象命名-》建立库表)
-》索引优化(慢查询-》执行计划)
-》SQL改写
-》事务ACID(由于高并发-》产生阻塞,死锁)
-》高可用,高可扩展(集群,负载均衡,主从复制,读写分离,分库分表(水平分割,垂直分割))
一,数据库:MySQL
二,业务分析:根据项目需求,得出需要创建的表,每个表应该有什么字段
三,逻辑设计:
三大范式:
- 单个字段不能再分。如:联系方式-》拆分-》手机,微信,QQ。。。
- 非主键字段必须依赖主键(有主键才有非主键,人在塔在)
- 非主键之间不能相互依赖(女朋友和小三不兼容)
- 优点:减少数据冗余
- 缺点:增加关联,产生关系表
反范式:根据业务需要,把需要的数据放进表中。
- 优点:减少关联表(运用:1:N关系,将1中适当的字段放进N中)
- 缺点:泛用使数据冗余,产生宽表
宽表:将所有字段放一个表中
关系表:两个表的关联
四,物理设计
存储引擎:INNODB
数据类型:
- 优先使用字节小的类型(timestamp代替datetime,字符串转整型存储,varchar代替text)
- 精度用decimal
- 不为NULL
对象命名:
- 包含库名
- 小写+下划线
- 不使用保留字
- 见名识义
- 相同数据列,列名和数据类型一致
- 临时表tmp,备份表bak前缀,日期为后缀
建立库表:DDL语句
五,索引优化:索引=目录,更快查询。常用主键,普通索引,唯一索引,联合索引
- 索引不是越多越好
- where,on/using,group,order,distinct中加索引(order by NULL:不进行文件排序)
- 索引列不能使用表达式和函数
- NOT IN和<>不能使用索引
- 范围查询的右边列不能使用索引
- order中全部列,group和order在一个表中
- 联合索引顺序:只能从最左侧使用索引,且不能跳过其中一列
- 覆盖索引:select,where中的列都是索引
- 前缀索引:一段字符串的最前一部分作为索引。唯一性越高越好,但不能过多
六,SQL改写
- 使用join或CTE(8.0的公共表表达式)代替子查询
- 大SQL改小SQL
- 巧用计算列
- 使用limit,field,count(*)
- 汇总表
- 缓存数据
附录:
3.对于修改数量的计算,封装成一个统计方法
,每次如果涉及到修改,调用一下这个方法
。
4.多个类中都用到的API,封装到common控制器中