浅谈优化顺序

提到sql优化,不要一上来就是加索引,索引增长存储负荷,下降写入效率,并且有时候添加了还不定用获得，因此添加索引不是万灵药。也不是惟一手段，如下从开发者角度与数据库运维角度总结了优化流程，以供你们借鉴。

优化流程:

• 开发角度: sql语句优化 → 第三方优化 → 索引优化 → 模型优化 → 修改功能

• 运维角度: 数据库配置 → 读写分离 → 虚拟机配置 → 物理机配置

---

sql语句优化:

• 检测sql是否能够拆分
• 分析sql语句执行计划,是否须要添加索引
• 样例:
  • sql语句功能: 查询某商品全部评论以及评论匹配到的信息
  • sql优化前性能: 数据量达到200万总量查询效率极差,具体表如今4核服务器满cpu运行10分钟未出结果
• 优化过程:
  1. 语句拆分，先查询商品全部包含子商品，查询该子商品全部评论 --> 优化结果60s出结果
  2. 针对该语句查询字段创建索引 --> 优化结果20s出结果
  3. 更改数据模型，由原来6个表下降到5个表 --> 优化结果1-8秒出结果(达到公司要求)

优缺点: 改动量最小，可是优化程度有限

第三方优化:

• 添加内存数据库-redis
• 添加全文搜索引擎-elasticsearch
• 添加....
• 样例:
  • 一个查询全部数据页面，每次用户点都要10s响应，并且点多几回就会占用完链接池
• 分析缘由：
  • 经过分析了解到用户只是想看最新的数据状况，极少数会翻页
• 优化过程
  • 使用redis缓存每一个用户前几页数据 --> 秒出

优缺点: 使用灵活,增长运营成本

索引优化：

• 经常使用优化手段，就再也不多作复述了

模型优化:

• 模型重构,主要是达到查询减小关联查询
• 样例：
  • 原来咱们查询购买，经过多表关联查询 --> 平均查询20s
• 优化过程
  • 将购买数据拍平成一张表，直接填写相关数据，去掉外键关联 --> 秒出

优缺点:影响较大,可极大程度优化

修改功能

• 在前面那些都没法优化时候就能够考虑修改功能
• 样例：
  • 分页时前端须要数据count来计算中的总页码，然而不少时候查询卡在sql count这里
• 优化过程
  • 采用相似百度分页效果，一次显示10页页码，不足的以实际稳准，在mysql查询中可经过limit a,b实现该效果，同时能够配合redis提早缓存其余分页数据,即提升了效率,又解决问题

优缺点:改动量最大,可最大程度优化

---

建议：

详细设计时,应该针对模型进行评审,评审应该从主要功能查询出发,检验模型是否能够高效支持查询。

1. 尽可能减小关联查询
2. 不拘泥于设计范式

---

若是不知道送女神啥礼物,扫他 ↓↓↓↓

---

• 太忙没时间挑礼物,或者不知道送什么?
• 怕买到贵的,或者质量差的?
• 没事,没事,ag银饰为你解决全部麻烦.
• 本店主营银饰,接受黄金,钻戒定制.
• 本店保证,质量优良,价格实惠,童叟无欺,顺丰包邮