[版权声明] 本站所有资料由用户提供并上传，若内容存在侵权，请联系邮箱。资料中的图片、字体、音乐等需版权方额外授权，请谨慎使用。网站中党政主题相关内容(国旗、国徽、党徽)仅限个人学习分享使用，禁止广告使用和商用。

更多详情，请转向我的Github仓库：

欢迎来做客，欢迎star~

在本文将讨论数据库原理和MySQL核心知识，MySQL性能优化等，包含 “MySQL基础” 和 “高性能MySQL实践” 两部分。

• 《高性能MySQL》第三版
• 部分参考：，特别鸣谢作者 @CyC2018

• 【慕课网】MySQL性能管理及架构设计
• 【龙果学院】MySQL大型分布式集群

第一部分：MySQL基础

MySQL的多存储引擎架构

这里先有个整体的MySQL Server的整体概念，详情转向：

（3）在事务1中，Mary 再次读取自己的工资时，工资变为了2000

在一个事务中前后两次读取的结果并不致，导致了不可重复读。

　　如果只有在修改事务完全提交之后才可以读取数据，则可以避免该问题。把数据库的事务隔离级别调整到REPEATABLE_READ

　　T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

事务1再次读取所有工资为 1000的 员工（共读取到了 11 条记录，这就像产生了幻读）

　　如果在操作事务完成数据处理之前，任何其他事务都不可以添加新数据，则可避免该问题。把数据库的事务隔离级别调整到 SERIALIZABLE_READ

　　T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。

　　所有事务一个接着一个的执行，这样可以避免幻读 (phantom read)，对于基于锁来实现并发控制的数据库来说，串行化要求在执行范围查询的时候，需要获取范围锁，如果不是基于锁实现并发控制的数据库，则检查到有违反串行操作的事务时，需回滚该事务。

　　所有被 Select 获取的数据都不能被修改，这样就可以避免一个事务前后读取不一致的情况。但是没有办法控制幻读，因为这个时候其他事务不能更改所选的数据，但是可以增加数据，因为强恶意事务没有范围锁。

　　被读取的数据可以被其他事务修改，这样可能导致不可重复读。也就是说，事务读取的时候获取读锁，但是在读完之后立即释放(不需要等事务结束)，而写锁则是事务提交之后才释放，释放读锁之后，就可能被其他事务修改数据。该等级也是 SQL Server 默认的隔离等级。

　　最低的隔离等级，允许其他事务看到没有提交的数据，会导致脏读。

• 四个级别逐渐增强，每个级别解决一个问题，每个级别解决一个问题，事务级别遇到，性能越差，大多数环境(Read committed 就可以用了)

隔离级别脏读不可重复读幻影读未提交读√√√提交读×√√可重复读××√可串行化×××

　　对于初学者来说我们通常不关注存储引擎，但是 MySQL 提供了多个存储引擎，包括处理事务安全表的引擎和处理非事务安全表的引擎。在 MySQL 中，不需要在整个服务器中使用同一种存储引擎，针对具体的要求，可以对每一个表使用不同的存储引擎。

　　MySQL 中的数据用各种不同的技术存储在文件（或者内存）中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。存储引擎说白了就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。

　　例如，如果你在研究大量的临时数据，你也许需要使用内存存储引擎。内存存储引擎能够在内存中存储所有的表格数据。又或者，你也许需要一个支持事务处理的数据库（以确保事务处理不成功时数据的回退能力）。

在MySQL中有很多存储引擎，每种存储引擎大相径庭，那么又改如何选择呢？

　　不同存储引起都有各自的特点，为适应不同的需求，需要选择不同的存储引擎，所以首先考虑这些存储引擎各自的功能和兼容。

MySQL 5.5版本之前的默认存储引擎，在 5.0 以前最大表存储空间最大 4G，5.0 以后最大 256TB。

Myisam 存储引擎由 .myd（数据）和 .myi（索引文件）组成，.frm文件存储表结构（所以存储引擎都有）

