weixin_54542328的博客

的定位是一款轻量级Java框架，它会以POM依赖的形式嵌入程序，运行期间会和Java应用共享资源，这款框架的本质可以理解成是JDBC的增强版，只不过Java原生的JDBC仅支持单数据源的连接，而Java-ORM框架在执行SQL语句时，会以切面的形式拦截发往数据库的语句，接着根据配置好的数据源、分片规则和路由键，为SQL选择一个目标数据源，然后再发往对应的数据库节点处理。在整个业务系统中对性能损耗极低，但为何后面又会推出呢？因为。

前面的步骤中实现了数据库的主备、主主搭建，但这仅仅只是数据库的基础架构，如果想要将这些架构应用到业务中，还得解决客户端的连接问题，毕竟现在从原有的单库变为了多库，因此多数据源的连接需要再通过新的手段处理，业内一般有三种做法：①基于提供的接口和类，拦截SQL语句动态选择对应的数据源。②使用这类驱动层框架，配置多个数据源，路由改写的工作交给框架完成。③使用等这类代理中间件，业务系统连接中间件，路由改写的工作交给中间件完成。基于上述三种方案，配置好多数据源的管理后，业务系统在线上运行时，会自行根据SQL。

不论任何技术栈，但凡一提高可用、高性能、高稳定这些词汇，必然会牵扯到集群、主从架构的概念，如任何技术栈中都会有，而MySQL中同样不例外，官方也提供了主从架构的支持，通过调整多个MySQL节点的配置信息，即可将一个节点的数据同步给另一个或多个节点，但这种方式同步的是所有数据！有人也许会疑惑：为什么要同步所有数据呀？难道不能对数据作分片，不同的节点同步不同的数据嘛？

在本章中补齐了分库分表带来的一系列问题的剖析，以及问题产生后相应的解决方案，但在这里仅给出了基本的解决方案，但并未对其进行落地实践，毕竟内容较多不可能面面俱到，具体的落地会在后续的章节中徐徐道来~最后附言：所谓的架构师并不是指能做架构选型即可，比如决定缓存用Redis、消息中间件用RocketMQORM框架用、微服务框架用。

分表方案主要是针对于单表字段过多或数据过多的情况去做的，通过垂直、水平分表的手段，能够很好解决单表由于字段、数据量过多产生的一系列负面影响，但无论是垂直分表还是水平分表，都必须建立在单库压力不高，但是单表性能不够的情况下进行的，因为它们都属于库内分表。如果是数据库整体压力都很大的情况，从而导致的查询效率低下，那不管再怎么做分表也无济于事，毕竟连流量入口都出现了拥塞，自然分表也无法解决问题，所以分表操作只建立在单库压力不高，但是单表查询效率低下的情况适用。

在这章中咱们介绍了MySQL几个重要的里程碑版本，显然每个版本中都对前版本中做了不小的优化，尤其是MySQL8.0中的新特性和新优化点十分具备吸引力。但线上环境已有数据的情况下，也不适合再做迁移，毕竟数据迁移是一件十分麻烦的事情，有时候甚至比你重构一个Java项目更累，因此如果你的数据库版本目前足以支撑系统的正常运转，那就没有必要去做版本迁移。

无用的知识又增加啦！为啥说表分区技术没用呢？其实作用还是有的，不过一般情况下都会有更好的选择代替，比如采用分表技术来划分表数据，不仅仅支持水平切分，甚至还可以做垂直切分。当单库的数据过多时，表分区技术其实派不上太大的用场，因为当数据达到一定量级时，要么会选择分库分表，要么会选择上分布式数据库，如TiDB，最后再配合大数据技术辅助，做历史数据归档。

其实排查这类问题不难，主要是得先定位到对应的线程，然后再找出OS线程对应的MySQL线程，找到对应的MySQL线程后，再找到其正在执行的SQL语句，因为线程是执行这条语句才导致占用高额CPU资源的，因此最后只需要把SQL的逻辑调整合理后，就能够彻底解决CPU占用过高的问题。本篇中对于MySQL开发过程中、线上环境中会出现的各类疑难杂症，以及具体该如何解决与排查的方法做了阐述，在本章中分了开发中的Bug、慢查询的排查、MySQL为啥不写如何解决内存相关的问题呢？相对来说，MySQL中除开Memory。

