My sql 5.6新特性深入剖析——innodb引擎

发表于 2013 年 4 月 12 日 由 hedengcheng

简介

2012-09-29，MySQL 5.6第一个RC版本发布(MySQL 5.6.7)，2013-02-05，MySQL 5.6第一个GA版本发布(MySQL 5.6.10)。总的来说，MySQL 5.6算是一个值得期待的版本，包含了大量的新特性，了解这些新特性，不仅对数据库内核研发有帮助，对于更好的使用MySQL数据库也有着极大的意义。

 

因此，本人从2012年初开始，就一直关注MySQL 5.6版本的各个新特性，阅读每一个5.6版本相关的相关博文，下载其最新的版本进行测试验证，积累下了一定的心得与收获，形成了这个介绍MySQL 5.6新特性深入剖析的PPT。本PPT一共分为两期：分别是InnoDB引擎以及MySQL Server。

 

本次为第一期，分享 MySQL 5.6 InnoDB引擎中的性能优化与功能增强。性能优化包括：Read-Only Transaction，Buffer Pool Flushing，Page Cleaner，Purge等；功能增强包括：Online DDL，InnoDB Memcached Plugin，Transportable Tablespaces，Buffer Pool Dump/Restore等；同时，阅读此PPT的过程中，朋友们还可以通过PPT中的链接，深入到每个功能的设计、实现与使用的相关资料，更进一步了解每一个新特性。

 

My sql 5.6新特性深入剖析——innodb引擎

 

新浪微盘地址

 

Slideshare在线观看

 



 

发表在 InnoDB, MySQL Server, 数据库, 数据库内核分享, 数据库研发 | 标签为 , , , | 一条评论

InnoDB Memcached Plugin源码实现调研

发表于 2013 年 4 月 3 日 由 hedengcheng

背景

 

MySQL 5.6版本，新增了一个NoSQL的接口，通过将memcached嵌入到MySQL系统之中，用户可以直接使用memcached接口直接操作MySQL中的InnoDB表，绕过MySQL Server层面的SQL解析，优化，甚至绕过InnoDB Handler层，直接操作InnoDB内部的方法，从而达到更优的响应时间与效率。关于此功能的官方介绍，请见：InnoDB Integration with memcached 。嵌入memcached之后，整个MySQL的架构如下图所示：

 

 

本文接下来的部分，将从源码的角度，详细分析InnoDB Integration with memcached的实现细节问题。

 

导读

 

  • InnoDB引擎为了支持Memcached API，在Handler层面进行的改动，请见(一)；


  • Memcached Plugin的初始化流程，请见(二)；

 

  • InnoDB提供的Callback方法在InnoDB Handlerton中的data中以及Memcached Plugin的data中，是如何传递的呢？请见(三)；

 

  • InnoDB Memcached Engine提供的方法集合，请见(四)；

 

  • InnoDB Memcached Engine提供的方法，如何调用到InnoDB Engine提供的方法，请见(五)；

 

  • InnoDB Memcached Engine中，存在两个Engine实例：InnoDB Engine vs Default Engine，二者的功能异同，请见(六)；

 

  • InnoDB Memcached Engine中，需要配置Container Table，Container表详解，请见(七)；

 

  • InnoDB Memcached Engine的初始化与使用流程，可参考engine_testapp.c测试文件；

继续阅读 →

发表在 InnoDB, MySQL Server, 数据库, 数据库内核分享, 数据库研发 | 标签为 , , , , | 3 条评论

二分查找(Binary Search)需要注意的问题，以及在数据库内核中的实现

发表于 2013 年 4 月 1 日 由 hedengcheng

问题背景

 

今年的实习生招聘考试，我出了一道二分查找(Binary Search)的题目。题目大意如下：

 

给定一个升序排列的自然数数组，数组中包含重复数字，例如：[1,2,2,3,4,4,4,5,6,7,7]。问题：给定任意自然数，对数组进行二分查找，返回数组正确的位置，给出函数实现。注：连续相同的数字，返回第一个匹配位置还是最后一个匹配位置，由函数传入参数决定。

 

