《High Performance MySQL》真是本经典好书,从应用层到数据库到硬件平台,各种调优技巧、常见问题全都有所提及。数据库的各种概念技巧平时都有接触,像索引、分区、Sharding等等,但要想真正提高还是得如此系统学习一下。

Chapter 1: MySQL Architecture and History


1.1 Transaction Isolation Level

事务隔离级别真是个老生常谈的问题的,但大多材料一提到脏读、幻读、重复读就讲得云里雾里,所以还是自己动手实践能体会最深。推荐文章:MySQL数据库事务隔离级别

1.2 Implicit and Explicit Locking

InnoDB默认自动根据事务隔离级别管理锁,同时支持两种标准SQL未提及的显示锁(Explicit Locking):
  • SELECT ... LOCK IN SHARE MODE
  • SELECT ... FOR UPDATE
  • LOCK/UNLOCK TABLES
InnoDB采用两阶段锁协议(Two-phase Locking Protocol)。在事务内任意时刻加锁,最后提交或回滚时一起释放所有锁。两阶段锁协议(跟分布式事务XA的两阶段提交)具体如下:
“一次性锁协议:事务开始时,一次性申请所有的锁,之后不会再申请任何锁。如果其中某个锁不可用,则整个申请就不成功,事务就不会执行,在事务尾端,一次性释放所有的锁。一次性锁协议不会产生死锁的问题,但事务的并发度不高。
“两阶段锁协议:整个事务分为两个阶段,前一个阶段为加锁,后一个阶段为解锁。在加锁阶段,事务只能加锁,也可以操作数据,但不能解锁。直到事务释放第一个锁,就进入解锁阶段,此过程中事务只能解锁,也可以操作数据,不能再加锁。
     两阶段锁协议使得事务具有较高的并发度,因为解锁不必发生在事务结尾。它的不足是没有解决死锁的问题,因为它在加锁阶段没有顺序要求。如两个事务分别申请了A, B锁,接着又申请对方的锁,此时进入死锁状态。

1.3 Multiversion Concurrency Control

类似于乐观锁机制,但一些文章介绍到InnoDB实现不是纯粹的MVCC。先标注一下,回头进行深入源码研究。收藏文章:何登成的InnoDB多版本(MVCC)实现简要分析,老码农的MySQL中的MVCC
“Innodb的实现真算不上MVCC,因为并没有实现核心的多版本共存,undo log中的内容只是串行化的结果,记录了多个事务的过程,不属于多版本共存。但理想的MVCC是难以实现的,当事务仅修改一行记录使用理想的MVCC模式是没有问题的,可以通过比较版本号进行回滚;但当事务影响到多行数据时,理想的MVCC据无能为力了。
“理想MVCC难以实现的根本原因在于企图通过乐观锁代替二段提交。修改两行数据,但为了保证其一致性,与修改两个分布式系统中的数据并无区别,而二提交是目前这种场景保证一致性的唯一手段。二段提交的本质是锁定,乐观锁的本质是消除锁定,二者矛盾,故理想的MVCC难以真正在实际中被应用,Innodb只是借了MVCC这个名字,提供了读的非阻塞而已


Chapter 4: Optimizing Schema and Data Types


4.1 Choosing Optimal Data Types

本章一上来就精辟的提出了关于模式和数据类型的总设计原则,那就是:
  1. Smaller is usually better(越小通常越好):因为占用更少磁盘空间,内存以及CPU缓存,所以越小通常代表越快。
  2. Simple is good(简单的就是好的):因为字符集和排序规则(Collation)使得字符串的比较很复杂,所以我们应当用Integer等内建类型而非字符串来保存日期时间或IP地址。
  3. Avoid NULL if possible(尽可能避免NULL):MySQL对NULL有特殊的处理逻辑,所以NULL会使索引、索引统计、值比较都变得更加复杂。
4.2 Using ENUM Instead Of A String Type

MySQL内部将枚举保存为整数,通过一张Lookup Table保存枚举与整数的对应关系。所以使用枚举非常节省空间(原则1越小越好越快),根据枚举总个数而定,只会占用1或2个字节。
但是随之而来的问题是:添加删除枚举值都要ALTER TABLE。并且使用Lookup Table进行转换时也会有开销,尤其是与CHAR或VARCHAR类型的列做联接时,但有时这种开销可以被枚举节省空间的优势所抵消。

4.3 Cons of A Normalized Schema

