MySQL高级-MVCC（超详细整理）

Posted Noblegasesgoo

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL高级-MVCC（超详细整理）相关的知识，希望对你有一定的参考价值。

什么是MVCC?

MVCC(multi-version-concurrent-control)

MVCC即多版本并发控制，MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

MVCC在MySQL InnoDB中的实现主要是为了提高数据库的并发性能，用更好的方式去处理读-写冲突，做到==即使有读写冲突时，也能做到不加锁，非阻塞并发读==。

什么是当前读和快照读

  • 当前读

就像 select lock in share mode（共享锁），select for update；update，insert，delete（排他锁）；这些操作都是一种当前读，为什么叫当前读？因为它读取的记录都是目前数据库中最新的版本，读取时还要保证其它并发事务不能修改当前记录，所以会对读取数据加锁。

  • 快照读

像不加锁的select操作就是快照读，即不加锁的非阻塞读，快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。

之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制(MVCC)。

所以我们可以认为MVCC是行锁的一个变种，但MVCC在很多情况下它避免了加锁，降低了开销，既然是基于多版本的，所以快照读不一定读到的就是最新版本的记录，而是可能为之前的历史版本。

当前读，快照读和MVCC的关系

  • 准确的说，MVCC多版本并发控制是指：“维持一个数据的多个版本，使得读写操作没有冲突”这么一个概念，听起来特别像我们JAVA中的那个写时复制，但这只是一个理想概念。
  • 而在MySQL中，实现这么一个MVCC理想概念，我们就需要MySQL提供具体的功能去实现它，而快照读就是MySQL为我们实现MVCC理想模型的其中一个具体非阻塞读功能不同的快照，可以看作不同的数据版本。而相对而言，当前读就是悲观锁的具体功能实现。
  • 要说得再细致一点，快照读本身也是一个抽象概念，再深入研究。MVCC模型在MySQL中的具体实现则是由四个隐式字段，undo日志，read view 等去完成的。

MVCC能解决什么问题？好处是什么？

数据库并发场景？

当前假设有三种，分别为：

  • 读-读：不存在任何问题，也不需要并发控制。
  • 读-写：有线程安全问题，会体现事务隔离性问题，也就是可能遇到，脏读，不可重复读，幻读等。
  • 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失，也会造成一些事务隔离性问题的出现。

MVCC带来的好处是？

**多版本并发控制（MVCC）**是一种用来解决 读-写 冲突的无所并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，也就是每个事务都有一个对应版本的快照，快照版本按照单向增长的时间戳来决定先后顺序。

在这样的情况下，读操作，我们只读该事务开始前的数据库快照，并不去读取正在修改的数据，我们读取事务开始前的最新版本。

所以解决了数据库在并发读取时的问题，即可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能，同时还可以解决脏读，不可重复读，幻读等事务隔离级别带来的问题。但不能解决更新丢失问题。

小结一下

总之，MVCC就是因为大牛们，不满意只让数据库采用悲观锁这些性能不佳的形式去解决读-写冲突问题，而提出的解决方案，所以在数据库中，因为有了MVCC，所以我们可以形成两个组合：

  • MVCC + 悲观锁 MVCC解决读写冲突，悲观锁解决写-写冲突。
  • MVCC + 乐观锁 MVCC解决读写冲突，乐观锁解决写-写冲突。

MVCC的实现原理

MVCC的目的就是多版本的并发控制，在数据库中的实现，就是为了解决读-写冲突的问题，它的实现原理主要是依赖记录中的 3个隐式字段、undo日志、read view 来实现的。

隐式字段

每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRXID, DB_ROLL, DB_ROW_ID等字段。

  • DB_ROW_ID：
    • 6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID生成一个聚簇索引。
  • DB_TRX_ID：
    • 6byte，最近修改（修改、插入）事务ID：记录创建这条记录以及最后一次修改该记录的事务的ID，是一个指针。
  • DB_ROLL_PTR：
    • 7byte，回滚指针，指向这条记录的上一个版本（上一个版本存储于，rollback segment里）。
  • DELETED_BIT：
    • 1byte，记录被更新或删除并不代表真的删除，而是删除flag变了，相当于记录一次逻辑删除。

就拿上图来解释这几个字段，DB_ROW_ID 是数据库默认为该行记录生成的唯一隐式主键；DB_TRX_ID 是当前操作该条记录的事务的ID；DB_ROLL_PTR 是一个回滚指针，用于配合 undo日志，指向该条记录的上一个版本；DELETED_FLAG 字段没有展示出来。

UNDO日志

InnoDB把这些为了回滚而记录的这些东西称之为 undo log。

值得注意的是，由于查询操作（SELECT）并不会修改任何用户记录，所以在查询操作时，并不需要记录相应的 undo log。

undo log 主要分为以下三种：

  • insert undo log：
    • 插入一条记录时，至少把这条记录的主键记录下来，之后回滚的时候只需要把主键对应的记录删除即可。
  • update undo log：
    • 修改一条记录时，至少要把修改这条记录前的旧值都记录下来，在回滚的时候再把这条记录的值更新为旧值就好了。
  • delete undo log：
    • 删除一条记录时，至少要把这条记录中的全部内容都记录下来，这样在之后回滚的时候再重新将这些内容组成的记录插入到表中就好了。
    • 删除操作都只是设置一下老记录的 DELETE_BIT，并不是真正将其删除，类似于数据库提供的专门的逻辑删除。
    • 为了节省磁盘空间，InnoDB有专门的 purge（清除）线程来清理 DELETED_BIT 为 true 的记录。
    • 为了不影响MVCC的正常工作，purge线程自己也维护了一个 read view（这个 read view 相当于当前系统中最老活跃的事务的 read view）。
    • 如果某个记录的 DELETED_BIT 为 true，并且 DB_TRX_ID（最后一个操作的事务ID） 相对于 purge线程的 read view 可见，那么这条记录一定是可以被安全清除的。

