高并发解决方案-mysql篇

1、mysql篇

高并发大多的瓶颈在后台，在存储，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文件中)。如果没有千万级以上数据，为什么要拆，仅对单表做做优化也是可以的；再如果没有太大的并发量，分区表也一般能够满足。所以，一般情况下，水平拆分是最后的选择，在设计时还是需要一步一步走。

2、索引原理初探

先抛出几个问题：

你知道InnoDB和MyIsam的区别吗？

InnoDB和MyIsam分别适合是用到什么场景下，为什么？

InnoDB和MyIsam分别使用的什么索引，如何实现的？

在分析索引之前，我们先要了解下几个数据结构。

1、二叉搜索树：每个节点有两个子节点，数据量的增大必然导致高度的快速增加，显然这个不适合作为大量数据存储的基础结构。

2、B树：一棵m阶B树是一棵平衡的m路搜索树。最重要的性质是每个非根节点所包含的关键字个数 j 满足：┌m/2┐ - 1

3、B+树：一棵m阶B树是一棵平衡的m路搜索树。最重要的性质是每个非根节点所包含的关键字个数 j 满足：┌m/2┐ - 1

B树与B+树两个最大区别：

1、B+树中，所有的数据都存在叶子节点中，B树部分数据在非叶子节点。

2、B+数叶子节点类似单链表，可以顺序找到下一个叶子结点。

(B数和B+数的分裂过程不在这里展示了，有兴趣同学可以查看参看资源1)

有计算机是内存-机械硬盘两层存储结构，所以B+树非常适合作为数据库的基础结构。内存可以完成快速的随机访问，但是容量较小。而硬盘的随机访问要经过机械动作（1磁头移动 2盘片转动），访问效率比内存低几个数量级，但是硬盘容量较大。

典型的数据库容量大大超过可用内存大小，这就决定了在B+树中检索一条数据很可能要借助几次磁盘IO操作来完成。如下图所示：通常向下读取一个节点的动作可能会是一次磁盘IO操作，不过非叶节点通常会在初始阶段载入内存以加快访问速度。同时为提高在节点间横向遍历速度，真实数据库中可能会将图中蓝色的CPU计算/内存读取优化成二叉搜索树（InnoDB中的page directory机制）。

了解B+数的结构和查询方式后，我看看B+树深度问题。

1 每个叶子节点存储468行数据，每个非叶子节点存储1203个键值，是一棵平衡的1203路搜索树

2 对于一个22.1G容量的表，也只需要高度为3的B+树就能存储了，这个容量大概能满足很多应用的需要了。如果把高度增大到4，B+树的存储容量立刻增大到25.9T之巨，当然也会多一次磁盘IO，没必要。

3 对于一个22.1G容量的表，B+树的高度是3，如果要把非叶节点全部加载到内存也只需要少于18.8M的内存，这样我们可以保证只需要一次磁盘IO操作就检索出所需的数据，效率是非常之高的。

更多的详细可以参考

1、http://blog.csdn.net/v_JULY_v/article/details/6530142/

2、http://www.linuxidc.com/Linux/2014-10/108487.htm

3、高性能Mysql的索引章节

高并发解决方案-mysql篇相关推荐

Mysql高并发解决方案
Mysql高并发解决方案前言随着近些年来分布式的应用,其伴随而来的是系统的数据量也越来越大,为了可以提升系统的整体性能,我们对以Mysql为代表的关系型数据库也提出了"分布式" ...
01 - Java并发编程与高并发解决方案笔记-基础篇
01 - Java并发编程与高并发解决方案笔记-基础篇基础篇很重要!很重要!很重要!!!一定要理解和认真思考. 01 - Java并发编程与高并发解决方案笔记-基础篇 1.课程准备 2.并发编程基础 ...
JavaWeb 并发编程与高并发解决方案
在这里写写我学习到和自己所理解的 Java高并发编程和高并发解决方案.现在在各大互联网公司中,随着日益增长的互联网服务需求,高并发处理已经是一个非常常见的问题,在这篇文章里面我们重点讨论两个方面的问题 ...
大型网站应用之海量数据和高并发解决方案
一.网站应用背景开发一个网站的应用程序,当用户规模比较小的时候,使用简单的:一台应用服务器+一台数据库服务器+一台文件服务器,这样的话完全可以解决一部分问题,也可以通过堆硬件的方式来提高网站应用的访 ...
电商中常见的高并发解决方案
目录多级缓存什么叫多级缓存多级缓存的实现思路 Redis 缓存同步 MySql 数据 Nginx 限流什么是限流常见的限流算法之漏桶算法 nginx 限流的方式控制速率控制并发量(连接数 ...
大数据和高并发解决方案
一.网站应用背景开发一个网站的应用程序,当用户规模比较小的时候,使用简单的:一台应用服务器+一台数据库服务器+一台文件服务器,这样的话完全可以解决一部分问题,也可以通过堆硬件的方式来提高网站应用的访 ...
大数据时代的海量数据存储、和高并发解决方案总结
一.结构化数据的存储随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载.对于系统的稳定性和扩展性造成了极 ...
[转]淘宝下单高并发解决方案
周末参加了@淘宝技术嘉年华主办的技术沙龙, 感觉收获颇丰,非常感谢淘宝人的分享.这里我把淘宝下单高并发解决方案的个人理解分享一下.我不是淘宝技术人员,本文只是写自己的理解,所以肯定是会有一些出入的. ...
mysql高可靠部署_可能是我见过最好的 MySQL 高可用解决方案 MySQL InnoDB Cluster 中文教程！...
公众号关注「运维之美」设为「星标」,每天带你玩转 Linux ! 这篇文章将详细地介绍 MySQL 的高可用解决方案-- MySQL InnoDB Cluster. 说到高可用性,首先要了解一下什么 ...

高并发解决方案-mysql篇

高并发解决方案-mysql篇相关推荐

最新文章

热门文章