【IT168技术文档】目前数据库监控的软件很多，如monyog,mon,mtop,cacti，还有强大的nagios等，但是很多数据库管理员会困惑从何处着手去监控，因为如果只是监控一下慢sql数量，com_select等读写操作的数量值，是很难有效的做到前期捕获表设计，以及sql语句问题的。

　　其实要做好一个全面的数据库监控，首先需要知道监控的目的，这样才能有选择性的去部署监控，所谓工欲善其事，必先利其器。

　　以我为例，因为我是做数据库平台的，大概数据库平台上跑了2百多个产品项目，且项目产品属于公司不同的应用部门，因此就会产生一个数据库实例里面跑好几个不同应用部门的项目库，当出现数据库服务器性能瓶颈或是访问变慢时候，需要去排查数据库时候就会产生很多麻烦，比如一个数据库实例出现大量的com_select操作，但是你要知道是哪个部门的哪个应用在使用，可光知道了是哪个部门在使用，并找到了对应的开发人员，但往往随之而来的就是开发人员会问你，是在什么时间，大概那种类型的sql语句导致的，甚至希望你能提供从哪个机器发起的请求等等一些更细节的问题，这个时候如果没有强大的监控策略，就很容易陷入被动，被开发人员给问僵了。

　　另外还有很多时候，为了能缩短项目的数据库使用申批流程时间，需要授权给开发人员比较大的权限如建表，建索引权限，改表字段权限，使自己从陪同开发人员加班的苦海中解放出来，不过随之带来的问题就是，很多sql缺乏索引，或是一个库下面建了上千个表，或是有的表没规划好，跑到千万rows了。

　　针对上述经常遇到的问题，我做的数据库策略就是，必须要对数据库的读写操作sql进行定时采样抓取(mysql 5.1的话能打开query参数，mysql 5.0的话可以用tcpdump抓取)，当出现某个实例有大量频繁读写异常时候，我就能有目的性的查对应的sql日志存档就能进行分析，找到问题的所在。

　　另外对于表的详细监控可以使用google-patch(http://code.google.com/p/google-mysql-tools/)的补丁来分析rows变化，因为当sql没有加合适索引时候，是会进行全表扫描，从而会使rows_read变的特别大。库和表的状况信息可以通过information_schema这个东东进行分析。(后面我会提供sp_dbdata来汇总)