锐客网

  1. 首页 > 睿知 > it技术 > >

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

IT技术队员


在检查过所有诊断数据之后 接下来的任务就很明显了 测量出什么导致了I/O 消耗 不幸的是 客户当前使用的GNU/Linux 版本对此的支持不力 通过一些工作我们可以做一些相对准确的猜测 但首先还是需要探索一下其他的可能性 我们可以测量有多少I/O来自MySQL 但客户使用的MySQL 版本较低以致缺乏一些诊断功能 所以也无法提供确切有利的支持
作为替代 基于我们已经知道MySQL 如何使用磁盘 我们来观察MySQL 的I/O 情况 通常来说 MySQL 只会写数据 日志 排序文件和临时表到磁盘 从前面的状态计数器和其他信息来看 首先可以排除数据和日志的写入问题 那么 只能假设MySQL 突然写入大量数据到临时表或者排序文件 如何来观察这种情况呢？有两个简单的方法 一是观察磁盘的可用空间 二是通过lsof 命令观察服务器打开的文件句柄 这两个方法我们都采用了 结果也足以满足我们的需求 下面是问题期间每秒运行df–h 的结果
下面则是lsof 的数据 因为某些原因我们每五秒才收集一次 我们简单地将mysqld 在/tmp 中打开的文件大小做了加总 并且把总大小和采样时的时间戳一起输出到结果文件中
$ awk
/mysqld *tmp/ {
total += $ ;
}
/^Sun Mar /total {
printf %s % f MB\n $ total/ / ;
total = ;
} lsof txt
: : MB
: : MB
: : MB
: : MB
: : MB
从这个数据可以看出 在问题之初MySQL 大约写了 GB 的数据到临时表 这和之前在SHOW PROCESSLIST 中有大量的 Copying to tmp table 相吻合 这个证据表明可能是某些效率低下的查询风暴耗尽了磁盘资源 根据我们的工作直觉 出现这种情况比较普遍的一个原因是缓存失效 当memcached 中所有缓存的条目同时失效 而又有很多应用需要同时访问的时候 就会出现这种情况 我们给开发人员出示了部分采样到的查询 并讨论这些查询的作用 实际情况是 缓存同时失效就是罪魁祸首（这验证了我们的直觉） 一方面开发人员在应用层面解决缓存失效的问题 另一方面我们也修改了查询 避免使用磁盘临时表 这两个方法的任何一个都可以解决问题 当然最好是两个都实施
返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
lishixinzhi/Article/program/MySQL/201311/29695
高性能MySQL：剖析单条查询（3）[1]剖析单条查询（ ）
从结果可以看到该查询使用了三个临时表 其中两个是磁盘临时表 并且有很多的没有用到索引的读操作（Handler_read_rnd_next） 假设我们不知道这个视图的具体定义 仅从结果来推测 这个查询有可能是做了多表关联（join）查询 并且没有合适的索引 可能是其中一个子查询创建了临时表 然后和其他表做联合查询 而用于保存子查询结果的临时表没有索引 如此大致可以解释这样的结果
使用这个技术的时候 要注意SHOW STATUS 本身也会创建一个临时表 而且也会通过句柄操作访问此临时表 这会影响到SHOW STATUS 结果中对应的数字 而且不同的版本可能行为也不尽相同 比较前面通过SHOW PROFILES 获得的查询的执行计划的结果来看 至少临时表的计数器多加了
你可能会注意到通过EXPLAIN 查看查询的执行计划也可以获得大部分相同的信息 但EXPLAIN 是通过估计得到的结果 而通过计数器则是实际的测量结果 例如 EXPLAIN 无法告诉你临时表是否是磁盘表 这和内存临时表的性能差别是很大的 附录D 包含更多关于EXPLAIN 的内容
使用慢查询日志
那么针对上面这样的查询语句 Percona Server 对慢查询日志做了哪些改进？下面是 使用SHOW PROFILE 一节演示过的相同的查询执行后抓取到的结果

推荐阅读


上一篇：Java代码实现顺序栈，java顺序表代码

下一篇：外国德州直播平台，外国线上德州