2014中华架构师大会蓄势待发

会议官网

【大会介绍】
中华架构师大会又将与大家见面了!

2014年11月15日-16日,上海长城假日酒店,我们诚挚地欢迎您的参加!

自2010年11月首次举办以来,大会云集了国内水平最高的IT架构师、技术总监、项目经理、运维总监/经理、DBA经理、研发工程师等IT技术大牛,由最初的百人规模扩展到现今超千人的技术饕餮盛宴。大会一直受到业界广泛关注与赞誉,是目前华东与华南地区最受欢迎、人气最高的架构师技术交流盛会。本次大会将继续秉承分享IT最佳应用实践的宗旨,以“发现架构之美,实战为王”为主题,邀请国内知名互联网企业的资深架构师和工程师,探讨实下最热门的行业趋势与技术热点,分享架构在企业中的最佳实践。大会关键词:分布式文件系统、大数据、GO语言、自动化、分布式数据库、云计算架构设计等。

欢迎大家踊跃报名参会,大会期间将与各行精英面对面的交流,绝对让您不虚此行。

本届会议官方报名网站:http://meeting.zhdba.com

【大会详情】
会议名称: 2014中华架构师大会
会议时间: 2014年11月15日-16日
会议举办具体地址:上海恒丰路585号 上海广场长城假日酒店
票价: 免费
会议主办方:中华数据库行业协会
联系人:朱颖丹
电话:136 5197 9898
邮箱:zhuyingdan@zhdba.com

【主持人】

MySQL数据库InnoDB存储引擎在线加字段实现原理详解

腾讯互娱内部维护了一个MySQL分支,基于官方5.5.24,实现了类似于Oracle 11g的快速加字段功能,这个分支我们内部称为TMySQL。该功能通过扩展存储格式来实现,原理类似于Oracle 11g,以下介绍下其实现原理。
1. GCS行格式

需要在innodb中实现类似oracle的快速加字段功能,仅仅基于原来的行格式是不行的,必须对其进行扩展。为了保证原MySQL和innodb的兼容性,不改变原存储格式的行为,在线加字段功能是通过新增一种innodb行格式GCS(Game Cloud Storage)来实现,从而避免对其他格式造成影响。

mysqlops-innodb-one

MySQL数据库量化InnoDB group commit的效果

前几天有位开发的同学问了个问题,InnoDB的group commit效果如何?之前说好了回头给看下,结果险些拖过年。

Group commit背景
         InnoDB的redo log的group commit历史比较悠久了(有别于binlog的group commit)。如果设置为1,每次事务提交都至少需要写一次redolog。这对IOPS冲击严重,尤其是在HDD上,直接成为性能瓶颈。
Group commit的基本想法是将多个并发线程对redo的fsync操作合并成1个。具体的过程可以参照这篇

Group commit的效果

         其实效果好不好全看具体场景。这里我们先给出一种直观看结果的方法,然后再举例子分析。

1)       数据
简单表结构

MySQL数据库5.6 explain update一个疑似bug

5.6 的新增特性,允许对DML语句做explain。这下大家高兴了,碰到复杂更新语句(且还造成慢查询)要自己手动改成select语句的日子终于到头了。

饶有兴致的试用了一把,总体感觉不错,不过发现一个bug。

复现    

mysql> create table tb(id int primary key , c int);
Query OK, 0 rows affected (0.01 sec)mysql> insert into tb values(1,1);
Query OK, 1 row affected (0.00 sec)mysql> insert into tb values(2,2);
Query OK, 1 row affected (0.00 sec)mysql> explain select * from tb where id=1;
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
|  1 | SIMPLE      | tb    | const | PRIMARY       | PRIMARY | 4       | const |    1 | NULL |
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
1 row in set (0.00 sec)

mysql> explain update tb   tb set c=2 where id=1;
+—-+————-+——-+——-+—————+———+———+——+——+————-+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+—-+————-+——-+——-+—————+———+———+——+——+————-+
|  1 | SIMPLE      | tb    | range | PRIMARY       | PRIMARY | 4       | NULL |    1 | Using where |
+—-+————-+——-+

 这里我们看到,在explain update的结果中,type=range,并且Extra是Using where。

MySQL数据库的字符集和copy_and_convert 字符集不同导致CPU资源额外消耗