对 MVCC 有实质上帮助的是 update undo log，undo log 实际上就是存在于 rollback segment 中的旧纪录链。

说了这么多，云里雾里的，我们来看一个例子：

  1. 比如一个事务往 persion表 中插入了一条新纪录，记录如下，name = jerry，age = 24；

    隐式主键 = 1，事务ID和回滚指针都假设为 NULL；

  2. 现在来了另一个事务1对该记录的 name 做出了修改，改为 tom；

    1. 在该 事务1 修改该行记录数据的同时，数据库会先对该行加排他锁（InnoDB引擎会自动对DML语言影响的记录上写锁|独占锁）。
    2. 上锁完毕后，将该行数据拷贝到 undo log 中，作为旧记录，即在 undo log 中有当前行的拷贝副本。
    3. 拷贝完毕后，修改该行的 name 为 tom，并且修改隐藏字段的 事务ID 为当前 事务1的ID，这里我们默认是从1开始递增，回滚指针指向拷贝到 undo log 的副本记录，即表示我的上一个版本就是他。
    4. 事务提交后，释放锁。

  1. 又来了一个事务2修改persion表的同一个记录，将 age 修改为 30岁；

    1. 在事务2修改该行数据之前，数据库继续给他上排他锁。
    2. 上锁完毕之后，把该行数据拷贝到 undo log 中，作为旧记录，发现操作的这行记录已经有undo log 的记录了，那么最新的旧数据作为链表的表头，插在这行记录的 undo log 日志的最前面。
    3. 修改该行age为30岁，并且修改隐藏字段的事务ID为当前事务2的ID，那就是2，回滚指针指向刚刚拷贝到 undo log 的副本记录。
    4. 事务提交，释放锁。

从上面几个例子可以看出，不同事物或者相同事务对同一个记录的修改，会导致该记录的 undo log 成为一条版本记录链。undo log 的链首就是最新的旧记录，尾部就是最旧的记录（当然，就像之前所说的该 undo log 的节点可能是会被 purge线程 清除掉的，像图中的第一条 insert undo log， 其实在事务提交之后可能就被删除丢失了，不过这里为了演示所以还放在这里，假设没被清除）。

Read View（读视图）

什么是 Read View？说白了 Read View 就是==事务进行快照读操作的时候生产的读视图==，在当前事务执行快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID（当每个事务开启时，都会被分配一个ID，这个ID是默认递增的，所以事务越新，ID越大）。

所以我们可以知道 Read View 主要是用来做==可见性判断==的，即当我们某个事物执行快照读的时候，对读取的该记录创建一个 Read View 视图，把它当作条件，用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据（也就是该快照），也可能是该行记录的 undo log 日志里的某个版本的数据。

Read View 遵循一个可见性算法：

事务ID查询就不会新增，只有DML语言才会导致事务ID增加。

主要是将被修改的数据的最新记录中的 DB_TRX_ID（当前事务ID）取出来，与系统当前其它活跃事务的ID去对比（由 Read View 维护），如果 DB_TRX_ID 跟 Read View 的属性做了某些比较之后不符合可见性，那就通过 DB_ROLL_PRT 回滚指针去取出 undo log 中的 DB_TRX_ID 再比较，也就是说遍历 undo log 链表的 DB_TRX_ID 找到特定条件的事务ID的版本，那么这个 DB_TRX_ID 所在的旧记录就是当前事务能看见的最新老版本。

那么这个判断条件是什么呢？

如上，他是一段 mysql 判断可见性的一段源码。即 changes_visible 方法（不完全，但是能看出大致逻辑），该方法展示了我们拿 DB_TRX_ID 去跟 Read View 某些属性进行怎么样的比较。

在介绍前，我们先简化一下 Read View ，我们可以把 Read View 简单的理解成有三个全局属性：

  • trx_list：未提交事务 ID 列表，用来维护 Read View 生成时刻系统正处于活跃状态的事务ID。
  • up_limit_id：记录 trx_list 事务ID列表中 最小的ID，也就是最初修改该记录的事务。
  • low_limit_id：Read View 生成时刻系统尚未分配的下一个事务ID，也就是等于**目前出现过的最大事务ID + 1**。

方法大致流程（对比上面代码）：

  • 首先判断 DB_TRX_ID < up_limit_id ：

    • 大于：进入下一个判断。
    • 小于：则当前事务能看到 DB_TRX_ID 所在记录。

  • 判断 DB_TRX_ID >= low_limit_id：

    • 大于：代表 DB_TRX_ID 所在的记录是在 Read View 生成之后才出现的，那对当前事务肯定不可见。
    • 小于：进入下一个判断。

  • 判断 DB_TRX_ID 是否在活跃事务中 trx_list.contains(DB_TRX_ID)：

    • 在：代表 Read View 生成的时候，你这个事务还在活跃状态，并没有 commit，你修改的数据，我当前的事务是看不见的（RR隔离级别）。
    • 不在：说明你这个事务在 Read View 生成之前就已经 commit 了，你修改的结果，我当前事务是看得见的。

  • 可以这样理解 Read View ：不应该让当前事务看到的记录版本，这些记录版本对应的事务ID都在Read View 中。