• 并发性和锁级别 （对于读写混合的操作不好，为表级锁，写入和读互斥）
• Myisam 表支持的索引类型（全文索引）
• Myisam 支持表压缩（压缩后，此表为只读，不可以写入。使用myisampack压缩）

• 只读类应用（插入不频繁，查询非常频繁）
• 空间类应用（唯一支持空间函数的引擎）

MySQL 5.5 及之后版本的默认存储引擎

• Innodb为事务性存储引擎
• 完全支持事物的 ACID 特性
• Redo log （实现事务的持久性） 和 Undo log（为了实现事务的原子性，存储未完成事务log，用于回滚）
• 行级锁可以最大程度的支持并发
• 行级锁是由存储引擎层实现的

• 可靠性要求比较高，或者要求事务
• 表更新和查询都相当的频繁，并且行锁定的机会比较大的情况。

• 数据以文本方式存储在文件中
• .csv文件存储表内容
• .csm文件存储表的元数据，如表状态和数据量

• 以 CSV 格式进行数据存储
• 所有列必须都是不能为 NULL
• 可以对数据文件直接编辑（其他引擎是二进制存储，不可编辑）

• 以 zlib 对表数据进行压缩，磁盘 I/O 更少
• 数据存储在ARZ为后缀的文件中（表文件为 a.arz，a.frm）
• 只允许在自增ID列上加索引

• 也称为 HEAP 存储引擎，所以数据保存在内存中（数据库重启后会导致数据丢失）
• 支持 HASH 索引（等值查找应选择 HASH）和 BTree 索引（范围查找应选择）
• Memory 存储使用表级锁（性能可能不如 innodb）

• 用于查找或是映射表，例如右边和地区的对应表
• 用于保存数据分析中产生的中间表
• 用于缓存周期性聚合数据的结果表

注意： Memory 数据易丢失，所以要求数据可再生

• 提供了访问远程 MySQL 服务器上表的方法
• 本地不存储数据，数据全部放在远程服务器上

默认是禁止的。如果需要启用，需要在启动时增加Federated参数

问：独立表空间和系统表空间应该如何抉择

• 系统表空间：无法简单的收缩大小（这很恐怖，会导致 ibdata1 一直增大，即使删除了数据也不会变小）
• 独立表空间：可以通过 optimize table 命令收缩系统文件
• 系统表空间：会产生I/O瓶颈（因为只有一个文件）
• 独立表空间：可以向多个文件刷新数据

总结 强烈建议：对Innodb引擎使用独立表空间（mysql5.6版本以后默认是独立表空间）

系统表转移为独立表的步骤（非常繁琐）

• 使用 mysqldump 导出所有数据库表数据
• 停止 mysql 服务，修改参数，并且删除Innodb相关文件

重要一点： 不要混合使用存储引擎 强烈推荐： Innodb

• MyISAM 是非事务安全型的，而 InnoDB 是事务安全型的。
• MyISAM 锁的粒度是表级，而 InnoDB 支持行级锁定。
• MyISAM 支持全文类型索引，而 InnoDB 不支持全文索引。
• MyISAM 相对简单，所以在效率上要优于 InnoDB，小型应用可以考虑使用 MyISAM。
• MyISAM 表是保存成文件的形式，在跨平台的数据转移中使用 MyISAM 存储会省去不少的麻烦。

• MyISAM 管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的 SELECT 查询，那么 MyISAM 是更好的选择。
• InnoDB 用于事务处理应用程序，具有众多特性，包括 ACID 事务支持。如果应用中需要执行大量的 INSERT 或 UPDATE 操作，则应该使用 InnoDB，这样可以提高多用户并发操作的性能。

问：为什么不建议 InnoDB 使用亿级大表

仅作拓展延伸，详情请转向：

INT(11) 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。

