工作以来都在接触Linux和Unix系统，所以对这两类系统用的多，也比较熟悉。渐渐的，Shell中的快捷键也运用自如，一次朋友看到我快捷的操作shell命令，很好奇的建议，什么时候教教他这些快捷方式。特撰写此文，来提高大家的工作效率和保护你们的键盘。

下述所有命令在Linux/unix的shell下有效，这里以bash为主。如有出入，以你自己的操作系统为准。

开始描述之前，先问几个常见的问题。

例如你在终端中输入了下面的这个find命令：

      » 继续阅读 Shell 快捷键助你一臂之力

Q3:
求100！乘积是多少。

A3:
正常情况下，大部分人使用循环语句。实际上可以 是：
seq -s ‘*’ 100 | bc
这个命令很好的利用了seq和bc这两个命令。bc处理运算。

Q4：
怎么用touch同时创建100个文件？

A4：
起先我想到了，seq 1 100 | touch来处理。发现touch不能这样接收参数。但是加xargs就可以处理，也可以使用
touch `seq 1 100`来处理。

Infobright是一款开源列式数据仓库引擎，采用他们自己的Knowledge Grid架构（一直没有明白这两个单词），该引擎采取内部管理自身优化查询的方式，给用户带来更为轻松的体验。我们所要做的就是写出“漂亮”的SQL，后面我会关于SQL语句说点有趣的东西。

Infobright像很多优秀的开源软件一样，也都具有两个版本，社区版（ICE）和企业版（IEE），多数情况下，如果免费的能满足我们的实际需求，领导更愿意采用社区版；企业版需要付费，那么自然就会给用户提供更加完善的功能、保证运行的稳定性以及良好的后期服务。下面具体介绍一下Infobright在我的实际环境中的应用。
      » 继续阅读 列式数据仓库引擎之Infobright

端午节到了，3天的假期可以好好放松下紧张了又一个月的神经，同时也可以总结一下近期的工作；遗憾的是，自从工作了就再也没能吃到老妈包的粽子了（姜米配上红豆、花生、大红枣，我的最爱）。

DBA的工作不知不觉已经经历了第二个月，比第一个月更加“凶险”——死里逃生（未知），我似乎成为了运维部的【问题焦点】，信任、仔细、积极、能力、诚实等等属性都面临着各方面的考验。曾经一度想逃离，工作的郁闷，自己内心的沉重，问题冒呀冒；我怕，真的开始怕了，怕打开终端执行每一条命令，怕后面又有什么问题在等着我，怕看到同事质问眼神，怕被领导冰冷的气场所笼罩，一点都不夸张，我甚至开始恐惧去公司，那个让我压抑的舞台，尽管我喜欢这份工作。第一次体会到工作带给我这么多的感受。庆幸的是，我坚挺了下来，学着慢慢调整心态；世界杯的到来也让我心情放松了很多，即便被开，也有理由——为了看世界杯休息一个月嘛，毕竟4年才一次，尽情享受一个个美妙和谐的夜晚。（Come on Portugal,Come on C’Ronaldo!）
      » 继续阅读 DBA工作初体验之死里逃生

嗨，大家好，SQL部落很久没有和大家分享新东西了，BBS近期也很少被Google爬来爬去的了。

前端时间刚换了工作，从5月16日开始，我正式成为了一名专职MySQL DBA（还在试用期），开始一段全新的体验。新就意味着有很多很多的工作要做，规范行为，整理思路，协调工作。回头一看一个月已经过去了，从之前没有写过SQL语句到现在平凡的数据统计、客服查询，一次次惊奇sql还可以这样那样，知道有那么多统计|时间|字符等各种有用的函数，开始一点点体会书本上学的索引在实际语句中的使用，是用表连接还是子查询，执行时间的快慢等等。

突然发现一个问题，感觉很明显，就是很多之前从书上学过了解到的知识，工作中并不会很自然地主动地被想起，而是每次就跟新东西一样，都是在同事的提示后，才恍然大悟，“哦，原来这样，其实，很早就知道这个东西的…..”，基本功不扎实呀！好比，渴了自然就会想到喝水。开始的自信与张扬已是消失殆尽，现在的心态就是：踏实、诚恳、谦虚地去学习，努力做好每件事情。

这一个月无论是工作的压力还是心情的波动，都让我体会颇多。第一次感觉到原来工作是有压力的，以及所背负的责任。我是一个很在意别人看法的人，我希望被每个人所认可，所以每次任务都积极去完成，但由于天生性格的急躁，还是总会弄出些岔子来。尽管开始成熟，但还是缺乏稳重。

下面就和大家抖露抖露我这一个月的“风花雪月”。
      » 继续阅读 DBA工作初体验之心惊胆战

此篇博客的存在是鉴于寻找正确解决mysql driver for python 2.6的困难。

今日开始学习将python来作为自己的主要编程语言。以后会和大家多分享一些开发方面的知识。习惯了perl的潇洒和‘放肆’，确有必要看看python。Perl的缺点一直是编写系统变大时，代码越来越难控制。

根据今天的学习来看python结构清晰，模块化思想。还是适合用于编写较大的系统。网上已有许多讨论perl和python比较的文章，这里不再一一复述。

      » 继续阅读 安装Python的MySQL驱动

ZRM(Zmanda For MySQL) 是一个功能丰富的针对于MySQL数据库实施数据备份与恢复的开源工具，其中针对于MySQL数据库社区版的ZRM提供免费下载使用。

下面就来具体介绍ZRM的使用方法和一些注意事项。

工作环境：Fedora 7 + MySQL 5.0.45 + ZRM 2.1.1

安装ZRM: rpm -ivh  MySQL-zrm-2.1.1-1.noarch.rpm

rpm -ivh  perl-XML-Parser-2.36-1.el5.rf.i386.rpm   (ZRM需要的perl模块)

（NOTE: 相关安装文件可以在 http://zmanda.com/download-zrm.php 的提示连接中下载。在安装zrm所需的两个模块perl-DBI和perl-XML-parser的时候折腾了半天，之前想通过CPAN去安装，但是后来发现都安装好了后，rpm去安装zrm的时候始终找不到perl-XML-parser这个模块，最后折腾半天还是安装上面连接中提示的地方下了一个rpm版的安装包，之后就没有问题了。）
      » 继续阅读 Zmanda让MySQL的备份与恢复更加方便快捷灵活

本文源于最近mysqlperformance上的一篇blog。
文章主要讨论了一个误区：key cache hit ratio 并不能作为key-buffer-size的调优依据。
内容并不复杂，但是传递的思想值得借鉴：调优过程中各种假设会导致最终结论的错误。

原文链接：Why you should ignore MySQL’s key cache hit ratio
正文：（翻译加个人总结）

错误的传统观念：
通过show global status 得到 Key_reads，Key_read_requests的值。Key_buffer_miss_ratio = Key_reads/Key_read_requests. 从而得到索引缓存的miss比率。一般建议这个比率应该小于1:100，否则说明key_buffer_size设置过小，需要调整。
再看一下mysql官方文档对这两个参数的解释：
Key_read_requests：The number of requests to read a key block from the cache.
Key_reads：The number of physical reads of a key block from disk.
可见这样的算法并没有错误。

但是！Key_buffer_miss_ratio真的能作为调优的依据吗？不能！

      » 继续阅读 key cache hit ratio的误区