对于MySQL数据库的一些调优策略，到这里就大致讲述完毕了，其中能够带来最大收益的方案则是优化项目架构和数据库架构，但这种方案成本也是最高的，一方面需要解决新的问题，同时还需要额外的部署成本，所以在无需使用更高规格的架构处理并发时，就不必提前做这些架构设计，因为能够根据业务特性控制成本，也是作为一个优秀的高级开发/架构师必备的思想。同时在本章中也未曾过多讲解SQL优化，这是每位中高级开发的重心，因为毕竟作为一个正常的程序员，代码才是日常工作中接触最多的东西，但由于SQL。

到这里为止，对于MySQL中大部分常用的命令基本上都已经罗列出来啦！以后如若忘记某个函数名称、某条语句的语法等等，都可以直接在本章中快捷搜索，但本篇仅仅只写出了基本的语法，实际数据库开发中往往还需要结合业务，来编写更为复杂的SQL语句~。本章的主要目的是当成《MySQL命令手册》，本质上没有太多可以学习的知识点，但它却非常实用，能够协助咱们的日常开发。

前面简单提过一嘴，存储过程类似于一门新的语言，在其中存在专门的语法规则，因此想要撰写一个高效的存储过程之前，我们得先掌握存储过程中的一些基本语法，例如创建、变量、流程控制、循环等基础语法。但好在大家都并非刚学编程的小白，因此这些在其他语言中都存在的语法，其实我们只需要搞清楚在MySQL中的关键字即可，所以上手速度还是非常快的，那么Les't Go~| 1 | 熊猫 | 女 | 6666 | 2022-08-14 15:22:01 |

经过上述一系列的分析后，咱们就将MySQL内存方面的知识理清楚了，尤其是关于InnoDB的缓冲池，会发现和我说的一样：**InnoDB引擎几乎将所有的操作都放在了内存中进行**，比如写日志、写数据、查数据等，只有逼不得已的情况下，才会走磁盘读写数据。假设你部署MySQL的机器内存足够大，并且为分配的内存空间也足够大，比如机器的内存有128GB，此时为分配了100GB，而整个库的所有表数据加起来仅有80GB，此时要记住！InnoDB。

叨叨絮絮下来，就大致将MySQL中的一些常见、较为重要的日志讲明白啦，其实重点搞清楚undo-log：主要用于实现事务ACID原则中的原子性和MVCC机制。redo-log：主要用于实现事务原则中的持久性，确保事务提交后就不会丢失。bin-log：主要结合redo-log实现事务原则中的一致性，确保事务提交前后，数据的一致。对于其他几类日志，在本篇中也仅讲明了大概，毕竟后面的章节中会再出现，而对于上述三大日志也就基本上不会提到了，因此剖析的较为全面，那么咱们下篇见~，下面准备讲：《MySQL。

对于死锁的定义，这里就不展开叙述了，因为在之前《并发编程-死锁、活锁、锁饥饿》[5]中曾详细描述过，如下：死锁是指两个或两个以上的线程（或进程）在运行过程中，因为资源竞争而造成相互等待、相互僵持的现象，一般当程序中出现死锁问题后，若无外力介入，则不会解除“僵持”状态，它们之间会一直相互等待下去，直到天荒地老、海枯石烂~当然，为了照顾一些不想看并发编程文章的小伙伴，这里也把之前的死锁栗子搬过来~

MVCC多版本并发控制，听起来似乎蛮高大上的，但实际研究起来会发现它并不复杂，其中的多版本主要依赖Undo-log日志来实现，而并发控制则通过表的隐藏字段+ReadView快照来实现，通过Undo-log日志、隐藏字段、ReadView快照这三玩意儿，就实现了MVCC机制，过程还蛮简单的~到这里，其实对于MySQL的事务隔离机制，已经拨开一部分迷雾了，下篇《MySQL事务与锁机制原理篇》中，则会彻底讲清楚MySQL锁是怎么实现的，以及不同的事务隔离级别，又是如何借助锁+MVCC处理客户端SQL。