FLOAT 和 DOUBLE 为浮点类型，DECIMAL 为高精度小数类型。CPU 原生支持浮点运算，但是不支持 DECIMAl 类型的计算，因此 DECIMAL 的计算比浮点类型需要更高的代价。

主要有 CHAR 和 VARCHAR 两种类型，一种是定长的，一种是变长的。

VARCHAR 这种变长类型能够节省空间，因为只需要存储必要的内容。但是在执行 UPDATE 时可能会使行变得比原来长，当超出一个页所能容纳的大小时，就要执行额外的操作。MyISAM 会将行拆成不同的片段存储，而 InnoDB 则需要分裂页来使行放进页内。

VARCHAR 会保留字符串末尾的空格，而 CHAR 会删除。

能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。

默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值，例如“ 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。

和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。

它和时区有关，也就是说一个时间戳在不同的时区所代表的具体时间是不同的。

默认情况下，如果插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。

索引能够轻易将查询性能提升几个数量级。

1. 对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效。
2. 对于中到大型的表，索引就非常有效。
3. 但是对于特大型的表，建立和维护索引的代价将会随之增长。这种情况下，需要用到一种技术可以直接区分出需要查询的一组数据，而不是一条记录一条记录地匹配，例如可以使用分区技术。

索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎具有不同的索引类型和实现。

定义一条数据记录为一个二元组 [key, data]，B-Tree 是满足下列条件的数据结构：

• 所有叶节点具有相同的深度，也就是说 B-Tree 是平衡的；
• 一个节点中的 key 从左到右非递减排列；

查找算法：首先在根节点进行二分查找，如果找到则返回对应节点的 data，否则在相应区间的指针指向的节点递归进行查找。

由于插入删除新的数据记录会破坏 B-Tree 的性质，因此在插入删除时，需要对树进行一个分裂、合并、旋转等操作以保持 B-Tree 性质。

• 每个节点的指针上限为 2d 而不是 2d+1（d 为节点的出度）；
• 内节点不存储 data，只存储 key；

一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 基础上进行了优化，在叶子节点增加了顺序访问指针，做这个优化的目的是为了提高区间访问的性能。

红黑树等平衡树也可以用来实现索引，但是文件系统及数据库系统普遍采用 B Tree 作为索引结构，主要有以下两个原因：

平衡树检索数据的时间复杂度等于树高 h，而树高大致为 O(h)=O(logdN)，其中 d 为每个节点的出度。

红黑树的出度为 2，而 B Tree 的出度一般都非常大。红黑树的树高 h 很明显比 B Tree 大非常多，因此检索的次数也就更多。

B+Tree 相比于 B-Tree 更适合外存索引，因为 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，检索效率会更高。

（二）利用计算机预读特性

为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。预读过程中，磁盘进行顺序读取，顺序读取不需要进行磁盘寻道，并且只需要很短的旋转时间，因此速度会非常快。

操作系统一般将内存和磁盘分割成固态大小的块，每一块称为一页，内存与磁盘以页为单位交换数据。数据库系统将索引的一个节点的大小设置为页的大小，使得一次 I/O 就能完全载入一个节点，并且可以利用预读特性，相邻的节点也能够被预先载入。

B+Tree 索引是大多数 MySQL 存储引擎的默认索引类型。

因为不再需要进行全表扫描，只需要对树进行搜索即可，因此查找速度快很多。除了用于查找，还可以用于排序和分组。

可以指定多个列作为索引列，多个索引列共同组成键。

B+Tree 索引适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。

如果不是按照索引列的顺序进行查找，则无法使用索引。

主索引的叶子节点 data 域记录着完整的数据记录，这种索引方式被称为聚簇索引。因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。

辅助索引的叶子节点的 data 域记录着主键的值，因此在使用辅助索引进行查找时，需要先查找到主键值，然后再到主索引中进行查找。

InnoDB 引擎有一个特殊的功能叫 “自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就让 B+Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。