我为什么会出这道题目？

 

  • 二分查找在数据库内核实现中非常重要

    在数据库的内核实现中，二分查找是一个非常重要的逻辑，几乎99%以上的SQL语句(所有索引上的范围扫描/等值查询/Unique查询等)，都会使用到二分查找进行数据的定位。


    考虑一个数据库表t1(a int primary key, b int)，表上的b字段有一个B+树索引，表中记录的b字段取值，就是题目中的[1,2,2,3,4,4,4,5,6,7,7]序列。此时，给定以下的两条查询语句，就是使用到了不同的二分查找逻辑：


    SQL1：   select * from t1 where b > 4;

    SQL2： select * from t1 where b >= 4;


    针对SQL1，索引的二分查找，就需要跳过所有的4，从最后一个4之后开始返回所有记录；针对SQL2，二分查找就需要定位到第一个4，然后顺序读取所有记录。


    除此之外，针对数据库中其他的查询逻辑，二分查找还需要附带更多的功能，例如：


    SQL3： select * from t1 where b < 2;

    SQL4： select * from t1 where b <= 2;


    由于数据库索引同时支持反向扫描，因此SQL3、SQL4的语句，都可以使用索引反向扫描。反向扫描时，SQL3需要定位到索引中的第一个2；而SQL4，则需要定位到索引的最后一个2，然后开始反向返回满足查询条件的索引记录。

    继续阅读 →

发表在 InnoDB, Programming, 数据库, 数据库内核分享, 数据库研发 | 标签为 , , | 5 条评论

SQL中的where条件，在数据库中提取与应用浅析

发表于 2013 年 3 月 3 日 由 hedengcheng

1        问题描述

一条SQL，在数据库中是如何执行的呢？相信很多人都会对这个问题比较感兴趣。当然，要完整描述一条SQL在数据库中的生命周期，这是一个非常巨大的问题，涵盖了SQL的词法解析、语法解析、权限检查、查询优化、SQL执行等一系列的步骤，简短的篇幅是绝对无能为力的。因此，本文挑选了其中的部分内容，也是我一直都想写的一个内容，做重点介绍：

 

给定一条SQL，如何提取其中的where条件？where条件中的每个子条件，在SQL执行的过程中有分别起着什么样的作用？

 

通过本文的介绍，希望读者能够更好地理解查询条件对于SQL语句的影响；撰写出更为优质的SQL语句；更好地理解一些术语，例如：MySQL 5.6中一个重要的优化——Index Condition Pushdown，究竟push down了什么？

 

本文接下来的内容，安排如下：

  1. 简单介绍关系型数据库中数据的组织形式；
  2. 给定一条SQL，如何提取其中的where条件；
  3. 最后做一个小的总结；

 

继续阅读 →

发表在 Optimizer, 数据库, 数据库内核分享, 数据库研发 | 标签为 , , | 12 条评论

Oracle RAC资源管理算法与Cache-Fusion实现浅析

发表于 2013 年 2 月 21 日 由 hedengcheng

 

本人阅读<Oracle DSI408>，<Oracle 8i Parallel Server>，<Oracle Core>等书籍后，整理的一篇简单介绍Oracle RAC实现的PPT，内容包括RAC的基本架构、RAC的脑裂检测、RAC的资源管理、RAC Cache-Fusion、RAC Instance Crash Recovery流程等。

 

微盘地址：Oracle RAC资源管理算法与Cache-Fusion实现浅析

 

注1：能够翻墙的朋友，应该能够看到以下的Slideshare内容

 



发表在 Oracle, 数据库 | 标签为 , , , , , , , , | 留下评论

NTSE、TNT引擎研发之自动化测试实践

发表于 2013 年 2 月 19 日 由 hedengcheng

背景介绍

软件自动化测试，是软件测试中的一类分支。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

 

基于NTSE、TNT项目的特点：

  • 软件需求变动不频繁

    NTSE是MySQL的一个非事务存储引擎，TNT是MySQL的事务存储引擎。两个项目在立项之初，就已经确定了项目的特性及主要功能。NTSE项目从2008年6月至今，其核心功能几乎没有变化。

  • 项目周期长

    NTSE、TNT均为数据库的存储引擎，研发难度大，周期长。其中，NTSE引擎从2008年6月立项，到目前为止已经历经5年左右时间，发布了多个版本。TNT引擎从2011年9月立项，至今也有了一年半左右时间。而且，两个项目还会一直进行持续研发，项目周期非常长。

  • 测试脚本可重复使用

    由于NTSE、TNT项目的核心功能相对稳定，因此很多测试用例，可以重复使用。例如：NTSE早期开发的测试框架与测试代码，在新的TNT引擎中仍旧能够正常运行。

    与此同时，数据库系统已经是非常成熟的系统，市场上已经有了大量自动化性能测试工具，这些工具也能够用于测试NTSE、TNT引擎。

