• 编译tcprstat

    在RHEL6.1(Red Hat Enterprise Linux Server)上静态编译并不容易。tcprstat编译也有这个问题。

    源码下载:tcprstat@Launchpad 命令:bzr branch lp:tcprstat

    编译命令:./bootstrap && ./configure && make

    如果顺利的话,就结束了。不过在我的发行版会报如下错误: (more…)

  • 在上上周给下厨房做过一次数据恢复(故障回顾:故障发生的技术总结 致歉信),恢复使用了开源工具Percona Data Recovery Tool for InnoDB(后面简称PDRTI),这里分享一下期间的注意事项,和遇到MySQL数据丢失的一些应对。

    本文主要介绍在使用Percona Data Recovery Tool for InnoDB时候的一些注意事项,并不包括具体的step by step的使用步骤,使用文档可以参考:Reference Manual and Documentation(more…)

  • 在杭州工作

    从那次Z9来杭州,快四年了,最近有两个老同学都问我杭州好不好,去杭州工作怎样之类的,这里说说这四年对杭州的感受吧。都是些主观认识,谨慎参考。

    在北京念书七年,因为种种“机缘巧合”,最终来了杭州。之前从不曾想过会因为工作来杭州,不过也没有想到这个城市给了我这么多惊喜。

    1. 工作在杭州

    先说工作,毕竟是因为这个原因来到这里的。相比北京,杭州的公司是要少很多的,所以工作机会也相对较少。一线的互联网公司,主要就是阿里巴巴和网易杭州研究院,不像北京几乎所有的公司都会在北京有办公地点,阿里在北京也有很大的办公地点。很少有人能够一辈子只在一家公司服务的,所以当打算换工作的时候,这就成为一个劣势了,选择较少,机会也较少。不过如果是电子商务的话,杭州的氛围还是很好的,我所知道的很多人/公司都在做围绕此创业(例如我不喜欢,但是很看好的蘑菇街)。

    当然,杭州工作机会少,这是相对而言,如果不跟北上广深,杭州的工作环境应该也算是非常好的。

    2. 生活在杭州

    hz-1

    在生活方面,如果再跟北京比的话,杭州是分分钟就秒杀了北京。杭州城区不算大,周末如果朋友想聚会的话,一般不会超过半小时的车程,打个牌、吃个饭什么的非常方便。记得刚到杭州那会儿,每隔周五晚上都是有小赌怡情的牌局,现在一个个都结婚生小孩了,聚会的时间少了很多。以前在北京,同学聚会还是比较麻烦的,东西三环就很远了,更别说石景山了,所以北京的同学聚会貌似也基本上跟我去北京出差的频率差不太多,所以总能赶上。杭州周末聚会有更多的选择,可以去龙井/梅家坞/青之坞,环境都非常好,而且离城西也非常近,七八个好友玩个三国杀、吃个饭、爬个山都很惬意。

    如果你喜欢运动,杭州也不会让你失望。西湖几乎四面环山,山不是很高,不过很长,适合周末慢慢爬。登山的路线也有很多,春秋季都很漂亮,很多杭州久住的人都喜欢爬山。 (more…)

  • 本文是一篇写给《HPM 3rd 中文版》的软文,慎入。《HPM 3rd 中文版》已经开始正式发售了,不是预售:亚马逊 china-pub 当当网

    从去年5月开始,与宁海元翟卫祥、彭立勋、刘辉一起利用业余时间,经历了翻译,校对,校对,再校对,交叉校对,再交叉校对,到前两天亚马逊上正式开售(不是预售了),前前后后也历经了大概一年。

    在过去的两三年,MySQL的生态圈发生了很大的变化,出现了MariaDB,Percona/XtraDB等等分支,与官方的版本产生了一些竞争。目前为止这些竞争还是比较良性的,都大大推动了MySQL在各个方面的改进,包括MySQL的性能和新的功能,这期间在社区对于InnoDB的改进(例如XtraDB),推进了MySQL/Oracle快速的推进了InnoDB Plugin的发展;MariaDB在优化器方面也做了很多工作,对应的MySQL/Oracle在5.6之后的版本也做了很多Server层(例如优化器、Group Commit等)的改进。

    虽然经历了收购的风波,但在竞争压力下,过去两三年仍然是MySQL/MariaDB快速发展的时期。08年High Performance MySQL(简称HPM)发布第二版,时隔四年发布了第三版,第三版中新增了分区、视图、存储过程方面的改进,高可用、集群和复制方面的改进,优化器全文索引等改进,SSD和多核CPU利用方面的改进,在线备份和恢复的工具等。是一本非常值得阅读的MySQL书籍。

    对于专注数据库领域的人来说,如果习惯阅读英文版本的,依旧推荐阅读英文版本,在亚马逊上可以买到HPM 3rd影印版的。如果不太习惯阅读英文版本的,我仍然强烈推荐阅读影印版,虽然这样可能会花更多的时间,但是可以大大锻炼一下自己的英文能力,相信你不会因为这个”浪费”时间而后悔的。

    如果,你喜欢阅读中文书籍,或者希望能够快速阅读,那么这次翻译的HPM 3rd会是很好的选择。这次译者都是专业/一线的MySQL DBA或者开发人员,并进行了多次(交叉)校对,是一次高要求、高质量的翻译,不会让你失望。 (more…)

  • 本文通过一个案例来看看MySQL优化器如何选择索引和JOIN顺序。表结构和数据准备参考本文最后部分”测试环境”。这里主要介绍MySQL优化器的主要执行流程,而不是介绍一个优化器的各个组件(这是另一个话题)。

    我们知道,MySQL优化器只有两个自由度:顺序选择;单表访问方式;这里将详细剖析下面的SQL,看看MySQL优化器如何做出每一步的选择。

    explain select * from employee as A,department as B where A.LastName = 'zhou' and B.DepartmentID = A.DepartmentID and B.DepartmentName = 'TBX';

    1. 可能的选择

    这里看到JOIN的顺序可以是A|B或者B|A,单表访问方式也有多种,对于A表可以选择:全表扫描和索引`IND_L_D`(A.LastName = ‘zhou’)或者`IND_DID`(B.DepartmentID = A.DepartmentID)。对于B也有三个选择:全表扫描、索引IND_D、IND_DN。

    2. MySQL优化器如何做

    2.1 概述

    MySQL优化器主要工作包括以下几部分:Query Rewrite(包括Outer Join转换等)、const table detection、range analysis、JOIN optimization(顺序和访问方式选择)、plan refinement。这个案例从range analysis开始。

    2.2 range analysis

    这部分包括所有Range和index merge成本评估(参考1 参考2)。这里,等值表达式也是一个range,所以这里会评估其成本,计算出found records(表示对应的等值表达式,大概会选择出多少条记录)。

    本案例中,range analysis会针对A表的条件A.LastName = ‘zhou’和B表的B.DepartmentName = ‘TBX’分别做分析。其中: (more…)

  • 本文纯属八卦,基本没有任何实用价值。Oracle总是都会通过SQL_ID来标志一个唯一的SQL。SQL_ID与SQL_TEXT一一对应。如果两个SQL文本有任何不同,包括空格等任何不可见字符,都会导致SQL_ID不同。本文八卦的内容是:Oracle如何根据SQL_TEXT内容散列成一个13位的字符串。为什么这个字符串会是13位?为什么这个字符经常以数字开头?

    本文参考TANEL PODER和Slavik的两篇介绍(12),详细介绍转换原理,顺便给出PHP/Perl实现代码。

    0. 概述

    Oracle先计算SQL_TEXT的md5散列值;取散列值的低64位(bits),每次取5位(最后一次4位),使用Base32将其依次转换成可见字符,就是你最终看到的SQL_ID。原理就是这样。

    不过实际转换过程中有一些要注意的事项:

    (a) Oracle在计算md5散列时,会在SQL_TEXT末尾加一个不可见字符\0,AWR报表中经常有这样的SQL_TEXT

    (b) 注意little-endian的问题

    (c) Base32转码的可见字符为0123456789abcdfghjkmnpqrstuvwxyz

    (d) 编写程序的时候需要注意大数精度的问题,本文中Perl/PHP程序都使用了数学大数处理函数 (more…)