高性能mysql怎么样 高性能mysql和高可用mysql( 三 )


File: index php Line: Function: fullCachePage request_id: ABC session_id: XYZ
SELECT * FROM …
如何测量MySQL 的调用取决于连接MySQL 的接口 如果使用的是面向对象的mysqli接口 则只需要修改一行代码 将构造函数从mysqli 改为可以自动测量的mysqli_x 即可 mysqli_x 构造函数是由Ifp 提供的子类 可以在后台测量并改写查询 如果使用的不是面向对象的接口 或者是其他的数据库访问层 则需要修改更多的代码 如果数据库调用不是分散在代码各处还好 否则建议使用集成开发环境(IDE)如Eclipse 这样修改起来要容易些 但不管从哪个方面来看 将访问数据库的代码集中到一起都可以说是最佳实践
Ifp 的结果很容易分析 Percona Toolkit 中的pt query digest 能够很方便地从查询注释中抽取出键值对 所以只需要简单的将查询记录到MySQL 的日志文件中 再对日志文件进行处理即可 Apache 的mod_log_config 模块可以利用Ifp 输出的环境变量来定制日志输出 其中的宏%D 还可以以微秒级记录请求时间
也可以通过LOAD DATA INFILE 将Apache 的日志载入到MySQL 数据库中 然后通过SQL 进行查询 在Ifp 的网站上有一个PDF 的幻灯片 详细给出了使用示例 包括查询和命令行参数都有
或许高性能mysql怎么样你会说不想或者没时间在代码中加入测量的功能 其实这事比想象的要容易得多 而且花在优化上的时间将会由于性能的优化而加倍地回报给你 对应用的测量是不可替代的 当然最好是直接使用New Relic xhprof Ifp 或者其他已有的优化工具 而不必重新去发明 轮子
MySQL 企业监控器的查询分析功能
MySQL 的企业监控器(Enterprise Monitor)也是值得考虑的工具之一 这是Oracle 提供的MySQL 商业服务支持中的一部分 它可以捕获发送给服务器的查询 要么是通过应用程序连接MySQL 的库文件实现 要么是在代理层实现(我们并不太建议使用代理层) 该工具有设计良好的用户界面 可以直观地显示查询的剖析结果 并且可以根据时间段进行缩放 例如可以选择某个异常的性能尖峰时间来查看状态图 也可以查看EXPLAIN 出来的执行计划 这在故障诊断时非常有用
【高性能mysql怎么样 高性能mysql和高可用mysql】返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
lishixinzhi/Article/program/MySQL/201311/29717
高性能MySQL:一个诊断案例(3)一个诊断案例( )
我们看到了两种可能性 要么是数据库导致了I/O(如果能找到源头的话 那么可能就找到了问题的原因) 要么不是数据库导致了所有的I/O 而是其他什么导致的 而系统因为缺少I/O 资源影响了数据库性能 我们也很小心地尽力避免引入另外一个隐式的假设 磁盘很忙并不一定意味着MySQL 会有问题 要记住 这个服务器主要的压力是内存读取 所以也很可能出现磁盘长时间无法响应但没有造成严重问题的现象
如果你一直跟随我们的推理逻辑 就可以发现还需要回头检查一下另外一个假设 我们已经知道磁盘设备很忙 因为其等待时间很高 对于固态硬盘来说 其I/O 平均等待时间一般不会超过 / 秒 实际上 从iostat 的输出结果也可以发现磁盘本身的响应还是很快的 但请求在块设备队列中等待很长的时间才能进入到磁盘设备 但要记住 这只是iostat 的输出结果 也可能是错误的信息
究竟是什么导致了性能低下?
当一个资源变得效率低下时 应该了解一下为什么会这样 有如下可能的原因
资源被过度使用 余量已经不足以正常工作
资源没有被正确配置
资源已经损坏或者失灵
回到上面的例子中 iostat 的输出显示可能是磁盘的工作负载太大 也可能是配置不正确(在磁盘响应很快的情况下 为什么I/O 请求需要排队这么长时间才能进入到磁盘?) 然而 比较系统的需求和现有容量对于确定问题在哪里是很重要的一部分 大量的基准测试证明这个客户使用的这种SSD 是无法支撑几百MB/s 的写操作的 所以 尽管iostat 的结果表明磁盘的响应是正常的 也不一定是完全正确的 在这个案例中 我们没有办法证明磁盘的响应比iostat 的结果中所说的要慢 但这种情况还是有可能的 所以这不能改变我们的看法 可能是磁盘被滥用注 或者是错误的配置 或者两者兼而有之 是性能低下的罪魁祸首

推荐阅读