规范化范式(Normalized Schema)不仅增加JOIN数,并且会使本可以属于一个索引的列分隔到不同的表中。
例如:SELECT ... FROM message INNER JOIN user USING(user_id)
     WHERE user.account_type = 'premium'
     ORDER BY message.published DESC LIMIT 10
则有两种执行计划:
  1. 倒序走published索引扫描message表,每行都去user表检查是否type为'premium',直到找到10行。
  2. 走account_type索引扫描user表找到所有type为'premium'的行,进行filesort后返回10行。

上面的问题本质在于:JOIN使我们无法通过一个索引就同时完成排序和过滤
改为非规范化 => SELECT .. FROM user_message 
     WHERE account_type = 'premium'
     ORDER BY published DESC LIMIT 10
则(account_type, published)上的索引能高效地完成任务!

4.4 Cache and Summary Tables

这一部分紧接上面关于Normalized和Denormalized Schema的Pros and Cons的讨论,从4.4到4.6提出了几种冗余数据的常用且实用的方法。这几种技术本质上都是为了加速查询操作,但代价是拖慢了写操作,并且会增加开发的复杂度。

缓存表(Cache Table)指那些包含能够轻松从Schema中获得的数据的表,即表中的数据是逻辑冗余(Logically Redundant)。汇总表(Summary/Roll-up Table)是说包含通过聚合函数得到的数据的表,例如表中数据是通过GROUP BY得到的。

为什么需要它们呢?最常见的场景就是报表等统计工作。生成这些统计数据要扫描大量数据,实时计算成本很高且很多时候没有必要。而且查询这些数据还要加大量组合索引(各种维度的)才能提高性能,然而这些索引又会对平时的更新和插入等操作造成影响。于是常用技术就是添加中间表到其他引擎(利用MyISAM更小的索引和全文检索能力),甚至其他系统(Lucene或Sphinx)。

有了中间表作为缓存,我们需要定期的更新或者重建它。影子表(Shadow Table)是一种不错的技术!
mysql> DROP TABLE IF EXISTS my_summary_new, my_summary_old;
mysql> CREATE TABLE my_summary_new LIKE my_summary;
mysql> RENAME TABLE my_summary TO my_summary_old, my_summary_new TO my_summary
只需一条rename操作,我们就可以原子地将影子表替换上去(swap with an atomic rename),并且之前的表也保留下来以防需要回滚。

4.5 Materialized Views

物化视图即预先计算并真正存储在磁盘上的视图(一般视图是不会实际存储,在访问视图时执行对应的SQL获得数据)。MySQL没有物化视图,但有一个很棒的开源实现Flexviews Tools。它有一些很有用的功能,例如:
  1. CDC(Change Data Capture)工具能够读取日志(Binary Logs),并提取对应的行变化。
  2. 一组帮助定义和管理视图的存储过程
  3. 将改变反应到物化视图数据上的工具
具体来说,它利用基于行的日志(Row-based Binary Log)包含了变化行的前后数据,所以Flextviews能够在无需访问源表的情况下,知道变化前和变化后的数据,并重新计算物化视图。这是它相比我们自己维护的Cache表或Summary表的优势。

4.6 Counter Tables

Web应用一个常见问题就是并发访问计数表,此书中提出方案来提高并发量。总体设计思路是:添加更多的槽来分散并发的访问。与Java的Concurrent并发包中的ConcurrentHashMap的设计理念有些像。

计数表和对应访问SQL可以简化如下:
mysql> CREATE TABLE hit_counter(cnt int unsigned not null) ENGINE=InnoDB;
mysql> UPDATE hit_counter SET cnt = cnt + 1;

可以看出,表中的一行计数器数据其实相当于全局锁,对它的更新将会被串行化。所以,首先建表时加入Slot一列。并初始化100条数据。
CREATE TABLE hit_counter(
     slot tinyint unsigned not null primary key,
     cnt int unsigned not null
) ENGINE=InnoDB;

之后将更新和查询SQL改为:
mysql> UPDATE hit_counter SET cnt = cnt + 1 WHERE slot = RAND() * 100;
mysql> SELECT SUM(cnt) FROM hit_counter;

ps:如果需要每天刷新计数器的话,那么建表时就加入时间列:
CREATE TABLE daily_hit_counter(
     day date not null,
     slot tinyint unsigned not null primary key,
     cnt int unsigned not null,
     primary key(day, slot)
) ENGINE=InnoDB;

pss:如果不想每天都插入初始数据的话,可以用下面的SQL:
mysql> INSERT INTO daily_hit_counter(day, slot, cnt) 
     VALUES(CURRENT_DATE, RAND() * 100, 1)
     ON DUPLICATE KEY UPDATE cnt = cnt + 1;

