orczhou.com

testing-04

代码细节

some code staff

  • 十年磨一剑，阿里巴巴企业级数据管理平台：iDB

    ·

    admin

    本文前段时间写的介绍云端企业数据管理产品DMS的“软”文，文章首发在阿里巴巴数据技术公众号，扫描下面的二维码关注：

    qrcode_for_gh_55546b2b5111_430

    摘要：在安全稳定的前提下，为了解决DBA的服务效率问题，十年前我们开始iDB的研发，完成手工变更的在线化，成为了DBA能力产品化的载体。在最新的4.0版本中，iDB面向云时代，是业界首创的数据库devops解决方案，形成了云时代企业数据管理的最佳实践。

    一、为了效率与安全而生

    在阿里巴巴，数据库团队是数据的守护者，保障着数据库的安全、稳定、高效的运行。在早期，DBA除了负责数据库的基础运维，对于研发流程中的数据库变更也都由DBA负责，包括线上库表设计、结构变更发布、数据变更、SQL审核、性能优化、容量评估等等。这种精细的业务支持方式，企业早期发展中，可以有效的保障数据库的稳定与安全，支撑业务的快速发展。

    业务持续增长，很快我们遇到了两个问题：(1) DBA繁重的工作量可能会成为业务研发瓶颈；(2) 大量的重复工作会限制DBA的成长。企业快速发展中，会不断的有新业务上线，成熟的业务也会快速迭代创新，伴随会有大量的数据库相关的变更和服务，如果所有这些都由DBA来处理，那么业务繁多DBA可能成为瓶颈，另外，DBA也会陷入各种“做不完”的日常工作，很难进一步成长。

    既要有DBA的安全把控能力，又希望高效支撑大量业务的发展，阿里数据库团队研发了自己的企业数据库管理平台：iDB。企业内部的研发、测试等人员，可以使用iDB完成大部分数据库相关的操作，包括数据查询、数据变更、结构变更、实例申请等等。另外，iDB产品中还继承了大量DBA的经验，比如判断哪些DDL会锁表、InnoDB表结构设计是需要主要哪些问题等等。 (more…)

  • index merge的补充说明

    ·

    orczhou

    在除了前面介绍的常见index merge的案例(Index Merge Union Access Algorithm)之外，还有一类很少见也比较特殊的index merge，多个索引扫描后进行交集，即 Index Merge Intersection。这类执行计划比较少见(因为MySQL需要ROR的原因)，但是，在合适的场景使用，效率仍然会有很大的提示，本文将看看MySQL优化器如何评估和选择此类执行计划。MySQL手册对此只是三言两语简单介绍了一下，这里做个较为详细的说明。

    这类执行计划完整名称应该是：The Index Merge Intersection Access Algorithm，下文简称Intersection。

    1. 为什么需要考虑Intersection

    考虑如下查询:

    SELECT COUNT(*) FROM t1 WHERE key1=1 AND key2=1;

    优化器可以考虑使用索引key1或者key2进行REF/Range访问，如果使用key1，那么key2=1则作为过滤条件。另外，优化器还会考虑使用Intersection，即同时使用索引key1和key2。这样做可能的好处是：

    (a) 如果两次索引扫描后做交集，如果最后ROWID很少，则回表次数大大减少

    (b) 如果扫描这两个索引能是覆盖扫描的话，则无需回表 (more…)

  • MySQL优化器：index merge介绍

    ·

    orczhou

    在MySQL官方手册上，关于index merge的介绍非常非常少。甚至还有不少误导的地方，这次把5.1版本关于此类优化处理的代码细看了一遍，以案例的方式介绍了各种实用index merge访问类型的SQL。后续的还会继续介绍index merge实现的主要数据结构，以及成本评估。

    1. 什么是index merge

    MySQL优化器如果发现可以使用多个索引查找后的交集/并集定位数据，那么MySQL优化器就会尝试index merge这类访问方式。index merge主要分为两大类，多个索引交集访问(intersections)，多个索引并集访问，当然这两类还可以组合出更为复杂的方式，例如多个交集后做并集。

    1.1 index merge的限制：range优先

    MySQL在5.6.7之前，使用index merge有一个重要的前提条件：没有range可以使用。这个限制降低了MySQL index merge可以使用的场景。理想状态是同时评估成本后然后做出选择。因为这个限制，就有了下面这个已知的bad case(参考)：

    SELECT * FROM t1 WHERE (goodkey1 < 10 OR goodkey2 < 20) AND badkey < 30;

    优化器可以选择使用goodkey1和goodkey2做index merge，也可以使用badkey做range。因为上面的原则，无论goodkey1和goodkey2的选择度如何，MySQL都只会考虑range，而不会使用index merge的访问方式。这是一个悲剧…（5.6.7版本针对此有修复) (more…)

  • MySQL源码：索引相关的数据结构(后篇)

    ·

    orczhou

    前篇介绍了MySQL存储索引信息的基本数据结构。本篇将延续下去，介绍MySQL如何找到可以使用的索引，以及期间需要使用的主要数据结构。

    谁适合阅读: 本文不打算从High Level来介绍MySQL索引及其使用，相反是从MySQL源码对应的数据结构开始介绍。如果你了解MySQL索引的基本原理，还打算继续从源码的角度解决一些索引使用的问题，那么你适合参考本文，否则，打住，真的很枯燥:(。在可见的未来，作者还将介绍Range优化相关的数据结构等。

    0. 概述

    本文介绍MySQL如何发现WHERE条件中的等值表达式，并通过分析这些等值表达式，找到可以使用的索引。在这个过程中，MySQL将递归的访问所有WHERE条件”谓词”，并将等值表达式都存储到KEY_FIELD对象的数组中。

    然后遍历该KEY_FIELD数组，并同时对比所有索引列，找到哪些字段是在索引列中出现，这些字段则可能可以使用索引，MySQL将所有这些字段都存储在对象KEYUSE数组中。

    最后，对KEYUSE进行处理，包括排序、删除无法使用的索引列。这时KEYUSE数组就是所有可以使用REF的索引列了。 (more…)

  • MySQL源码：索引相关的数据结构(前篇)

    ·

    orczhou

    很枯燥的，配首背景音乐吧：

    本文将尝试介绍MySQL索引存储相关的数据结构。程序=数据结构+算法，了解数据结构，然后就可以进一步了解MySQL源码中如何使用索引，如何选择自己的执行计划。

    1. MySQL如何描述某个数据表的索引

    MySQL使用TABLE对象来描述一个数据表，那么数据表的索引是如何描述，索引的统计信息又是如何存储的呢? 例如我们有如下数据表：

    CREATE TABLE `users` (
  `id` int(11) NOT NULL,
  `nick` varchar(32) DEFAULT NULL,
  `reg_date` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `IND_NICK` (`nick`),
  KEY `IND_REGDATE` (`reg_date`)
)

    该表有索引，PRIMARY KEY、IND_NICK、IND_REGDATE，我们来看看MySQL内部是如何存储这三个索引，以及如何使用这些索引的统计信息的。下图，描述了存储一个数据表索引的主要结构：

    indexoftable-s (more…)

  • MySQL源代码：从SQL语句到MySQL内部对象

    ·

    orczhou

    自从有了微薄后博客就写得少了，上一篇博客已经是6月份写的了… 从写第一篇关于MySQL源码的文章之后也已经过了很久，继续上路。

    优化器是关系数据库的一个重要而有特色的部分，优化器的理论和实践也多半也都很复杂，本系列文章希望通过解析MySQL优化器，来用好MySQL,扬其长，避其短。顺便也一窥关系数据库优化器的实现思路。文章将重点介绍重要的数据结构和数据结构之间的关系，而不是侧重于代码（”Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”）。

    0 写在前面

    本文解决了什么问题：希望通过这些文章能够帮你更加顺畅的理解MySQL优化器的行为；在你阅读MySQL源代码之前了解更多的背后思路。

    本文不解决什么问题：教你如何读懂源代码；

    这个系列很长,大概按这样的思路进行下去: 基本的数据结构、语法解析、JOIN的主要算法、JOIN顺序和单表访问。数据结构(以及他们的关系)和算法流程总是相互穿插介绍。

    建议阅读：参考文献中的文章和书籍，都建议在阅读本文之前阅读。

    1 SQL语句解析基础

    1.1 语法解析基础/Flex与Bison

    MySQL语法解析封装在函数MYSQLparser中完成。跟其他的语法解析器一样，它包含两个模块：词法分析(Lexical scanner)和语法规则(Grammar rule module)。词法分析将整个SQL语句打碎成一个个单词(Token)，而语法规则模块则根据MySQL定义的语法规则生成对应的数据结构，并存储在对象THD->LEX结构当中。最后优化器，根据这里的数据，生成执行计划，再调用存储引擎接口执行。

    词法分析和语法规则模块有两个较成熟的开源工具Flex和Bison分别用来解决这两个问题。MySQL出于性能和灵活考虑，选择了自己完成词法解析部分，语法规则部分使用Bison。词法解析和Bison沟通的核心函数是由词法解析器提供的函数接口yylex()，在Bison中，必要的时候调用yylex()获得词法解析的数据，完成自己的语法解析。Bison的入口时yyparse()，在MySQL中是，MYSQLParse。

    如果对词法分析和语法规则模块感到陌生，建议阅读参考文献[4][5][6]先注1，否则很难理解整个架构，或者至少会有很强的断层感。而且，根据Bison的Action追踪MySQL数据的存储结构是很有效的。 (more…)