关于copy_and_convert
在对MySQL做业务压力测试的时候,我们在perf结果中发现 copy_and_convert 是一个耗费cpu的操作。这个函数的意思,就是在字符集之间做内容转换。
如果源和目标的字符集相同,就可以直接用memcpy,这显然比做字符集转换(按字节或字长拷贝更快,和节省cpu)

当整个系统是CPU瓶颈时,我们希望能够减少这种cpu消耗。

一次查询涉及的拷贝
如果我们执行一个简单的select语句,会涉及到两部分的内容:metadata和data。MySQL的返回包是能够“自解析”的,也就是说不仅有内容,还有描述信息。这些描述信息我们称为metadata。

在将这两部分信息返回给客户端的时候,就涉及到字符串拷贝,如果源字符集和目标字符集不同,就需要作转换。

MySQL数据库关于一次导入数据提示的MySQL server has gone away

背景

这个问题由一个同事问到的一次导入数据引发。一个很常见的操作,将数据从一个表中dump出来,在用mysql < a.sql的方式导入到另一个库的一个表中。

在执行导入的时候,提示 MySQL server has gone away。在追查的时候突然想到会不会是因为max_allowed_packet太小导致的。将max_allowed_packet改大,确实解决了问题。

本文基于在此之后想到的两个问题:

1、              MySQL server has gone away这个提示很不友好,是不是所有的包超过大小都是报这个?

2、              对于出现这种不友好的错误提示,有什么方法定位原因(而不是靠“突然想到”)?

追查1

数据库的堆表与索引组织表的数据存储格式讨论

数据库的堆表与索引组织表的数据存储格式讨论

汪洋@tiptop(967409) 2012/8/29 21:48:48

InnoDB存储引擎为mysql数据库快速小巧这一特点做的,就是你按有序主键去查找,不要更新主键

 

汪洋@tiptop(967409) 2012/8/29 21:49:57

二级索引的更新,需要overflow segment的问题在rdbms都避免不了吧

文科@EC(101800844) 2012/8/29 22:03:13

不知道分形索引是如何实现的

汪洋@tiptop(967409) 2012/8/29 22:05:31
oracle数据库实现关系型数据库rdbms的来说:大 全 精

MySQL5.6.7-rc index condition pushdown代码解读

对index condition pushdown很感兴趣,并且跟踪代码让自己受益良多,因此就来跟一下相关代码。

看的是mysql5.6.7-rc官方社区版。

 

先说说我对研究MySQL源码的看法:

每个使用MySQL数据库的人都应该看代码吗?不是的,那意味着MySQL数据库的使用门槛太高,几乎不可用;但另一方面,如果看MySQL代码的人多了,意味着有更多的人对MySQL数据库的了解更加深入。能够进一步推动MySQL数据库广泛而恰当地使用,为使用者、相关从业者创造更多的赢利机会和就业机会。

MariaDB数据库5.5.27 HASH JOIN源码解读

MariaDB数据库加入了对HASH JOIN算法的支持,我对HASH JOIN不了解,借此机会学习一下,测试的数据库版本为MariaDB5.5.27。

先是配置文件,这是我为了方便跟踪源码,在windows上建的环境。

 

D:mariadb-5.5.27sqlDebug>more my.ini
[mysqld]
innodb_file_per_table
optimizer_switch='index_condition_pushdown=on'
optimizer_switch='mrr=on'
optimizer_switch='mrr_sort_keys=on'
optimizer_switch='mrr_cost_based=off'
mrr_buffer_size=32M
optimizer_switch='join_cache_incremental=on'
optimizer_switch='join_cache_hashed=on'
optimizer_switch='join_cache_bka=on'
join_cache_level=4

 

MySQL数据库Filesort过程

看mysql源码的收获

•为优化提供理论依据
•为优化提供方向
•学习解决问题的算法和思路

 

filesort algorithm

  • 读取所有需要排序的数据
  • 每行数据
  •     算法1(original):存储排序key和行指针
  •     算法2(modified):存储排序key和select中的字段
  • 每次排序sort_buffer_size能容纳的行数,排序结果写入IO_CACHE对象(不妨称为IO1),本次排序结果的位置信息写入另一个IO_CACHE对象(不妨称为IO2);
  • IO_CACHE超过64k时写入临时文件
  • 当order by有limit n时,只需要把前n条排序结果写入IO_CACHE;
  • 排序KEY长度<=20且排序KEY数量在一千和十万之间时使用radixsort,否则使用quicksort
  • Merge buffer
  • 读取排序结果(算法2直接从临时文件读取结果;算法1从临时文件读取行指针,再从表中读取数据)