以 Repeatable Read （RR隔离级别）举个例子吧，要求读一个值，一直读都是同一个值：

  • 这种隔离级别下，开启事务的时候开启一个 Read View ，在当前事务执行的整个过程中都用这个 Read View。
  • 当前 事务ID = 10，ReadView 就是（4，8, 10），因为当前事务10正在执行，所以自己也活跃，此时 up_limit_id=4，low_limit_id=11。
  • 如果 **当前事务10 **读到一个数据的 事务ID = 1，小于 活跃列表的最小值（up_limit_id=4），可见。
  • 为什么？
    • 因为在 事务10 开启的时候生成的 Read View ，除了4，8，10，其他事务都已经提交了（不处于活跃状态了），所以事务1的版本 < 事务4的版本，以及5、6、7、9，都是肯定在我开启的时候已经提交了（事务ID单调递增）。
    • 所以这些版本的的数据，再怎么读都不会变，可以放心的读。
  • 但如果我读到一个数据的 事务ID = 12，说明他在我创建 Read View 之后提交的，我不应该看见这个值，应该去 undo log 里找这个数据的前面的版本，如果找到 事务ID < 4的版本，或者 事务ID = (5、6、7、9)的版本 都是安全的，可以读。
  • 如果我读到一个数据 事务ID在活跃列表的范围内：
    • 如果当前事务就是活跃的事务之一，比如说是8，说明这个数据在我开启事务之后，才被其它活跃事务更改（提交或未提交），那么这个我不能看见，应该去 undo log 中找上一个版本来读，假设说是 7，7也是在这个活跃范围里，但是并不是活跃事务之一，这个版本是在当前事务开启事务之前由事务7提交的，所以这个版本可见。

再举个读已提交的例子：

  • 在这个隔离级别是每次读都采用新的 Read View。
  • 事务10 开启。
  • 读一个数据，事务ID = 9，假设此时Read View 中 活跃事务ID =（4，8，10），按照规则，可见。
  • 过一会再读这个数据，发现此时 事务ID = 11，而此时活跃事务ID =（4，8，10），但是因为开启了新的 Read View，当前系统最大事务ID >11(因为我们已经读到11了嘛)，根据判断规则，事务11不在活跃ID列表并且 （事务11ID = 11） < (low_limit_id = 12)，所以可见。这回就读到了这个数据的新版本了。

整体流程

说了这么多，我们在了解了 隐式字段、undo log、Read View 的概念之后。就可以来康康 MVCC 的具体实现流程大致是什么样的了。

我们可以模拟一下：

当 事务2 对某行数据执行了快照读，数据库为该行数据生成一个 Read View （读视图），假设当前事务ID为2，此时还有事务1和事务3在活跃状态中，事务4在事务2快照读前一刻提交了更新，所以 Read View 记录了系统当前活跃事务1，3的ID，维护在一个列表上，假设我们称这个列表为 trx_list:

事务1事务2事务3事务4
事务开始事务开始事务开始事务开始
………修改且已提交
进行中快照读进行中
………

ReadView 不仅仅会通过一个列表 trx_list 来维护事务2执行快照读那刻系统中正在活跃的事务ID，还会有两个属性 up_limit_id，low_limit_id；所以在这里的例子中，up_limit_id = 1, low_limit_id = 4+1 = 5，trx_list集合的值是1，3，Read View 如下图。

我们的例子中，只有事务4修改过该行记录，并在事务2 执行快照读前，就提交了事务。

所以，当前该行数据的 undo log 就如下图所示。

我们的事务2，在快照读该行记录的时候，就会拿该行记录的 DB_TRX_ID 去和 up_limit_id，low_limit_id 和 trx_list（活跃事务ID列表）进行比较，判断当前事务2能看到的记录是哪个版本。

MVCC相关的问题

RR是如何在RC级的基础上解决不可重复读的？

当前读和快照读在 RR级别 下的区别：

事务A事务B
开启事务开启事务
快照读（无影响）查询金额为500快照读（无影响）查询金额为500
更新金额为400—
commit—
—select 快照读 金额为500
—select lock in share mode 当前读 金额为400
事务A事务B
开启事务开启事务
快照读（无影响）查询金额为500—
更新金额为400—
commit—
—select 快照读 金额为400
—select lock in share mode 当前读 金额为400

在第二个表中，为什么事务B在事务A的提交后，快照读和当前读都是400呢？

这里与第一个表的唯一区别仅仅是表一的事务A修改金额前快照读过一次金额数据，而表二的事务B在事务A提交前并没进行过快照读。

所以我们知道，事务中快照读的结果非常依赖事务首次出现快照读的地方，即某个事务中首次出现快照读的地方十分的关键，它可以决定该事务后续快照读结果的能力。

我们这里测试的是更新，同时删除和更新也是一样的，如果事务B的快照读是在事务A操作之后进行的，事务B的快照读也是能读取到最新的数据的。

RC,RR级别下的InnoDB快照读有什么不同？

正式因为 Read View 的生成时间不同。

  • 在 RR 级别下的某个事务对某条记录的第一次快照读会创建一个快照以及 Read View，记录当前系统中活跃的其它事务，此后在调用快照读的时候，还是用的同一个 Read View，所以只要当前事务在其它事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个 Read View，所以对之后的修改不可见。
    • 即 RR 级别下，快照读生成 Read View 时，Read View 会记录所有当前其它所有活跃事务的快照，这些食物的修改对于当前事务都是不可见的，而早于 Read View 创建的事务所作的修改均可见。
  • 在 RC 级别下，事务中，每次快照都都会生成一个新的 Read View 和最新快照，这就是我们在 RC级别下的事务中可以看到别的事务提交更新的原因。

反正总而言之就是 RC 隔离级别 下，每个快照读都会生成新的 Read View 以及快照，而在 RR隔离级 别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。

github仓库同步笔记，可自取欢迎各位star指正，邀请各位一起来完善:https://github.com/Noblegasesgoo/CS-Java-Notes

参考文章与部分图片来源：https://www.pdai.tech/md/db/sql-mysql/sql-mysql-mvcc.html 由本人二次整理。
如果出错希望评论区大佬互相讨论指正，维护社区健康大家一起出一份力，不能有容忍错误知识。
										—————————————————————— 爱你们的 noblegasesgoo

Java面试题超详细整理《MySQL篇》

MySQL 介绍