哈希索引能以 O(1) 时间进行查找，但是失去了有序性，它具有以下限制：

• 只支持精确查找，无法用于部分查找和范围查找；

MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较是否相等。查找条件使用 MATCH AGAINST，而不是普通的 WHERE。

全文索引一般使用倒排索引实现，它记录着关键词到其所在文档的映射。

空间数据索引（R-Tree）

MyISAM 存储引擎支持空间数据索引，可以用于地理数据存储。空间数据索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。

必须使用 GIS 相关的函数来维护数据。

• 可以加快数据库的检索速度
• 降低数据库插入、修改、删除等维护的速度
• 只能创建在表上，不能创建到视图上
• 既可以直接创建又可以间接创建
• 可以在优化隐藏中使用索引
• 使用查询处理器执行SQL语句，在一个表上，一次只能使用一个索引

• 创建唯一性索引，保证数据库表中每一行数据的唯一性
• 大大加快数据的检索速度，这是创建索引的最主要的原因
• 加速数据库表之间的连接，特别是在实现数据的参考完整性方面特别有意义
• 在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间
• 通过使用索引，可以在查询中使用优化隐藏器，提高系统的性能

• 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加
• 索引需要占用物理空间，除了数据表占用数据空间之外，每一个索引还要占一定的物理空间，如果建立聚簇索引，那么需要的空间就会更大
• 当对表中的数据进行增加、删除和修改的时候，索引也需要维护，降低数据维护的速度

• 如果条件中有or，即使其中有条件带索引也不会使用 (这就是问什么尽量少使用or的原因)
• 对于多列索引，不是使用的第一部分，则不会使用索引
• like查询是以%开头
• 如果列类型是字符串，那一定要在条件中使用引号引起来，否则不会使用索引
• 如果MySQL估计使用全表扫秒比使用索引快，则不适用索引。

8. 在什么情况下适合建立索引

• 在union等集合操作的结果集字段上，建立索引。其建立索引的目的同上。
• 为经常用作查询选择 where 后的字段，建立索引。
• 在经常用作表连接 join 的属性上，建立索引。
• 考虑使用索引覆盖。对数据很少被更新的表，如果用户经常只查询其中的几个字段，可以考虑在这几个字段上建立索引，从而将表的扫描改变为索引的扫描。

两个或更多个列上的索引被称作联合索引，联合索引又叫复合索引。对于复合索引：Mysql 从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。

例如索引是key index (a,b,c)，可以支持[a]、[a,b]、[a,b,c] 3种组合进行查找，但不支 [b,c] 进行查找。当最左侧字段是常量引用时，索引就十分有效。

1. 需要加索引的字段，要在 where 条件中
2. 数据量少的字段不需要加索引
3. 如果 where 条件中是OR关系，加索引不起作用

其中 table_name 是要增加索引的表名，column_list 指出对哪些列进行索引，多列时各列之间用逗号分隔。索引名 index_name 可选，缺省时，MySQL将根据第一个索引列赋一个名称。另外，ALTER TABLE 允许在单个语句中更改多个表，因此可以在同时创建多个索引。

在创建索引时，可以规定索引能否包含重复值。如果不包含，则索引应该创建为 PRIMARY KEY 或 UNIQUE 索引。对于单列惟一性索引，这保证单列不包含重复的值。对于多列惟一性索引，保证多个值的组合不重复。 PRIMARY KEY 索引和 UNIQUE 索引非常类似。

第3条语句只在删除 PRIMARY KEY 索引时使用，因为一个表只可能有一个 PRIMARY KEY 索引，因此不需要指定索引名。如果没有创建 PRIMARY KEY 索引，但表具有一个或多个 UNIQUE 索引，则 MySQL 将删除第一个 UNIQUE 索引。

如果从表中删除了某列，则索引会受到影响。对于多列组合的索引，如果删除其中的某列，则该列也会从索引中删除。如果删除组成索引的所有列，则整个索引将被删除。

