最近很多朋友反馈之前开发的 myperf 工具自从增加了 snap 和 report 两个功能升级之后使用起来比以前复杂了，不仅参数选项增加了，还多了一个配置文件，而且还要创建数据库，不是很明白如何使用了。
为了让大家使用起来更方便容易，这里做一个简单的介绍。
- 文件组成
- myperf
myperf工具主程序，可执行python文件
- myperf.cnf
myperf工具的配置文件，用来存放各种配置项以减少命令行输入
- myperf.sql
myperf工具用来存放性能数据的Schema结构创建文件，如果需要使用snap和report功能，就必须要通过此文件创建好Schema用来存放性能数据。当然，如果一直只是使用top模式，那就不需要使用了
- 功能组成
- top
类似于Linux/Unix 下最常用最基本的性能查看工具 top 类似，实时刷新展示数据库中的各项核心性能指标信息
- snap
收集数据库当前各项性能状态数据并存储在数据库中，用于性能分析调优，类似于 Oracle 的 Statspack 的 snapshot功能，目前收集的信息主要是 global status，如果是 MySQL5.5，还会手机Performance Schema 中的部分信息
- report
和上面的snap是相辅相成的，主要是对snap存储的性能数据进行分析，获得性能报告，类似于 Oracle 的 Statspack 的 report 功能。当然，由于数据来源有限，和 Oracle Statspack 相比，还有很大的差距
由于配置文件对于程序运行比较重要，所以这里对配置文件再单独介绍一下。myperf 配置文件模仿 MySQL 的配置文件，也将配置项进行了分组，目前的3个分组分别如下：
- main
用来配置与数据库连接无关的全局控制参数，如interval，mode，event，session等
- source
用来配置被监控的源数据库的连接信息
- target
用来配置存放监控数据的目标数据库连接信息，由于需要存储性能数据，所以这里的配置中还会有一个用来指定存放性能数据的database的参数项
最后，有个好消息宣布，那就是 myperf 迎来了第一位合作者 Leopku，@Leopku
myperf, MySQL, mysqltools, performance, performance tuning
myperf 继 0.1-beta 版发布，可以实时在线显示 MySQL 性能数据并定期刷新之后，最近又增加了计划中的另外两个小功能：
- 定期收集MySQL数据库的性能数据并存储（snapshot） 由于初衷主要是考虑到多台 MySQL 服务器，所以数据会集中存储到一台集中的 MySQL Server中，并没有保存到自身。当然，以后有可能增加这样的功能。
- 根据性能数据的snapshot进行分析并生成report记录到文本文件 目前生成的报表还只能生成纯文本方式，不支持保存在数据库中。且只支持生成相邻两个snapshot的报表，暂不支持人工选择某两个snapshot之间的报表。
除了增加这2个功能外，还在原来的基础上增加了一个可选配置文件。主要是为了减少在命令行输入的内容，毕竟很多时候都在重复输入一些参数。当然，不喜欢配置文件方式的同学，选择不使用配置文件，直接将参数全部在命令行中输入。 由于现在 MySQL 5.5 增加了 Performance Schema，所以新版本中也增加了针对 Performance Schema 数据的收集，比如Event wait，File IO 等，只是目前针对这写数据的分析还比较弱，希望后续能加强一些。 源代码、配置文件以及存储snapshot数据所使用的Schema结构文件都放在 Google Code 上了，可以通过SVN工具匿名方式co出来，也欢迎猛击下载试用。 至此，之前设想的基本功能已经完成的差不多了，我的代码写的比较糙，有兴趣进一步完善的同学，欢迎 Gmail 给 sky000，一起维护完善这个小工具。
myperf, MySQL, mysqltools, performance, performance tuning
一直苦恼于 MySQL 没有像 Oracle Statspack 这样的性能分析工具，调优手段太少。很久以前自己学习 C 的时候，写了个简单的收集分析 MySQL 性能状态数据的小工具，之所以选择用 C 去写，一来是为了熟悉 MySQL 的 C API，熟悉 MySQL 代码，另一方面想捡回早就丢掉的 C 语言知识（后被证明很难实现，哈哈）。
随着 MySQL 5.5的出现，MySQL 新增了 Performance Schema，用于展示一些系统等待事件和性能信息。虽然仍然没有 DBA 最需要的 SQL 执行的信息，但至少比以前仅仅只有一些简单的 status 有了很大的进步。
所以最近又想完善一下这个被我自己称为 MySQL Performance Tool 的工具 “myperf” 。这次选择用较轻量级的脚本来实现，简单快速嘛（其实对我也是刚开始学习的，哈哈）
暂时计划包含以下3个功能：
- 显示实时性能状态 (top mode)
- 对性能状态做snapshot (snap mode)
- 分析性能状态，输出报告 (report mode)
目前暂时先做了第一个功能点，连接到需要查看的数据库后以类似于linux 上 top 命令的方式实时刷新，包括active session 也会输出。
实现比较简陋，当前目标是基本能用就行。下面是输出截图：
欢迎有兴趣和我一起完善这个工具的同学加入和我一起完善他，有兴趣请 gmail 给 sky000。
myperf, MySQL, mysqltools, performance, performance tuning
上个周日，参加上海这边 thinking in lamp 的一个技术交流活动，分享了一下我再 MySQL 数据同步方面的一些想法。主要就是基于 MySQL Replication 做一些开发，来解决我们实际的业务需求与目前原生 MySQL Replication 的功能方面的冲突。
分享 PPT 如下：
数据库 Sharding 目前已经是数据层架构的家常便饭了，随着越来越多的人不断的通过 Sharding 技术来提升数据层的扩展能力，Sharding 本身所带来的各种弊端也开始不断的显露出来了。最近和朋友聊天的时候针对 Sharding 带来的问题做了一些交流，记录之：
- 急于 Sharding，分区键考虑不充分，影响业务发展
Sharding 本身是一个需要慎重对待的事情，尤其是分区键的选择。好的分区键会让整个系统基本上对应用没有影响，但是如果选择了一个不合适的分区键，就可能给应用程序带来巨大的麻烦，甚至让有些功能变得几乎不可实现。因为不合适的分区键可能会让本来需要 分组/排序/连接 的数据被拆分分到不同的物理节点，迫使很多原本在一个 Instance 内部的简单处理都无法完成，不得不让应用程序进行大批量IO运算，反而增大的处理成本。应用程序的开发成本上升了，开发效率下降了，业务发展可能就受阻了。
- 过于 Sharding，单机性能过低，造成节点数量过大，维护成本倍增
从与一些 DBA 朋友们的交流中了解到，过度 Sharding 也是现在非常常见的一个问题。由于 MySQL 的免费，大家就觉得节点的增加成本较低，扩充节点的性价比非常高，因为不用像 Oracle 那样需要按照 CPU 个数来付 Licence 费用嘛。
但事实真的如此吗？可能并不是这么简单。首先，在很多人的意识中，扩展成本只是一个节点的购买成本，而忽略了该节点所占用的IDC资源（机架/电力/布线…）。如果从 IDC 资源角度来考虑，单机性能越高，成本也越低。也就是说节点数越少，IDC 资源消耗也越少（曾今就由朋友说笑：我们使用一台大型机搞定所有业务，成本一定是最低的）。那这就和我们的 Sharding 方向相违背了不是？毕竟单节点的扩展能力一定是有限的嘛，咱也不可能真整一台大型机是吧 
。
除了显性的财务支持成本， Sharding 同时也给运维工作带来了维护成本的增加。节点数多了，需要维护的机器也就增多了，一个节点发生故障的概率也增加了。维护变更的重复工作量增大了，操作失误的可能性也就增大了。所以我们又不得不考虑平衡节点数和单机性能。
这时候我们就不得不考虑，到底我们该 Sharding 到何种程度，才能既有效的提升了Scale Out能力，又能控制总体成本尽可能低。既能让维护成本可控，又能分散可用性故障点。
- 为了 Sharding 而 Sharding
“Sharding 如此流行，要事咱的数据层不做 Sharding，都不好意思见人了”，很多架构师/DBA可能都有此想法。在还没有弄清楚 Sharding 的好处与弊端的时候，在系统都还没有一点压力的时候，甚至都还不清楚为何要 Sharding 的时候就开始做 Sharding 了，最终很可能就将自己埋葬在 Sharding 中了。