MySQL 是一种关系型数据库，主要用于持久化存储我们的系统中的一些数据比如用户信息。

MySQL 是开源软件，使用时无需付费，并且他还是比较成熟的数据库，被大量使用在各种系统中。MySQL 的默认端口号是3306。

获取当前的Mysql 版本： SELECT VERSION();

MySQL由哪些部分组成, 分别用来做什么

  • Server
    连接器： 管理连接，权限验证
    分析器： 词法分析，语法分析
    优化器： 执行计划生成，索引的选择
    执行器： 操作存储引擎，返回执行结果
  • 存储引擎： 存储数据，提供读写接口

MySQL中的执行引擎

常用的存储引擎有以下：

  • Innodb引擎：Innodb引擎提供了对数据库ACID事务的支持。并且还提供了行级锁和外键的约束。它的设计的目标就是处理大数据容量的数据库系统。
  • MyIASM引擎(原本Mysql的默认引擎)：不提供事务的支持，也不支持行级锁和外键。
  • MEMORY引擎：所有的数据都在内存中，数据的处理速度快，但是安全性不高。

MyISAM与InnoDB区别：

MyISAMInnodb
是否支持事务不支持事务， 但是每次查询都是原子的支持 ACID 的事务， 支持事务的四种隔离级别
锁支持支持表级锁定支持行级锁定、表级锁定，锁定力度小并发能力高
是否支持外键不支持外键支持外键
存储结构每张表被存放在三个文件：索引文件MYI、数据文件MYD、frm表结构文件所有的表都保存在同一个数据文件中（也可以是多个），InnoDB表的大小只受限于操作系统文件的大小，一般为2GB
存储空间MyISAM可被压缩，存储空间较小InnoDB的表需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引
文件格式数据和索引是分别存储的，数据.MYD，索引.MYI数据和索引是集中存储的，.ibd
可移植性、备份及恢复跨平台的数据转移中会很方，在备份和恢复时可单独针对某个表进行操作可以拷贝数据文件、备份 binlog，或者用 mysqldump，在数据量达到几十G的时候就相对痛苦了
记录存储顺序按记录插入顺序保存按主键大小有序插入
哈希索引不支持支持
全文索引支持不支持(但可以使用Sphinx插件)

大多数时候我们使用的都是 InnoDB 存储引擎，在某些读密集的情况下，使用 MyISAM 也是合适的。不过，前提是你的项目不介意 MyISAM 不支持事务、崩溃恢复等缺点。
MyISAM：以读写插入为主的应用程序，比如博客系统、新闻门户网站。
Innodb：更新（删除）操作频率也高，或者要保证数据的完整性；并发量高，支持事务和外键。比如OA自动化办公系统。

MySQL中字段类型CHAR 和 VARCHAR 的区别？

charvarchar
长度长度固定（1-255）长度可变
长度不足时插入的长度小于定义长度时，则用空格填充，检索 CHAR 值时需删除尾随空格小于定义长度时，按实际插入长度存储
性能存取速度比varchar快得多存取速度比char慢得多
使用场景适合存储很短的，固定长度的字符串，如手机号，MD5值等适合用在长度不固定场景，如收货地址，邮箱地址等

MySQL中字段类型DATETIME 和 TIMESTA的区别？

类型占据字节范围时区问题
datetime8 字节1000-01-01 00:00:00到 9999-12-31 23:59:59存储与时区无关，不会发生改变
timestamp4 字节1970-01-01 00:00:01到 2038-01-19 11:14:07

如果一个表有一列定义为 TIMESTAMP ，每当行被更改时，时间戳字段将获取当前时间戳。

数据库三大范式

  • 第一范式： 属性不可再分
  • 第二范式： 在一范式的基础上，消除了部份依赖，属性完全依赖于主键
  • 第三范式： 在二范式的基础上，消除了传递依赖，属性不依赖于其它非主属性 属性直接依赖于主键

数据库中的事务是什么?事务的特性？

事务（ transaction） 是一组有序的数据库操作。如果组中的所有操作都成功， 则认为事务成功，提交事务。 如果一个操作失败， 则事务将回滚， 该事务所有操作的影响都将取消。（事务是逻辑上的一组操作，要么都执行，要么都不执行）

事务的特性：ACID

  • 原子性（Atomicity） ： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
  • 一致性（Consistency）： 执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；
  • 隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
  • 持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
# 开启一个事务
START TRANSACTION;
# 多条 SQL 语句
SQL1,SQL2...
## 提交事务
COMMIT;

ACID靠什么来保证？

  • 原子性：MySQL InnoDB 引擎使用 undo log(回滚日志) 来保证事务的原子性，记录了需要回滚的日志信息，事务回滚时撤销已经执行成功的sql
  • 一致性：保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。
  • 隔离性：MySQL InnoDB 引擎通过锁机制、MVCC 等手段来保证事务的隔离性（ 默认支持的隔离级别是 REPEATABLE-READ ）。
  • 持久性：使用 redo log(重做日志) 保证事务的持久性，mysql修改数据的同时在内存和redo log记录这次操作，宕机的时候可以redo log恢复。redo log的刷盘会在系统空闲时进行。

InnoDB redo log写盘，InnoDB事务进入prepare状态。如果前面的prepare成功，binlog写盘，在继续将事务日志持久化到binlog中，如果持久化成功，那么InnoDB事务则进入commit状态（在redo log里面写一个commit记录）

什么是MVCC

多版本并发控制：读取数据时通过一种类似快照的方式将数据保存下来，这样读锁就和写锁不冲突了，不同的事务session会看到自己特定版本的数据,版本链

MVCC只在 READ COMMITTED（读已提交）和 REPEATABLE READ（可重复读）两个隔离级别下工作。其他两个隔离级别够和MVCC不兼容，因为 READ UNCOMMITTED（读未提交）总是读取最新的数据行，而不是符合当前事务版本的数据行。而 SERIALIZABLE（串行化）则会对所有读取的行都加锁。