psss:如果想减少计数器的行数来节约空间,那么可以执行一个定期任务来合并所有记录到Slot 0:


Chapter 5: Indexing for High Performance


5.1 B-Tree Family

一般我们讨论数据库索引时,其实指的都是B树索引,MySQL的CREATE TABLE及其他语句中也的确使用这种说法。然而实际上,存储引擎内部可能会使用不同的存储结构。例如NDB使用T树(关于不同的索引类型,在我的另一篇介绍内存数据库中也有所提及。T树就非常适合内存存储),而InnoDB使用B+树。


所以准确地说我们使用的是B树大家族里B树的各种变形。各种变形的核心是围绕着内结点出度(例如基于内存的T树和基于磁盘的B树)、存储使用率(B树和B+树)等方面进行的。

首先B树与其他数据结构如红黑树、普通AVL树的最大区别就是:B树的结点有很多个子结点。而这一点正是为减少磁盘I/O读取开销而设计。因为子结点很多,所以树的总体高度很低,这样就只需加载少量的磁盘页就能查找到目标数据。那关于B树和B+树的区别呢:B+树的内结点不存data(即指向key所在数据行的指针),只存key。
B+树的优势:
  • 因为内部结点不存data了,所以在一个磁盘页上能存更多的key了,树的高度进一步降低,从而加快key的查找命中。
  • 需要全树遍历时(如某字段的范围查询甚至full scan,这都是很常见而频繁的查询操作),只需要对B+树的叶子结点进行线性遍历即可,而B树则需要树遍历。而线性遍历比树遍历命中率更高(因为相邻数据都很近,不会分散在结点的左右子树中,跨页的概率能低一些吧)
B树的优势:
  • 在B树中查找可能在内部结点结束,而B+树则必须在叶子结点结束。



首先引用一个B树查找的例子

“下面,咱们来模拟下查找文件29的过程:
  1. 根据根结点指针找到文件目录的根磁盘块1,将其中的信息导入内存。【磁盘IO操作 1次】
  2. 此时内存中有两个文件名17、35和三个存储其他磁盘页面地址的数据。根据算法我们发现:17<29<35,因此我们找到指针p2。
  3. 根据p2指针,我们定位到磁盘块3,并将其中的信息导入内存。【磁盘IO操作 2次】
  4. 此时内存中有两个文件名26,30和三个存储其他磁盘页面地址的数据。根据算法我们发现:26<29<30,因此我们找到指针p2。
  5. 根据p2指针,我们定位到磁盘块8,并将其中的信息导入内存。【磁盘IO操作 3次】
  6. 此时内存中有两个文件名28,29。根据算法我们查找到文件名29,并定位了该文件内存的磁盘地址。

分析上面的过程,发现需要3次磁盘IO操作和3次内存查找操作。关于内存中的文件名查找,由于是一个有序表结构,可以利用折半查找提高效率。至于IO操作是影响整个B树查找效率的决定因素。当然,如果我们使用平衡二叉树的磁盘存储结构来进行查找,磁盘4次,最多5次,而且文件越多,B树比平衡二叉树所用的磁盘IO操作次数将越少,效率也越高。


而B+树就是这个样子:
 