NTSE、TNT项目以上三个显著的特点，非常符合软件自动化测试的基本需求。因此，在项目的研发过程中，大量使用了自动化测试技术，达到了很好的测试效果。

继续阅读 →

发表在 Test, 数据库, 数据库研发 | 标签为 , , | 2 条评论

从MySQL Bug#67718浅谈B+树索引的分裂优化

发表于 2013 年 1 月 6 日 由 hedengcheng

问题背景

今天，看到Twitter的DBA团队发布了其最新的MySQL分支：Changes in Twitter MySQL 5.5.28.t9，此分支最重要的一个改进，就是修复了MySQL 的Bug #67718：InnoDB drastically under-fills pages in certain conditions。关于此Bug的详细描述，以及如何重现此问题，可以阅读以上的Bug链接，以下简单描述下此Bug对应的问题：

 

InnoDB的索引分裂策略，在特定的情况下，索引页面的分裂存在问题，导致每个分裂出来的页面，仅仅存储一条记录，页面的空间利用率极低。

 

此Bug引起了我的兴趣，因此准备跟大家简单聊聊B+树索引的结构、B+树的分裂、B+树分裂操作的优化、Bug #67718的成因，以及个人对如何修复此Bug的一些建议等。

继续阅读 →

发表在 InnoDB, 数据库, 数据库内核分享, 数据库研发 | 标签为 , , , , , | 29 条评论

硬件体系架构浅析

发表于 2012 年 12 月 19 日 由 hedengcheng

个人写的一个介绍硬件体系架构的PPT，介绍CPU，Cache，内存，硬盘，SSD，网络等各方面的基础知识。包括如何计算各种内存的速度？如何计算硬盘的IOPS？SSD与硬盘的性能差距？编程中，针对不同的硬件，有何注意点？等等知识。由于本人不是这方面的专家，因此做了大量的调研，力争让每一页的PPT都尽量正确，如果PPT中有错误之处，还希望朋友们给予指出，本人做修正。

 

此PPT，可通过新浪微盘下载，也可以通过Slideshare在线阅读。其中，新浪微盘分享的下载文件，每一页的PPT，其备注部分都包含了撰写此页PPT所参考的资料，推荐通过参考资料进行深入的阅读。

 

新浪微盘地址：硬件体系架构浅析

 



发表在 Hardware | 标签为 , , , , , | 3 条评论

数据库内核分享(第二期)—— InnoDB 日志 回滚段 & 崩溃恢复 实现详解

发表于 2012 年 12 月 7 日 由 hedengcheng

 

本期PPT分享内容：

 

InnoDB 日志/回滚段/崩溃恢复的实现详解。第一期分享的内容，是InnoDB与Oracle的Buffer Pool实现对比。而本期，让我们暂时告别Oracle，将心思完全放在InnoDB引擎上。本期的分享，将详细介绍如下内容：
一、InnoDB的日志相关内容：InnoDB有哪些日志？InnoDB的DML操作，会如何记录日志？为何不同的Update操作，性能上会有较大的不同？
二、InnoDB的Redo详解：InnoDB Redo日志的种类？Mini-Transaction是什么？InnoDB的Log Buffer，Log Block的结构是怎样的？如何通过LSN计算对应的日志文件位置？
三、InnoDB的Undo详解：InnoDB的回滚段结构是如何组织的？回滚段页面有哪些类型？事务与回滚段是如何交互的？事务提交、回滚、Purge的操作，分别如何进行？
四、InnoDB的崩溃恢复详解：InnoDB的崩溃恢复步骤？崩溃恢复过程中，如何处理Redo？如何处理Undo？如何重建所有事务？

 

本期PPT的微盘下载地址：微盘下载

本期PPT分享的视频地址：分享视频

 



 

发表在 InnoDB, MySQL Server, 数据库, 数据库内核分享 | 标签为 , , , , , , , , | 留下评论