聚簇索引记录中有两个必要的隐藏列:
trx_id：用来存储每次对某条聚簇索引记录进行修改的时候的事务id
roll_pointer：每次对哪条聚簇索引记录有修改的时候,都会把老版本写入undo日志中。这个ro‖_pointer就是存了一个指针，它指向这条聚簇索引记录的上一个版本的位置，通过它来获得上一个版本的记录信息。(注意插入操作的undo日志没有这个属性，因为它没有老版本)

Mysql的MVCC通过版本链，实现多版本，可并发读写，写读。通过 Readview生成策略的不同实现不同的隔离级别：

  • 始事务时创建 readview， readview维护当前活动的事务id，即未提交的事务id，排序生成一个数组。
  • 访问数据获取数据中的事务id（获取的是事务id最大的记录），对比 readview如果在 readview的左边（比 readview都小），可以访问（在左边意味着该事务已经提交）
  • 如果在 readview的右边（比 readview都大）或者就在 readview中，不可以访问，获取 roll_ pointer，取上一版本重新对比（在右边意味着，该事务在 readview生成之后出现，在 readview中意味着该事务还未提交）
  • 已提交读和可重复读的区别就在于它们生成 Readview的策略不同：
    已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的 Readview，而可重复读隔离级别则在第一次读的候生成一个 Readview，之后的读都复用之前的 Readview

mysql主从同步原理

MySQL的主从复制中主要有三个线程： master (binlog dump thread)，slave( I/O thread、SQL thread)， Master-条线程和Save中的两条线程。

  • 主节点binlog：主从复制的基础是主库记录数据库的所有变更记录到binlog。 binlog是数据库服务器启动的那一刻起，保存所有修改数据库结构或内容的一个文件。
  • 主节点 log dump线程，当 binlog有变动时， log dump线程读取其内容并发送给从节点。
  • 从节点I/O线程接收 binlog内容，并将其写入到 relay log文件中。
  • 从节点的SQL线程读取 relay log文件内容对数据更新进行重放，最终保证主从数据库的一致性

由于mysql默认的复制方式是异步的，主库把日志发送给从库后不关心从库是否已经处理，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念：

  • 全同步复制：主库写入 binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响
  • 半同步复制：和全同步不同的是，半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成

并发事务带来哪些问题?

  • 脏读（Dirty read）：某个事务对数据进行修改时，另外一个事务读取了这个数据。因为这个数据是还没有提交的数据（可能会发生回滚），那么另外一个事务读到的这个数据是“脏数据”。
  • 不可重复读（Unrepeatable read）：某个事务内多次读同一数据，数据不一致。可能在该事务多次读取数据期间，某一个事务修改了数据。（修改操作）
  • 幻读（Phantom read）： 某个事务内多次读同一种数据，数据行数不一致。可能在该事务多次读取数据期间，某一个事务插入了数据，导致出现了本不该出现的数据。（插入删除操作）
  • 丢失修改（Lost to modify）: 某个事务读取一个数据，并对数据进行修改，期间另外一个事务也访问了该数据，并对数据进行修改。导致第一个事务进行修改的的操作没有成功，因此称为丢失修改。 例如：事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 也修改 A=A-1，最终结果 A=19，事务 1 的修改被丢失。

四种事务隔离级别

  • READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
  • READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
  • REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
  • SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。我们可以通过SELECT @@transaction_isolation;查看

什么是索引？索引的基本原理

索引是一种用于快速查询和检索数据的数据结构。常见的索引结构有: B 树， B+树和 Hash。

索引的作用就相当于目录的作用。其本身是一种特殊的文件，它们包含着对数据表里所有记录的引用指针。会占据一定的物理空间。

索引的优缺点：

  • 优点 ：使用索引可以大大加快数据的检索速度（大大减少检索的数据量）
  • 缺点 ：创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低 SQL 执行效率。另外，索引需要使用物理文件存储，也会耗费一定空间。

索引的原理：把无序的数据变成有序的查询

  • 把创建了索引的列的内容进行排序
  • 对排序结果生成倒排表
  • 在倒排表内容上拼上数据地址链
  • 在查询的时候，先拿到倒排表的内容，再取出数据地址链，从而拿到具体数据

使用索引一定能提高查询性能吗?
大多数情况下，索引查询都是比全表扫描要快的。但是如果数据库的数据量不大，那么使用索引也不一定能够带来很大提升。

索引类型

  • 普通索引(Index) ：用来快速查询数据，一张表允许创建多个普通索引，并允许数据重复和 NULL。
  • 唯一索引(Unique Key) ：可以保证数据记录的唯一性，允许数据为 NULL，一张表允许创建多个唯一索引。 建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性，而不是为了查询效率。
  • 主键索引(Primary Key)：数据表的主键列使用的就是主键索引。是一种特殊的唯一索引，一张数据表有只能有一个主键，并且主键不能为 null，不能重复。
  • 前缀索引(Prefix) ：前缀索引只适用于字符串类型的数据。前缀索引是对文本的前几个字符创建索引，相比普通索引建立的数据更小， 因为只取前几个字符。（前缀的标识度高。比如密码就适合建立前缀索引，因为密码几乎各不相同）
  • 全文索引(Full Text) ：全文索引主要是为了检索大文本数据中的关键字的信息，通过建立倒排索引，可以极大提升索引效率，解决判断字段是否包含问题，是目前搜索引擎使用的关键技术。

唯一索引比普通索引快吗，为什么?
对于写多读少的情况， 普通索引利用 change buffer 有效减少了对磁盘的访问次数，而唯一索引需要校验唯一性，此时普通索引性能要高于唯一索引

MySQL 如何为表字段添加索引？