6. 什么情况下使用索引

1. 为了快速查找匹配WHERE条件的行。
2. 为了从考虑的条件中消除行。
3. 如果表有一个multiple-column索引，任何一个索引的最左前缀可以通过使用优化器来查找行。
4. 查询中与其它表关联的字，字段常常建立了外键关系
5. 查询中统计或分组统计的字段

10. 聚集索引与非聚集索引

11. 数据库中的分页查询语句怎么写？【阿里面经】

• LIMIT 接受一个或两个数字参数。参数必须是一个整数常量。如果给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数目。初始记录行的偏移量是 0(而不是 1)

12. 常用的数据库有哪些？Redis用过吗？【阿里面经】

• 常用的数据库有哪些？Redis用过吗？
  • Redis 是一个速度非常快的非关系型数据库，他可以存储键(key)与5种不同类型的值（value）之间的映射，可以将存储在内存中的键值对数据持久化到硬盘中。
  • 两者都可用于存储键值映射，彼此性能也相差无几
  • Redis 能够自动以两种不同的方式将数据写入硬盘
  • Redis 除了能存储普通的字符串键之外，还可以存储其他4种数据结构，memcached 只能存储字符串键
  • Redis 既能用作主数据库，由可以作为其他存储系统的辅助数据库
  • 缓存、任务队列、应用排行榜、网站访问统计、数据过期处理、分布式集群架构中的session分离

• 海量数据的高效存储和访问

• STRING：可以是字符串、整数或者浮点数
• LIST：一个链表，链表上的每个节点都包含了一个字符串
• SET：包含字符串的无序收集器（unordered collection），并且被包含的每个字符串都是独一无二、各不相同的
• HAST：包含键值对的无序散列表
• ZSET：字符串成员（member）与浮点数分值（score）之间的有序映射，元素的排列顺序由分值的大小决定

注：更多 Redis 相关内容将在

简单来说，数据的切分就是通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）中，以达到分散单台设备负载的效果，即分库分表。

数据的切分根据其切分规则的类型，可以分为如下两种切分模式。

• 垂直（纵向）切分：把单一的表拆分成多个表，并分散到不同的数据库（主机）上。
• 水平（横向）切分：根据表中数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上。

垂直切分是将一张表按列切分成多个表，通常是按照列的关系密集程度进行切分，也可以利用垂直切分将经常被使用的列和不经常被使用的列切分到不同的表中。

在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库 payDB、用户数据库 userBD 等。

• 拆分后业务清晰，拆分规则明确
• 系统之间进行整合或扩展很容易
• 按照成本、应用的等级、应用的类型等将表放到不同的机器上，便于管理
• 便于实现动静分离、冷热分离的数据库表的设计模式

• 部分业务表无法关联（Join），只能通过接口方式解决，提高了系统的复杂度
• 受每种业务的不同限制，存在单库性能瓶颈，不易进行数据扩展和提升性能

水平切分又称为 Sharding，它是将同一个表中的记录拆分到多个结构相同的表中。

当一个表的数据不断增多时，Sharding 是必然的选择，它可以将数据分布到集群的不同节点上，从而缓存单个数据库的压力。

• 单库单表的数据保持在一定的量级，有助于性能的提高
• 切分的表的结构相同，应用层改造较少，只需要增加路由规则即可
• 提高了系统的稳定性和负载能力

• 切分后，数据是分散的，很难利用数据库的Join操作，跨库Join性能较差
• 分片事务的一致性难以解决
• 数据扩容的难度和维护量极大

垂直切分和水平切分的共同点

• 存在跨节点Join的问题
• 存在跨节点合并排序、分页的问题
• 存在多数据源管理的问题

• 范围：可以是 ID 范围也可以是时间范围
  
• 比如每台服务器计划存放一个亿的数据,先将数据写入服务器A.一旦服务器A写满,则将数据写入服务器B,以此类推. 这种方式的好处是扩展方便.数据在各个服务器上分布均匀.

