从一种 DB 转到另一种 DB 的最初阶段,往往要找自己原来熟悉的工具。拿我自己来说,算是有点 Oracle 的经验,有时被问及 MySQL 优化的东西,就希望找到 MySQL 上类似 Oracle 等待接口或是 SQL Trace 之类的工具,多少有些路径依赖。
Slow Query Log 是 MySQL 的基本 Log 之一。这个优化思路基本上是用 SQL 执行时间 作基准(类似 Oracle 基于等待的优化思想。另外,在 MySQL 中我还没发现根据 逻辑 IO 作基准的方法,这样对于存储层的性能控制就有些不好入手)具体如何操作我就不赘述了。默认情况下,在产品环境中如果临时决定起用该特性是影响可用性的。另外,旧一些的版本时间粒度相对比较大(最小 1 秒钟)。可以通过 Microslow Patch 来解决这个问题(粒度可以到百万分之一秒)。这个 Patch 在开发测试环境也很有用武之地,有些公司的线下开发环境数据不能达到产品环境的规模,如果也把眼光放到抓取执行时间大于 1 秒钟的 SQL 无疑会漏掉很多潜在的问题语句。
在 MySQL 5.0 之后,利用 –log-queries-not-using-indexes 参数可以抓到未使用索引的慢查询。为什么 SQL 没有使用索引,这恐怕是开发 DB 应用的朋友要问的最常见的问题之一。
关于 Slow Query Log 的分析,MySQL 自带有 mysqldumpslow 分析工具,除此之外,也有包装的更好(?)一点的开源工具,比如 MyProfi,以及 Mysql-log-filter。
Sun 收购 MySQL 之后,相信很多人都会对 Dtrace 能否集成到 MySQL 比较感兴趣。其实原来就有人利用 Dtrace 来分析 MySQL 性能问题。不过这个方式门槛还比较高,也没有形成比较清晰的方法论。
网上关于 MySQL 优化的文章汗牛充栋,我这篇就当是读书笔记吧。
–EOF–
http://www.mysqlperformanceblog.com/2007/07/18/microslow-patch-for-5120/
Microslow Patch 链到这儿才是吧
Mysql也有类似于Oracle的sql trace的工具:profile
可以通过set profiling=1打开该功能,然后执行相关sql,
再show profiles,可以看到打开该功能后执行所有sql语句,然后再show profile n,即可看到执行该sql时候的很多信息,包括各种消耗信息。这个功能可以在优化sql的时候起到一定的帮助作用。
似乎不应该漏过这篇文章中提供的“slow query log parser”
http://www.mysqlperformanceblog.com/2006/09/06/slow-query-log-analyzes-tools/
http://hackmysql.com/mysqlsla
我目前在用的是这个。
学习中