添加 PRIMARY KEY（主键索引）
ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )

添加 UNIQUE(唯一索引)
ALTER TABLE `table_name` ADD UNIQUE ( `column` )

添加 INDEX(普通索引)
ALTER TABLE `table_name` ADD INDEX index_name ( `column` )

添加 FULLTEXT(全文索引)
ALTER TABLE `table_name` ADD FULLTEXT ( `column`)

添加多列索引
ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

select count(*)/count(distinct left(password,prefixLen));
通过从调整prefixLen的值（从1自增）查看不同前缀长度的一个平均匹配度，接近1时就可以了（表示一个密码的前prefixLen个字符几乎能确定唯一一条记录）

在 MySQL 的 InnoDB 的表中，当没有显示的指定表的主键时，InnoDB 会自动先检查表中是否有唯一索引的字段，如果有，则选择该字段为默认的主键，否则 InnoDB 将会自动创建一个 6Byte 的自增主键。

二级索引(辅助索引)：
二级索引又称为辅助索引，是因为二级索引的叶子节点存储的数据是主键。也就是说，通过二级索引，可以定位主键的位置。唯一索引，普通索引，前缀索引等索引属于二级索引。

二级索引属于非聚簇索引

聚集索引与非聚集索引

两者都是B+树的数据结构，依赖于有序的数据。

聚集索引：聚集索引即索引结构和数据一起存放，并按一定的顺序进行排序的索引，找到了索引进找到了数据。
主键索引属于聚集索引。
优点：
聚集索引的范围查询速度非常的快，因为整个 B+树本身就是一颗多叉平衡树，叶子节点也都是有序的，定位到索引的节点，就相当于定位到了数据。
缺点：

  • 依赖于有序的数据 ：因为 B+树是多路平衡树，如果索引的数据不是有序的，那么就需要在插入时排序，如果数据是整型还好，否则类似于字符串或 UUID 这种又长又难比较的数据，插入或查找的速度肯定比较慢。
  • 更新代价大 ： 如果对索引列的数据被修改时，那么对应的索引也将会被修改， 而且况聚集索引的叶子节点还存放着数据，修改代价肯定是较大的， 所以对于主键索引来说，主键一般都是不可被修改的。

非聚集索引：非聚集索引即索引结构和数据分开存放的索引。非聚集索引的叶子节点并不存放数据，存储的数据行地址，根据数据行地址再回表查数据。
优点：
更新代价比聚集索引要小 。非聚集索引的更新代价就没有聚集索引那么大了，非聚集索引的叶子节点是不存放数据的
缺点：

  • 跟聚集索引一样，非聚集索引也依赖于有序的数据
  • 可能会二次查询(回表) ：这应该是非聚集索引最大的缺点了。 当查到索引对应的指针或主键后，可能还需要根据指针或主键再到数据文件或表中查询。

MyISAM：采用非聚集索引， 索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致， 但是辅索引不用保证唯一性。
InnoDB：主键索引采用聚集索引（ 索引的数据域存储数据文件本身）， 辅助索引的数据域存储主键的值； 因此从辅助索引查找数据， 需要先通过辅助索引找到主键值， 再访问辅助索引； 最好使用自增主键， 防止插入数据时， 为维持 B+树结构， 文件的大调整。

创建索引的一些原则

适合索引：频繁查询、范围查询、排序、连接的字段
不适合索引：基数较小、频繁更新、重复值多的、字段为NULL的字段

选择合适的字段创建索引：

  • 被频繁查询的字段 ：我们创建索引的字段应该是查询操作非常频繁的字段。
  • 被作为条件查询的字段 ：被作为 WHERE 条件查询的字段，应该被考虑建立索引。(避免在查询条件中对字段施加函数，这会造成无法命中索引)
  • 频繁需要排序的字段 ：索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。
  • 被经常频繁用于连接的字段 ：经常用于连接的字段可能是一些外键列，对于外键列并不一定要建立外键，只是说该列涉及到表与表的关系。对于频繁被连接查询的字段，可以考虑建立索引，提高多表连接查询的效率。

被频繁更新的字段应该慎重建立索引：虽然索引能带来查询上的效率，但是维护索引的成本也是不小的。 如果一个字段不被经常查询，反而被经常修改，那么就更不应该在这种字段上建立索引了。

取值离散大的字段的列放到联合索引的前面，可以通过count()函数查看字段的差异值，返回值越大说明字段的唯一值越多字段的离散程度高；比如性别就不适合做索引。

索引不为 NULL 的字段 ：索引字段的数据应该尽量不为 NULL，因为对于数据为 NULL 的字段，数据库较难优化。如果字段频繁被查询，但又避免不了为 NULL，建议使用 0,1,true,false 这样语义较为清晰的短值或短字符作为替代。

索引字段越小越好：数据库的数据存储以页为单位一页存储的数据越多一次IO操作获取的数据越大效率越高。

考虑在字符串类型的字段上使用前缀索引代替普通索引。前缀索引仅限于字符串类型，较普通索引会占用更小的空间，所以可以考虑使用前缀索引带替普通索引。

尽可能的考虑建立联合索引而不是单列索引：因为索引是需要占用磁盘空间的，可以简单理解为每个索引都对应着一颗 B+树。如果一个表的字段过多，索引过多，那么当这个表的数据达到一个体量后，索引占用的空间也是很多的，且修改索引时，耗费的时间也是较多的。如果是联合索引，多个字段在一个索引上，那么将会节约很大磁盘空间，且修改数据的操作效率也会提升。

注意避免冗余索引 ：冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如（name,city ）和（name ）这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者的在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。

一些建议：

  • 对于中到大型表索引都是非常有效的，但是特大型表的话维护开销会很大，不适合建索引。
  • 在使用 InnoDB 时使用与业务无关的自增主键作为主键，即使用逻辑主键，而不要使用业务主键。
  • 删除长期未使用的索引，不用的索引的存在会造成不必要的性能损耗
  • 在使用 limit offset 查询缓慢时，可以借助索引来提高性能