InnoDB Adaptive Hash Index浅析

发表于 2012 年 12 月 7 日 由 hedengcheng

InnoDB Adaptive Hash Index调研总结

  • #InnoDB Adaptive Hash Index# 定义

    维护索引叶页面中所有记录的索引键值(或键值前缀)到索引叶页面位置的Hash映射关系，能够根据索引键值(前缀)快速定位到叶页面满足条件记录的Offset，减少了B+树Search Path的代价，将B+树从Root页面至Leaf页面的路径定位，优化为Hash Index的快速查询。

 

  • #InnoDB Adaptive Hash Index# 使用

    Adaptive Hash Index是针对B+树Search Path的优化，因此所有会涉及到Search Path的操作，均可使用此Hash索引进行优化，这些可优化的操作包括：Unique Scan/Range Scan(Locate First Key Page)/Insert/Delete/Purge等等，几乎涵盖InnoDB所有的操作类型。

 

  • #InnoDB Adaptive Hash Index# 维护

    Adaptive，意味着不是所有的叶页面都会以Hash索引维护，叶页面进入Hash索引的条件是：同种类型的操作(Scan/Insert…)，命中同一叶页面的次数，超过此页面记录数量的1/16，则可将当前叶页面加入Hash索引，用以优化后续可能的相同Search Path。

 

  • #InnoDB Adaptive Hash Index#

    Adaptive Hash Index，是一个临时的Hash索引(针对一类特定的语句进行的优化，一般而言，当前的Hash优化，对于下一条语句，不一定有用)，针对不同的Scan/Insert/Delete，Search Path的条件不同，导致最终提取出来的Search Info的n_fields与n_bytes也不同(n_fileds + b_bytes构成了索引的键值前缀，或者是完整的索引键值)，同一页面的前一个Hash索引，在下一个查询中可能就失效了。此时，进行hash guess会失败(会设置Search Info的last_hash_succ = false，接下来不会使用此Hash Index)，在Search Path之后，进行Hash索引的更新(btr0sea.ic::btr_search_info_update())，会重设Search Info的n_fields，n_bytes，进而重设buffer header上的n_fields，n_bytes，在满足页面重新进入Hash Index的条件之后(见下面的分析，一共有三个条件)，当判断出buffer header上的[n_fields, n_bytes]与[curr_n_fields, curr_n_bytes]不同，则对页面重新进行Hash计算，步骤是：

    • 首先删除页面旧的Hash索引项；
    • 然后根据[n_fields, n_bytes]组合计算新的Hash索引项，存入Hash Index；

 

  • #InnoDB Adaptive Hash Index#

    对需要维护Hash Index的B+树索引叶页面，按照一定的[n_fields, n_bytes]组合，提取索引键值前缀，计算hash值，维护页内所有Records至叶页面offset的Hash项。但是，由于index->search_info是索引全局所有的，其中保存的[n_fields, n_bytes]会根据不同的SQL语句发生变化，此组合一变，原来进入Hash索引的项就无法摘除了(计算Hash值也会变化，找不到原有的Hash项)。因此，InnoDB在每一个Buffer Header上维护了自身进入Hash索引时的[n_fields, n_bytes]组合，后续根据此组合可以将页面对应的Hash项完全删除。更进一步，Buffer Header之上还有[curr_n_fields, curr_n_bytes]组合，这个标识的当前页面在Hash索引中真正使用的组合。Buffer Header上维护两组[n_fields, n_bytes]，[curr_n_fields, curr_n_bytes]的目的：

    • [n_fields, n_bytes]

      此组合随着index->search_info上的[n_fields, n_bytes]组合的变化而变化，若二者不同，则更新Buffer Header组合，重新开始统计新的组合潜在可用的次数(n_hash_helps)；

    • [curr_n_fields, curr_n_bytes]

      此组合维护的是叶页面进入Hash Index时使用的索引键值前缀组合。在将页面从Hash索引删除时，需要根据此组合构建Hash值删除hash索引项；若此组合与buffer header上的[n_fields, n_bytes]组合不同，并且满足了页面重新进入Hash索引的条件，则按照新的[n_fields, n_bytes]组合计算Hash值，维护页面的hash索引。

 

继续阅读 →

发表在 InnoDB, MySQL Server, 数据库 | 标签为 , , , , , | 留下评论