看到这里，相信大家对MySQL中提供的锁机制有了全面的认识，但以目前情况而言，虽对每种锁类型有了基本认知，但本篇的内容更像一个个的点，很难和《MySQL事务篇》连成线，而对于这块的具体内容，则会放在后续的《事务与锁机制的实现原理篇》中详细讲解，在后续的原理篇中再将这一个个知识点串联起来，因为想要真正弄懂MySQL事务隔离机制的实现，还缺少了一块至关重要的点没讲到：即MVCC机制。因此会先讲明白数据库的MVCC多版本并发控制技术的实现后，再去剖析事务隔离机制的实现。

一点点看到这里，《MySQL事务篇》也就接近了尾声，在本篇中对事务机制一点点去引出，慢慢的到事务机制的概述、并发事务的问题、事务的隔离级别、事务的实现原理等诸多方面进行了全面剖析，但大家应该也略微有些不尽兴，毕竟对于隔离级别的具体实现并未讲到，这是由于MySQL事务与锁机制之间有着千丝万缕的关系，所以在《MySQL锁篇》中会再次详细讲到事务隔离机制的。当然，由于目前是分布式/微服务架构横行的时代，所以也引出了新的问题，即分布式事务问题。

到目前而言，对于MySQL的索引底层实现，大多数内容就全面讲明白了，从最开始的全表扫描过程，到磁盘IO实现、局部性原理、索引为什么默认是B+Tree结构、建立索引后发生的一系列事情、写类型的SQL对索引的影响.....等一系列内容进行了深入剖析。看完本章后，对于之前两章中抛出的一些疑惑，你稍加思考后也能彻底明悟，最后再简单说说聚簇索引和非聚簇索引的区别。聚簇索引和非聚簇索引的根本区别：聚簇索引中，表数据和索引数据是按照相同顺序存储的，非聚簇索引则不是。

至此，MySQL索引应用篇，也就是索引中篇就结束了，相信大家认真看完本篇之后，对于索引的掌握性、熟练程度绝对会更上一层楼，因为本章中从索引的优劣分析，到建立索引的原则、索引失效的情景、使用索引的正确姿势、MySQL对于索引的优化机制等各方面，对索引进行了进一步阐述。经历中、上两篇的阐述后，对于MySQL。

对于MySQL索引就是用来帮助表快速检索目标数据的。此时先来简单回顾一下MySQL中索引是如何使用的呢？首先需要创建索引，MySQL可以通过三种方式创建一个索引。OK~，在本篇中就对MySQL的索引机制有了全面认知，从索引的由来，到索引概述、索引管理、索引分类、唯一/全文/联合/空间索引的创建与使用等内容，进行了全面概述，相信本章看下来，足够让你对MySQL索引机制有一个系统化的体系，那么我们下篇再见。

在本篇中详细阐述了DB库表设计时的一些思想，也就是范式与反范式设计理论，这些理论仅仅只是一套方法论，实际开发过程中，还是需要根据业务来设计出最合适的结构。在文中提及了六种范式，但一般项目中仅需满足到第三范式或BC范式即可，因为这个度刚刚好，再往后就会因为过于精细化设计，导致整体性能反而下降。控制到第三范式的级别，一方面数据不会有太多冗余，第二方面也不会对性能影响过大。同时，如若打破范式的设定能对业务更有利，那也可以违背范式原则去设计。

看到这里，SQL执行原理篇也走进了尾声，其实SQL语句的执行过程，实际上也就是MySQL的架构中一层层对其进行处理，理解了MySQL架构篇的内容后，相信看SQL执行篇也不会太难，经过这篇文章的学习后，相信大家对数据库的原理知识也能够进一步掌握，那我们下篇再见~

MySQL数据库是由瑞典的MySQL AB公司开发的，后面这家企业被Sun公司收购，最后Sun公司又被Oracle以74亿美元收购，所以本质上MySQL现在隶属于Oracle旗下，因此大家也会发现，MySQL后面的高版本会有收费版出现。实际上如果MySQL没有并入Oracle的话，是有很大几率问鼎数据库榜首的，造化弄人。当然，虽然MySQL出了收费版，但Oracle也没有赶尽杀绝，而是向MySQL的用户给出了《十项承诺》[1]，所以我们如今依旧可以使用开源版的MySQL。