索引失效的原因可能是什么？

索引失效这个问题的前提应该是建立了索引，却没有使用到，或者没有完全使用到，下面列举了一些常见原因，面试中可能也会闻到。

  • 原因一：复合索引没有遵守最左前缀原则，复合索引必须遵守最左前缀，也就是按照复合索引创建的顺序，左边的列必须按顺序出现。
  • 原因二：在索引列上做了任何操作（计算、函数、类型转换）
  • 原因三：出现范围条件，往后全部失效
  • 原因四：没有充分利用覆盖索引
  • 原因五：使用了不等于（!= 或者 <>） 作为条件

完整性约束包括哪些？

约束：保证数据的完整性而实现的摘自一套机制，即(约束是针对表中数据记录的)

数据完整性(Data Integrity)是指数据的精确(Accuracy)和可靠性(Reliability)。分为以下四类：

  • 实体完整性： 规定表的每一行在表中是惟一的实体。
  • 域完整性：是指表中的列必须满足某种特定的数据类型约束，其中约束又包括 取值范围、精度等
    规定。
  • 参照完整性： 是指两个表的主关键字和外关键字的数据应一致，保证了表之间的数据的一致性，
    防止了数据丢失或无意义的数据在数据库中扩散。
  • 用户定义的完整性：不同的关系数据库系统根据其应用环境的不同，往往还需 要一些特殊的约束
    条件。用户定义的完整性即是针对某个特定关系数据库的约束条件， 它反映某一具体应用必须满足的语
    义要求。

与表有关的约束：

  • 非空约束：NOT NULL 保证某列数据不能存储NULL 值;
  • 唯一约束：UNIQUE(字段名) 保证所约束的字段，数据必须是唯一的，允许数据是空值(Null)，但只允许有一个空值(Null)；
  • 主键约束：PRIMARY KEY(字段名) 主键约束= 非空约束 + 唯一约束 保证某列数据不能为空且唯一；
  • 外键约束：FOREIGN KEY(字段名) 保证一个表中某个字段的数据匹配另一个表中的某个字段，可以建立表与表直接的联系；
  • 自增约束：AUTO_INCREMENT 保证表中新插入数据时，某个字段数据可以依次递增；
  • 默认约束：DEFALUT 保证表中新插入数据时，如果某个字段未被赋值，则会有默认初始化值；
  • 检查性约束：CHECK 保证列中的数据必须符合指定的条件；

B树和B+树的区别

B 树& B+树两者有何异同呢？

  • B 树也称 B-树，全称为多路平衡查找树 ，在B树中，所有节点既存放键(key) 也存放数据(data)，叶子节点各自独立。
  • B+树是B树的一种变体，内部节点都是键(key)，没有值，叶子节点同时存放键(key)和值(value)。而且所有的叶子结点中增加了指向下一个叶子节点的指针， 因此 InnoDB 建议为大部分表使用默认自增的主键作为主索引。

使用B树的好处：
B树可以在内部节点同时存储键和值，因此，把频繁访问的数据放在靠近根节点的地方将会大大提高热点数据的查询效率。这种特性使得B树在特定数据重复多次查询的场景中更加高效。

使用B+树的好处：
由于B+树的内部节点只存放键，不存放值，因此，一次读取，可以在内存页中获取更多的键，有利于更快地缩小查找范围。 B+树的叶节点由一条链相连，因此，当需要进行一次全数据遍历的时候，B+树只需要使用O(logN)时间找到最小的一个节点，然后通过链进行O(N)的顺序遍历即可（检索效率很稳定）。而B树则需要对树的每一层进行遍历(当于对范围内的每个节点的关键字做二分查找)，这会需要更多的内存置换次数，因此也就需要花费更多的时间

数据库为什么使用B+树而不是B树？

  • B树只适合随机检索，而B+树同时支持随机检索和顺序检索；
  • B+树空间利用率更高，可减少I/O次数，磁盘读写代价更低。B+树的内部结点并没有指向关键字具体信息的指针，只是作为索引使用，其内部结点比B树小，盘块能容纳的结点中关键字数量更多，一次性读入内存中可以查找的关键字也就越多，相对的，IO读写次数也就降低了。
  • B+树的查询效率更加稳定，B树搜索有可能会在非叶子结点结束，越靠近根节点的记录查找时间越短，只要找到关键字即可确定记录的存在，其性能等价于在关键字全集内做一次二分查找。而在B+树中，顺序检索比较明显，随机检索时，任何关键字的查找都必须走一条从根节点到叶节点的路，所有关键字的查找路径长度相同，导致每一个关键字的查询效率相当。
  • B-树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。B+树的叶子节点使用指针顺序连接在一起，只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作。
  • 增删文件（节点）时，效率更高。因为B+树的叶子节点包含所有关键字，并以有序的链表结构存储，这样可很好提高增删效率。

在 MySQL 中，MyISAM 引擎和 InnoDB 引擎都是使用 B+Tree 作为索引结构，但是，两者的实现方式不太一样。

MyISAM 引擎中，B+Tree 叶节点的 data 域存放的是数据记录的地址。在索引检索的时候，首先按照 B+Tree 搜索算法搜索索引，如果指定的 Key 存在，则取出其 data 域的值，然后以 data 域的值为地址读取相应的数据记录。这被称为“非聚簇索引”。

InnoDB 引擎中，其数据文件本身就是索引文件。相比 MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按 B+Tree 组织的一个索引结构，树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。这被称为“聚簇索引（或聚集索引）”，而其余的索引都作为辅助索引，辅助索引的 data 域存储相应记录主键的值而不是地址，这也是和 MyISAM 不同的地方。在根据主索引搜索时，直接找到 key 所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，在走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。

