1.SQL：一种既熟悉又陌生的编程语言这里介绍几个关键词；“熟悉”、“不熟悉”、“编程语言”。说是“耳熟能详”，是因为它是DBA和开发人员操作数据库的主要手段，几乎每天都在使用。称它为“陌生”意味着很多人只是简单地使用它。至于它是如何工作的？它如何更有效地工作？但他们从来没有考虑过。在这里，SQL被归于一种“编程语言”，这可能与很多人对它的认知不同。我们看一下它的简单定义（以下内容摘自百度百科）结构化查询语言（StructuredQueryLanguage），简称SQL，是一种专用编程语言，一种数据库查询和编程语言，用于存储Fetch数据和查询、更新和管理关系数据库系统。结构化查询语言是一种高级非过程编程语言，允许用户处理高级数据结构。它不需要用户指定数据的存储方式，也不需要用户了解具体的数据存储方式，因此底层结构完全不同的不同数据库系统可以使用相同的结构化查询语言作为数据输入和输入的接口。管理。结构化查询语言语句可以嵌套，这使得它极其灵活和强大。综上所述，SQL是一种非过程性编程语言，通过它可以访问关系数据库系统。第二，你真的懂“SQL”吗？接下来，我就用一个小例子，看看你是不是真的懂SQL。这是一个关于SQL语句执行顺序的非常简单的例子。在这里，一个普通的SELECT语句被分成三个子句。那么在实际执行过程中，是按照什么顺序处理的呢？这里有从A到F的六个选项，大家可以考虑选择...最后的答案是D，即先执行FROM子句，再执行WHERE子句，最后执行SELECT部分??。对于上面的例子，我们来实际构建一个场景，看执行计划是否按照我们选择的顺序执行。关于执行计划的解释，后面再说。这里我先说明一下整个实现过程。第一步是在全表扫描中访问对象表(EMP)。对应于语句的FROM部分。第二步，对提取的结果集进行过滤（过滤部分），即过滤掉符合条件的记录。对应于语句的WHERE部分。第三步，对满足条件的记录进行字段投影，即提取需要展示的字段。对应于语句的SELECT部分。这是SQL各部分执行顺序的详细说明。了解执行顺序对我们以后的优化工作会有很大的帮助。一个很简单的理解就是优化动作越接近越好。3、SQL现在还重要吗？这里引入一个新问题。SQL语言现阶段还重要吗？之所以引入这个话题，是因为随着NOSQL、NEWSQL、BIGDATA等技术的逐渐成熟和推广，“现阶段SQL语言已经不那么重要了”成为一些人的观点。那么实际情况如何呢？让我们先来看一张经典图片。图中描述了传统SMP架构的关系型数据库、MPP架构的NEWSQL、MPP架构的NoSQL不同方案的应用场景对比。从上面的“数据价值密度和实时性”来看，传统关系型数据库适用于价值密度较高、实时性要求较高的场景（不难理解传统关系型数据库存储账户、金额等信息数据库）；其次是MPP架构的NewSQL，MPP架构的NoSQL更适合低价值、实时性要求不高的场景。从下面的“数据规模”来看，传统关系型数据库适合保存的规模仅限于TB级别，而后两者可以保存更大规模（PB、EB）的数据。从以下“典型场景”来看，传统关系型数据库适用于OLTP在线交易系统；MPP架构的NewSQL适用于OLAP在线分析系统；而NoSQL有很多使用场景（适合KV类需求，数据挖掘等）考虑）。最后，从“数据特性”来看，前两者适合存储结构化数据，后者更适合存储半结构化甚至非结构化数据。综上所述，不同的技术各有特点，不存在谁取代谁的问题。传统的关系数据库有其鲜明的特点，在某些场合仍然是唯一的选择。SQL作为其主要的交互语言，必须长期存在和发展。我们来对比一下传统数据库和大数据技术。从数据量、增长类型、多元化、价值等维度对比两种技术，各有各的适用场景。对于大数据领域，各种技术层出不穷。但是，对于广大的用户来说，使用起来往往有一定的门槛，所以现在的一个趋势是在大数据领域引入“likeSQL”，以类似SQL的方式访问数据。对于广大用户来说，这无疑大大降低了使用门槛。解答一些问题：NoSQL和NewSQL已经超越传统数据库，SQL无处发挥！各种技术都有各自适用的场景，不能一概而论。SQL语言作为关系型数据库的主要访问方式，仍然占有一席之地。云时代，谁还在用关系型数据库！对于高价值密度和严格一致性的场景，关系型数据库仍然适合作为解决方案。我用ORMapping工具编程，再也不用写SQL了！的确，ORMapping工具的引入大大提高了生产效率，但是它的副作用也很明显，就是语句的运行效率失控了。许多低效的语句往往是直接由工具生成的。这也是为什么有些制图工具还提供了原生的SQL接口，保证关键语句的执行效率。大数据时代，我们都用Hadoop和Spark，不用写SQL了！无论我们使用Hadoop还是Spark，我们都可以通过编写程序来完成数据分析，但是生产效率往往很低。这也是为什么产生了Hive、SparkSQL等“类SQL”解决方案来提高生产效率的原因。数据库的处理能力很强，不用太担心SQL性能问题！的确，随着多核CPU、大内存、闪存等硬件技术的发展，数据库的处理能力比以前有了很大的提升。但SQL性能仍然很重要。后面我们可以看到，一条简单的SQL语句就可以轻松搞垮一个数据库。SQL优化，找个DBA就行了，我不用学！SQL优化是DBA的职责，但是对于开发人员来说，他们更应该对自己的代码负责。如果能在开发阶段注意SQL的质量，就会避免很多低级问题。我只是一个运维DBA，不会优化SQL！DBA的开发可以分为“运维DBA->开发DBA->数据架构师...”。如果只能完成数据库的运维工作，无疑是技能上的欠缺，对大家以后的发展也不利。而且随着PaaS云的逐步推广，对数据库运维的要求越来越少，对优化、设计、架构的要求越来越多。因此，SQL优化是每个DBA都必须掌握的技能。现在有优化的工具，很简单！确实有些工具可以为我们减少一些优化分析工作，并且会自动给出一些优化建议。但是，作为DBA，您不仅要知其然，更要知其所以然。而且，数据库优化器本身就是一个非常复杂的组件，很难做到完整无差错的优化，需要人工干预和分析。优化不就是索引吗？重点是什么？确实，索引是一种非常常见的优化方法，但并不是唯一的一种。并且在许多情况下，添加索引可能会导致更差的性能。后面会有案例说明。第四，SQL还是很重要的！下面用一个例子来说明，理解SQL的运行原理还是很重要的。这是我在生产环境中遇到的真实案例。在Oracle数据库环境中，两个表是关联的。执行计划令人震惊。优化器评估返回数据量3505T记录，计划返回量127P字节，总开销9890G，返回时间999:59:59。从执行计划可以看出，两张表之间的关联使用了笛卡尔积的关联方式。我们知道笛卡尔连接是指两个表之间没有连接条件的情况。一般情况下，除某些特殊场合外，应尽量避免使用笛卡尔积。否则，再强大的数据库也搞不定。这是典型的多表关联缺少join条件，导致笛卡尔积，导致性能问题。就案例本身而言，并没有什么特别之处，只是开发人员的疏忽导致了一条质量很差的SQL。但在更深层次上，这个案例可以给我们带来以下启示：一个开发者的疏忽导致了严重的后果，而原来的数据库是如此的脆弱。对数据库要保持一颗“敬畏”的心。计算机不是人脑。它不知道你的需求是什么，所以它只能用书面逻辑来处理它们。不要责怪开发商，每个人都会犯错，关键是如何从系统上保证类似的问题不会再次发生。五、SQL优化规则下面我们来看看常见的优化规则。这里所说的优化规则，其实就是指可以从那些角度考虑的SQL优化问题。有很多方法可以查看它。请在下面列出一两个。这里有一张Ali-YeZhengsheng博客的图，相信很多人都看过。这里提出了经典的漏斗优化规则。高度是指我们投入的资源，宽度是指可能获得的收益。从图中可以看出，“减少数据访问”是一种投入最少的资源，产生更多收益的方法；“增加硬件资源”是相对投入资源最多，收益较少的方法。由于时间关系，这里就不细说了。这是我总结的一个优化法则，简称“DoDo”法则。第一篇，《少做还是不做！》翻译过来，就是尽量让数据库少做一些工作，甚至不做任何工作。如何理解更少的工作？例如，创建索引往往可以提高访问效率。原理是将原来的表扫描转换为索引扫描。通过一个有序的结构，只需要少量的IO访问就可以获取到相应的数据，所以效率更高。这归结为做更少的工作。不工作怎么理解？比如在系统设计中常见的缓存设计，很多都是把原来需要访问数据库改成访问缓存。这样既提高了访问效率，又减轻了数据库的压力。从数据库的角度来看，这通常是行不通的。第二篇《非做不可，快做！》已翻译，如果数据库必须做这个事件，那么请尽快做。怎么理解这句话？比如数据库中常见的并行操作，就是通过引入多进程来加快原来的执行过程。加快处理过程可以减少相关资源的占用，提高系统的整体吞吐量。六、SQL执行过程SQL的执行过程比较复杂，不同的数据库之间也存在一定的差异。下面介绍两种主流数据库（Oracle、MySQL）。用户提交一条SQL语句，数据库根据SQL语句的字面值计算出一个HASH值。根据HASH值判断数据库缓冲区中是否有这条SQL的执行计划。如果不存在，则需要生成执行计划（硬解析过程），然后将结果存入缓冲区。如果存在，则判断是否是同一条SQL（HASH值相同的语句可能有不同的字符，即使完全相同也可能代表不同的语句，这一块不展开）确认是同样的SQL语句，然后从缓冲区中提取执行计划。将执行计划交给执行者执行。结果返回给客户端。客户端提交语句，现在查询缓存，查看是否有对应的缓存数据，有则直接返回（一般可能性很小，所以一般建议关闭查询缓存）。交给解析器，解析器会为提交的语句生成解析树。预处理器处理解析树以形成新的解析树。这个阶段有一些SQL改写过程。重写的解析树被提交给查询优化器。查询优化器生成执行计划。执行计划交给执行引擎调用存储引擎接口完成执行过程。这里要注意，MySQL的Server层和Engine层是分开的。最终结果由执行引擎返回给客户端，如果启用了查询缓存，将被缓存。7、SQL优化器在上面的执行过程描述中，优化器进行了多次改进。它也是数据库的核心组件。接下来介绍一下优化器。以上是我对优化器的一些理解。优化器是数据库的精华，值得DBA们认真研究。但遗憾的是，数据库对这方面还不够开放。（相对来说Oracle做的还是不错的）我们这里看到的MySQL优化器的工作过程大致经历了以下几个过程：词法分析、语法分析、语义检查预处理阶段（查询重写等）查询优化阶段（具体可分为逻辑优化和物理优化）查询优化器的优化依据来自成本估算器的估算结果（会调用统计信息作为计算依据），交给执行器执行.这张图是DBAplus社区MySQL专家李海翔对不同数据库优化器技术的对比总结。由此可见，不同的数据库，其实现层次是不同的，有的支持，有的不支持，即使支持，其实现原理也大不相同，表现也不一样。下面会有一个例子来说明8.SQL执行计划理解执行计划是DBA优化的前提之一。它为我们打开了一个通向数据库内部的窗口。但遗憾的是，一直没有一本叫做《如何理解执行计划》的书。这里的情况很复杂，很多都需要DBA们长年积累。这是一个简单的Oracle执行计划示例，说明了执行计划的一般内容。