《高性能MySQL》读书笔记(上)的更多相关文章

  1. 编写可维护的Javascript读书笔记

    写在前面:之前硬着头皮参加了java方面的编程规范培训,收货良多,工作半年有余的时候,总算感觉到一丝丝Coding之美,以及造轮子的乐趣,以至于后面开发新功能的时候,在Coding style方面花了 ...

  2. 《编写可维护的JavaScript》 笔记

    <编写可维护的JavaScript> 笔记 我的github iSAM2016 概述 本书的一开始介绍了大量的编码规范,并且给出了最佳和错误的范例,大部分在网上的编码规范看过,就不在赘述 ...

  3. 编写可维护的javascript阅读笔记

    格式 变量 变量命名, 采取小驼峰大小写 变量使用名词, 函数前缀为动词 局部变量应统一定义在函数的最上面, 而不是散落在函数的任意角落. 赋初始值的定义在未赋初始值的变量的上面. 我个人建议不使用单 ...

  4. 读《编写可维护的javascript》笔记

    第一章 基本的格式化 缩进层级:推荐 tab:4; 换行:在运算符后面换行,第二行追加两个缩进: // Good: Break after operator, following line inden ...

  5. 《编写可维护的javascript》读书笔记(上)

    最近在读<编写可维护的javascript>这本书,为了加深记忆,简单做个笔记,同时也让没有读过的同学有一个大概的了解. 一.编程风格 程序是写给人读的,所以一个团队的编程风格要保持一致. ...

  6. 《编写可维护的javascript》读书笔记(中)——编程实践

    上篇读书笔记系列之:<编写可维护的javascript>读书笔记(上) 上篇说的是编程风格,记录的都是最重要的点,不讲废话,写的比较简洁,而本篇将加入一些实例,因为那样比较容易说明问题. ...

  7. 【读书笔记】读《编写可维护的JavaScript》 - 编程实践(第二部分)

    本书的第二个部分总结了有关编程实践相关的内容,每一个章节都非常不错,捡取了其中5个章节的内容.对大家组织高维护性的代码具有辅导作用. 5个章节如下—— 一.UI层的松耦合 二.避免使用全局变量 三.事 ...

  8. 编写可维护的JavaScript代码(部分)

    平时使用的时VS来进行代码的书写,VS会自动的将代码格式化,所有写了这么久的JS代码,也没有注意到这些点.看了<编写可维护的javascript代码>之后,做了些笔记. var resul ...

  9. 推荐一本好书:编写可维护的JavaScript(可下载)

    目录 推荐一本好书:编写可维护的JavaScript(可下载) 书摘: 下载: 有些建议: 推荐一本好书:编写可维护的JavaScript(可下载) 书摘: 很多设计模式就是为了解决紧耦合的问题.如果 ...

  10. 拯救一切强迫症 - 读《编写可维护的 JavaScript》(一)

    拯救一切强迫症 - 读<编写可维护的 JavaScript>(一) 本文写于 2020 年 4 月 24 日 我在小学的时候就有接触过编程,所以读大一的时候 C 语言还算是轻车熟路.自然会 ...

随机推荐

  1. [JLOI2015]管道连接

    题目描述 小铭铭最近进入了某情报部门,该部门正在被如何建立安全的通道连接困扰.该部门有 n 个情报站,用 1 到 n 的整数编号.给出 m 对情报站 ui;vi 和费用 wi,表示情报站 ui 和 v ...

  2. 【Codeforces 851D Arpa and a list of numbers】

    Arpa的数列要根据GCD变成好数列. ·英文题,述大意:      给出一个长度为n(n<=5000000)的序列,其中的元素a[i]<=106,然后输入两个数x,y(x,y<=1 ...

  3. [BZOJ]1095 Hide捉迷藏(ZJOI2007)

    一道神题,两种神做法. Description 捉迷藏 Jiajia和Wind是一对恩爱的夫妻,并且他们有很多孩子.某天,Jiajia.Wind和孩子们决定在家里玩捉迷藏游戏.他们的家很大且构造很奇特 ...

  4. python dataframe数据条件筛选

    一般情况下我们从一堆数据中选择我们获取想要的数据会通过一下方式: (1)创建链表或数组: (2)用for 循环遍历所有数据,将想要的存入链表或数组. 但是python中我们不需要这么做,我们可以用Pa ...

  5. Linux(CentOs6.3)网络配置

    新装好的虚拟机往往还无法连接网络,本文描述了如何在CentOs6.3系统上配置网络信息 1.windows系统下快捷键windows+r,输入cmd并确定,打开黑窗口 2.黑窗口中输入ipconfig ...

  6. 安装yum源和gcc编译器遇到的问题

    这两天我试着在VMware虚拟机里安装gcc,遇到了不少问题 1.   安装yum源 我搭建的是光盘yum源(有两种方法搭建yum源,另外一种是网络yum源,但至今没弄懂我的网络yum源为什么不成功) ...

  7. centos7 支持中文显示

    http://www.linuxidc.com/Linux/2017-07/145572.htm这篇文章比较全.我印证了一下,没有问题 centos7的与centos6有少许不同: 1.安装中文包: ...

  8. 数据结构之并查集Union-Find Sets

    1.  概述 并查集(Disjoint set或者Union-find set)是一种树型的数据结构,常用于处理一些不相交集合(Disjoint Sets)的合并及查询问题. 2.  基本操作 并查集 ...

  9. mysql常见的优化需要注意的点

    1.explain分析explian引用索引基数show indexes from table_name;主键索引具有最好的基数 测试时 不走缓存SELECT SQL_NO_CACHE id from ...

  10. zookeeper工作机制

    Zookeeper Zookeeper概念简介: Zookeeper是为用户的分布式应用程序提供协调服务的 zookeeper是为别的分布式程序服务的 Zookeeper本身就是一个分布式程序(只要有 ...