• 映射表：使用单独的一个数据库来存储映射关系

使用分布式事务来解决，比如 XA 接口。

可以将原来的 JOIN 查询分解成多个单表查询，然后在用户程序中进行 JOIN。

• 使用全局唯一 ID：GUID。
• 为每个分片指定一个 ID 范围。

15. 主从复制与读写分离

主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。

• binlog 线程 ：负责将主服务器上的数据更改写入二进制文件（binlog）中。
• I/O 线程 ：负责从主服务器上读取二进制日志文件，并写入从服务器的中继日志中。
• SQL 线程 ：负责读取中继日志并重放其中的 SQL 语句。

主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。

读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。

MySQL 读写分离能提高性能的原因在于：

• 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
• 从服务器可以配置 MyISAM 引擎，提升查询性能以及节约系统开销；
• 增加冗余，提高可用性。

Explain 用来分析 SELECT 查询语句，开发人员可以通过分析 Explain 结果来优化查询语句。

• select_type : 查询类型，有简单查询、联合查询、子查询等

1. 减少请求的数据量

使用 WHERE 语句进行查询过滤，有时候也需要使用 LIMIT 语句来限制返回的数据。

（三）缓存重复查询的数据

使用缓存可以避免在数据库中进行查询，特别要查询的数据经常被重复查询，缓存可以带来的查询性能提升将会是非常明显的。

2. 减少服务器端扫描的行数

最有效的方式是使用索引来覆盖查询。

一个大查询如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。

将一个大连接查询（JOIN）分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联，这样做的好处有：

• 让缓存更高效。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用。
• 分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询。
• 在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可扩展。
• 查询本身效率也可能会有所提升。例如下面的例子中，使用 IN() 代替连接查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的连接要更高效。

第二部分：高性能MySQL实践

1. 如何解决秒杀的性能问题和超卖的讨论

抢订单环节一般会带来2个问题：

　　比较火热的秒杀在线人数都是10w起的，如此之高的在线人数对于网站架构从前到后都是一种考验。

　　任何商品都会有数量上限，如何避免成功下订单买到商品的人数不超过商品数量的上限，这是每个抢购活动都要面临的难题。

　　将存库MySQL前移到Redis中，所有的写操作放到内存中，由于Redis中不存在锁故不会出现互相等待，并且由于Redis的写性能和读性能都远高于MySQL，这就解决了高并发下的性能问题。然后通过队列等异步手段，将变化的数据异步写入到DB中。

　　优点：解决性能问题

　　缺点：没有解决超卖问题，同时由于异步写入DB，存在某一时刻DB和Redis中数据不一致的风险。

引入队列，然后将所有写DB操作在单队列中排队，完全串行处理。当达到库存阀值的时候就不在消费队列，并关闭购买功能。这就解决了超卖问题。

　　优点：解决超卖问题，略微提升性能。

　　缺点：性能受限于队列处理机处理性能和DB的写入性能中最短的那个，另外多商品同时抢购的时候需要准备多条队列。

　　**将提交操作变成两段式，先申请后确认。然后利用Redis的原子自增操作（相比较MySQL的自增来说没有空洞），同时利用Redis的事务特性来发号，保证拿到小于等于库存阀值的号的人都可以成功提交订单。**然后数据异步更新到DB中。

　　优点：解决超卖问题，库存读写都在内存中，故同时解决性能问题。

　　缺点：由于异步写入DB，可能存在数据不一致。另可能存在少买，也就是如果拿到号的人不真正下订单，可能库存减为0，但是订单数并没有达到库存阀值。

2. 数据库主从不一致，怎么解

数据库主库和从库不一致，常见有这么几种优化方案：

（1）业务可以接受，系统不优化

（2）强制读主，高可用主库，用缓存提高读性能

（3）在cache里记录哪些记录发生过写请求，来路由读主还是读从