高并发大多的瓶颈在后台,在存储,mysql的正常的优化方案如下:

1)代码中sql语句优化

2)数据库字段优化,索引优化

3)加缓存,redis/memcache等

4)主从,读写分离

5)分区表

6)垂直拆分,解耦模块

7)水平切分

点评:

1、1&2是最简单,也是提升效率最快的方式。也许有人说这两点你已经做的很好了,你的每条语句都命中了索引,是最高效的。但是你是否是为了你的sql达到最优而去建索引,而不是从整个业务上来考虑。比如,订单表上我需要增加xx索引满足某单一业务,是否就一定要加,其他方法能否解决。如果要满足所有业务的需求,那么索引就泛滥了,对于千万级以上的表来说,维护索引的成本大大增加,反而增加了数据库的内存的开销。

2、数据库字段的优化。曾经发现一高级程序员在表字段的设计上,一个日期类型,被设计为varchar类型,不规范的同时,无法对写入数据校验,做索引的效率也有差别(网(xian)友(pen)的(liao)观(zai)点(shuo),具体差别原理不详)。

3、缓存适合读多写少更新频度相对较低的业务场景,否则缓存异议不大,命中率不高。缓存通常来说主要为了提高接口处理速度,降低并发带来的db压力以及由此产生的其他问题。你的接口时延多少?有没有被用户吐槽?有没有必要提升?好吧,我们的前台后台商家并发量太低,当我没说。

4、分区不是分表,结果还是一张表,只不过把存放的数据文件分词了多个小块,分块后。在表数据非常大的情况下,可以解决无法一次载入内存,以及大表数据维护等问题。

5、垂直拆分将表按列拆成多表,常见于将主表的扩展数据独立开,文本数据独立开,降低磁盘io的压力。

6、水平拆,这是一把最有效的牛刀。但是存在一个误区,有的人会觉得,为什么不在最开始就直接水平线拆,免去了后面迁移数据的麻烦。我个人感觉是,下定某个决策之前,必须有一个非常充分的理由。水平拆分的主要目的是提升单表并发读写能力(压力分散到各个分表中)和磁盘IO性能(一个非常大的.MYD文件分摊到各个小表的.MYD文件中)。如果没有千万级以上数据,为什么要拆,仅对单表做做优化也是可以的;再如果没有太大的并发量,分区表也一般能够满足。所以,一般情况下,水平拆分是最后的选择,在设计时还是需要一步一步走。

————————————————
版权声明:本文为CSDN博主「qiuweihong」的原创文章,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qiuweihong/article/details/78751466

最新文章

  1. 使用R进行倾向得分匹配
  2. implicit operator
  3. (转)iphone数据存储之-- Core Data的使用
  4. linux系统的目录讲解
  5. iOS本机生成证书请求文件流程
  6. 示例:Servlet显示当前系统时间(时间格式化)
  7. NAND Flash内部结构简介
  8. 转:ElasticSearch 插件安装
  9. HTML系列(二):头部meta元素
  10. 巧妙利用ToArray()函数移除集合中的元素
  11. 模拟在内存中的数据库DataSet相关的类
  12. python之路 socket,socketsever初探
  13. java实现网页爬虫
  14. HTML5.1 推荐中 1.5.3. Extensibility 段落翻译
  15. ueditor插入百度音乐无法播放-403 问题
  16. [C#] 获取计算机内部信息 - ComputerInfoHelper
  17. Java开源生鲜电商平台-系统简介
  18. jdbc crud
  19. GMM-实现聚类的代码示例
  20. 廖雪峰Java2面向对象编程-2数据封装-1方法

热门文章

  1. JVM:类加载与字节码技术-2
  2. 理解ASP.NET Core - 路由(Routing)
  3. Scrum Meeting 0609
  4. docker multi-stage 多阶段构建
  5. boost编译中的细节问题
  6. Spring Boot 2.5.0 重新设计的spring.sql.init 配置有何用?
  7. (二)FastDFS 高可用集群架构学习---搭建
  8. Centos 8 升级ssl到1.1.1h
  9. Ambari 2.4 在 CentOS 7.4 因 TLS_1.2 协商内部错误导致注册失败
  10. 印象最深的一个bug——排查修复问题事件BEX引发的谷歌浏览器闪退崩溃异常