Hash索引与B+树?

在大多数情况下，直接选择B+树索引可以获得稳定且较好的查询速度。而不需要使用hash索引。

  • hash索引底层就是hash表，进行查找时，调用一次hash函数就可以获取到相应的键值，之后进行回表查询获得实际数据。B+树底层实现是多路平衡查找树。对于每一次的查询都是从根节点出发，查找到叶子节点方可以获得所查键值，然后根据查询判断是否需要回表查询数据。
  • hash索引进行等值查询更快(一般情况下)，但是却无法进行范围查询。因为在hash索引中经过hash函数建立索引之后，索引的顺序与原顺序无法保持一致，不能支持范围查询。而B+树的的所有节点皆遵循(左节点小于父节点，右节点大于父节点，多叉树也类似)，支持范围查询。
  • hash索引任何时候都避免不了回表查询数据，而B+树在符合某些条件(聚簇索引，覆盖索引等)的时候可以只通过索引完成查询。
  • hash索引虽然在等值查询上较快，但是不稳定。性能不可预测，当某个键值存在大量重复的时候，发生hash碰撞，此时效率可能极差。而B+树的查询效率比较稳定，对于所有的查询都是从根节点到叶子节点，且树的高度较低。

什么是最左前缀匹配原则？

最左前缀匹配原则：最左优先，在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。

mysql会一直从左向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式

MySQL锁的类型

按照锁的粒度把数据库锁分为行级锁、表级锁和页级锁

  • 行级锁：行级锁是MySQL中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁和排他锁。
    特点：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
  • 表级锁：表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。
    特点：开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。
  • 页级锁：页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。
    特点：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

基于锁状态分类：共享锁、排它锁

  • 共享锁( Share Lock) 又称读锁，简称S锁；当一个事务为数据加上读锁之后，其他事务只能对该数据加读锁，而不能对数据加写锁。直到所有的读锁释放之后其他事务才能对其进行加持写锁，共享锁的特性主要是为了支持并发的读取数据，读取数据的时候不支持修改，避免出现重复读的问题
  • 排他锁( exclusive Lock) 又称写锁，简称X锁；当一个事务为数据加上写锁时，其他请求将不能再为数据加任何锁，直到该锁释放之后， 其他事务才能对数据进行加锁，排他锁的目的是在数据修改时候，不允许其他人同时修改，也不允许其他人读取，避免了出现脏数据和脏读的问题

锁的优化策略：
读写分离、分段加锁、减少锁持有的时间

InnoDB 存储引擎的锁的算法

  • Record lock：记录锁（行锁），单条索引记录上加锁，锁住的永远是索引，而非记录本身。
  • Gap lock：间隙锁，在索引记录之间的间隙中加锁（锁定一个范围），并不包括该索引记录本身。
  • Next-key lock：临键锁，Record lock 和 Gap lock 的结合，即除了锁住记录本身，也锁住索引之间的间隙（一个范围）。

InnoDB 中的行锁的实现依赖于索引，一旦某个加锁操作没有使用到索引，那么该锁就会退化为表锁。记录锁存在于包括主键索引在内的唯一索引中，锁定单条索引记录。

间隙锁存在于非唯一索引中，锁定开区间范围内的一段间隔，它是基于临键锁实现的。在索引记录之间的间隙中加锁，或者是在某一条索引记录之前或者之后加锁，并不包括该索引记录本身。

临键锁存在于非唯一索引中，该类型的每条记录的索引上都存在这种锁，它是一种特殊的间隙锁，锁定一段左开右闭的索引区间。即，除了锁住记录本身，也锁住索引之间的间隙。

MySQL怎么恢复一个月前的数据？

通过整库备份+binlog进行恢复. 前提是要有定期整库备份且保存了binlog日志

千万条数据的表, 如何分页查询？

数据量过大的情况下，limit offset 分页会由于扫描数据太多而越往后查询越慢。 可以配合当前页最后一条ID进行查询， SELECT * FROM T WHERE id > #ID LIMIT #LIMIT 。 当然， 这种情况下ID必须是有序的， 这也是有序ID的好处之一。

一天万条以上的增量， 预计运维三年，怎么优化？

  • 设计良好的数据库结构， 允许部分数据冗余， 尽量避免 join 查询， 提高效率。
  • 选择合适的表字段数据类型和存储引擎， 适当的添加索引。
  • MySQL 库主从读写分离。
  • 找规律分表， 减少单表中的数据量提高查询速度。
  • 添加缓存机制， 比如 memcached， apc
    等。
  • 不经常改动的页面， 生成静态页面。
  • 书写高效率的 SQL。比如 SELECT * FROM TABEL 改为 SELECT field_1, field_2, field_3 FROM TABLE

慢查询如何优化？

慢查询的优化首先要搞明白慢的原因是什么?是查询条件没有命中索引?是load了不需要的数据列?还是数据量

所以优化也是针对这三个方向来的：

  • 首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。
  • 分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改素引，使得语句可以尽可能的命中索引。
  • 如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表

分库分表：
以订单为例：由于历史订单使用率并不高， 高频的可能只是近期订单， 因此， 将订单表按照时间进行拆分， 根据数据量的大小考虑按月分表或按年分表。 订单ID最好包含时间(如根据雪花算法生成)， 此时既能根据订单ID直接获取到订单记录， 也能按照时间进行查询。

以上是关于MySQL高级-MVCC（超详细整理）的主要内容，如果未能解决你的问题，请参考以下文章

Java面试题超详细整理《MySQL篇》

Java面试题超详细整理《MySQL篇》

Java面试题超详细整理《MySQL篇》

MySQL高级MVCC原理分析

JavaWeb连接mysql数据库并返回json格式数据（超详细整理）

MYSql数据篇-----基础知识点超详细整理---图形化界面----保姆级教程