高性能mysql怎么样 高性能mysql和高可用mysql

高性能MySQL：测试何种指标

测试何种指标

在开始执行甚至是在设计基准测试之前 需要先明确测试的目标 测试目标决定了选择什么样的测试工具和技术 以获得精确而有意义的测试结果 可以将测试目标细化为一系列的问题 比如 这种CPU 是否比另外一种要快？ 或 新索引是否比当前索引性能更好？

有时候需要用不同的方法测试不同的指标 比如 针对延迟（latency）和吞吐量（throughput）就需要采用不同的测试方法

请考虑以下指标 看看如何满足测试的需求

吞吐量

吞吐量指的是单位时间内的事务处理数 这一直是经典的数据库应用测试指标 一些标准的基准测试被广泛地引用 如TPC C（参考// tpc ） 而且很多数据库厂商都努力争取在这些测试中取得好成绩 这类基准测试主要针对在线事务处理（OLTP）的吞吐量 非常适用于多用户的交互式应用 常用的测试单位是每秒事务数（TPS） 有些也采用每分钟事务数（TPM）

响应时间或者延迟

这个指标用于测试任务所需的整体时间 根据具体的应用 测试的时间单位可能是微秒 毫秒 秒或者分钟 根据不同的时间单位可以计算出平均响应时间 最小响应时间 最大响应时间和所占百分比 最大响应时间通常意义不大 因为测试时间越长 最大响应时间也可能越大 而且其结果通常不可重复 每次测试都可能得到不同的最大响应时间 因此 通常可以使用百分比响应时间（percentile responsetime）来替代最大响应时间 例如 如果 % 的响应时间都是 毫秒 则表示任务在 % 的时间段内都可以在 毫秒之内完成

使用图表有助于理解测试结果 可以将测试结果绘制成折线图（比如平均值折线或者 % 百分比折线）或者散点图 直观地表现数据结果集的分布情况 通过这些图可以发现长时间测试的趋势 本章后面将更详细地讨论这一点

并发性

并发性是一个非常重要又经常被误解和误用的指标 例如 它经常被表示成多少用户在同一时间浏览一个Web 站点 经常使用的指标是有多少个会话注 然而 HTTP协议是无状态的 大多数用户只是简单地读取浏览器上显示的信息 这并不等同于Web 服务器的并发性 而且 Web 服务器的并发性也不等同于数据库的并发性 而仅仅只表示会话存储机制可以处理多少数据的能力 Web 服务器的并发性更准确的度量指标 应该是在任意时间有多少同时发生的并发请求

在应用的不同环节都可以测量相应的并发性 Web 服务器的高并发 一般也会导致数据库的高并发 但服务器采用的语言和工具集对此都会有影响 注意不要将创建数据库连接和并发性搞混淆 一个设计良好的应用 同时可以打开成百上千个MySQL 数据库服务器连接 但可能同时只有少数连接在执行查询 所以说 一个Web 站点 同时有 个用户 访问 却可能只有 ～ 个并发请求到MySQL 数据库

换句话说 并发性基准测试需要关注的是正在工作中的并发操作 或者是同时工作中的线程数或者连接数 当并发性增加时 需要测量吞吐量是否下降 响应时间是否变长 如果是这样 应用可能就无法处理峰值压力

并发性的测量完全不同于响应时间和吞吐量 它不像是一个结果 而更像是设置基准测试的一种属性 并发性测试通常不是为了测试应用能达到的并发度 而是为了测试应用在不同并发下的性能 当然 数据库的并发性还是需要测量的 可以通过sy *** ench 指定 或者 个线程的测试 然后在测试期间记录MySQL 数据库的Threads_running 状态值 在第 章将讨论这个指标对容量规划的影响

可扩展性

在系统的业务压力可能发生变化的情况下 测试可扩展性就非常必要了 第 章将更进一步讨论可扩展性的话题 简单地说 可扩展性指的是 给系统增加一倍的工作 在理想情况下就能获得两倍的结果（即吞吐量增加一倍） 或者说 给系统增加一倍的资源（比如两倍的CPU 数） 就可以获得两倍的吞吐量 当然 同时性能（响应时间）也必须在可以接受的范围内 大多数系统是无法做到如此理想的线性扩展的 随着压力的变化 吞吐量和性能都可能越来越差

可扩展性指标对于容量规范非常有用 它可以提供其他测试无法提供的信息 来帮助发现应用的瓶颈 比如 如果系统是基于单个用户的响应时间测试（这是一个很糟糕的测试策略）设计的 虽然测试的结果很好 但当并发度增加时 系统的性能有可能变得非常糟糕 而一个基于不断增加用户连接的情况下的响应时间测试则可以发现这个问题

一些任务 比如从细粒度数据创建汇总表的批量工作 需要的是周期性的快速响应时间 当然也可以测试这些任务纯粹的响应时间 但要注意考虑这些任务之间的相互影响 批量工作可能导致相互之间有影响的查询性能变差 反之亦然

归根结底 应该测试那些对用户来说最重要的指标 因此应该尽可能地去收集一些需求 比如 什么样的响应时间是可以接受的 期待多少的并发性 等等 然后基于这些需求来设计基准测试 避免目光短浅地只关注部分指标 而忽略其他指标

       返回目录 高性能MySQL

       编辑推荐

       ASP NET开发培训视频教程

数据仓库与数据挖掘培训视频教程

lishixinzhi/Article/program/MySQL/201311/29741

相关问答

Q1: 高性能MySQL：测量PHP 应用程序

测量PHP 应用程序

如果不使用New Relic 也有其他高性能mysql怎么样的选择 尤其是对PHP 有好几款工具都可以帮助进行性能剖析 其中一款叫做xhprof（//pecl php net/package/xhprof） 这是Facebook开发给内部使用的 在 年开源高性能mysql怎么样了 xhprof 有很多高级特性 并且易于安装和使用 它很轻量级 可扩展性也很好 可以在生产环境大量部署并全天候使用 它还能针对函数调用进行剖析 并根据耗费的时间进行排序 相比xhprof 还有一些更底层的工具 比如xdebug Valgrind 和cachegrind 可以从多个角度对代码进行检测注 有些工具会产生大量输出 并且开销很大 并不适合在生产环境运行 但在开发环境却可以发挥很大的作用

下面要讨论的另外一个PHP 性能剖析工具是我们自己写的 基于本书第二版的代码和原则扩展而来 名叫IfP（instrumentation for php） 代码托管在Goole Code 上（//code google /p/instrumentation for php/） Ifp 并不像xhprof 一样对PHP 做深入的测量 而是更关注数据库调用 所以当无法在数据库层面进行测量的时候 Ifp 可以很好地帮助应用剖析数据库的利用率 Ifp 是一个提供了计数器和计时器的单例类 很容易部署到生产环境中 因为不需要访问PHP 配置的权限（对很多开发人员来说 都没有访问PHP配置的权限 所以这一点很重要）

Ifp 不会自动剖析所有的PHP 函数 而只是针对重要的函数 例如 对于某些需要剖析的地方要用到自定义的计数器 就需要手工启动和停止 但Ifp 可以自动对整个页面的执行进行计时 这样对自动测量数据库和memcached 的调用就比较简单 对于这种情况就无须手工启动或者停止 这也意味着 Ifp 可以剖析三种情况 应用程序的请求（如page view） 数据库的查询和缓存的查询 Ifp 还可以将计数器和计时器输出到Apache 通过Apache 可以将结果写入到日志中 这是一种方便且轻量的记录结果的方式 Ifp 不会保存其他数据 所以也不需要有系统管理员的权限

使用Ifp 只需要简单地在页面的开始处调用start_request（） 理想情况下 在程序的一开始就应当调用

require_once（ Instrumentation php ）

Instrumentation::get_instance（） start_request（）

这段代码注册了一个shutdown函数 所以在执行结束的地方不需要再做更多的处理

IFP会自动对SQL添加注释 便于从数据库的查询日志中更灵活地分析应用的情况 通过SHOW PROCESSLIST也可以更清楚地知道性能低的查询出自何处 大多数情况下 定位性能低下查询的来源都不容易 尤其是那些通过字符串拼接出来的查询语句 都没有办法在源代码中去搜索 那么IFP的这个功能就可以帮助解决这个问题 它可以很快定位到查询是从何处而来的 即时应用和数据库中间加了代理或者负载均衡层 也可以确认是哪个应用的用户 是哪个页面请求 是源代码中的哪个函数 代码行号 甚至是所创建的计数器的键值对 下面是一个例子

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

       编辑推荐

       ASP NET开发培训视频教程

数据仓库与数据挖掘培训视频教程

lishixinzhi/Article/program/MySQL/201311/29717

Q2: 高性能MySQL：一个诊断案例（3）

一个诊断案例（ ）

我们看到了两种可能性 要么是数据库导致了I/O（如果能找到源头的话 那么可能就找到了问题的原因） 要么不是数据库导致了所有的I/O 而是其他什么导致的 而系统因为缺少I/O 资源影响了数据库性能 我们也很小心地尽力避免引入另外一个隐式的假设 磁盘很忙并不一定意味着MySQL 会有问题 要记住 这个服务器主要的压力是内存读取 所以也很可能出现磁盘长时间无法响应但没有造成严重问题的现象

如果你一直跟随我们的推理逻辑 就可以发现还需要回头检查一下另外一个假设 我们已经知道磁盘设备很忙 因为其等待时间很高 对于固态硬盘来说 其I/O 平均等待时间一般不会超过 / 秒 实际上 从iostat 的输出结果也可以发现磁盘本身的响应还是很快的 但请求在块设备队列中等待很长的时间才能进入到磁盘设备 但要记住 这只是iostat 的输出结果 也可能是错误的信息

究竟是什么导致了性能低下？

当一个资源变得效率低下时 应该了解一下为什么会这样 有如下可能的原因

资源被过度使用 余量已经不足以正常工作

资源没有被正确配置

资源已经损坏或者失灵

回到上面的例子中 iostat 的输出显示可能是磁盘的工作负载太大 也可能是配置不正确（在磁盘响应很快的情况下 为什么I/O 请求需要排队这么长时间才能进入到磁盘？） 然而 比较系统的需求和现有容量对于确定问题在哪里是很重要的一部分 大量的基准测试证明这个客户使用的这种SSD 是无法支撑几百MB/s 的写操作的 所以 尽管iostat 的结果表明磁盘的响应是正常的 也不一定是完全正确的 在这个案例中 我们没有办法证明磁盘的响应比iostat 的结果中所说的要慢 但这种情况还是有可能的 所以这不能改变我们的看法 可能是磁盘被滥用注 或者是错误的配置 或者两者兼而有之 是性能低下的罪魁祸首

在检查过所有诊断数据之后 接下来的任务就很明显了 测量出什么导致了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

Q3: 高性能MySQL：剖析单条查询（3）[1]

剖析单条查询（ ）

从结果可以看到该查询使用了三个临时表 其中两个是磁盘临时表 并且有很多的没有用到索引的读操作（Handler_read_rnd_next） 假设我们不知道这个视图的具体定义 仅从结果来推测 这个查询有可能是做了多表关联（join）查询 并且没有合适的索引 可能是其中一个子查询创建了临时表 然后和其他表做联合查询 而用于保存子查询结果的临时表没有索引 如此大致可以解释这样的结果

使用这个技术的时候 要注意SHOW STATUS 本身也会创建一个临时表 而且也会通过句柄操作访问此临时表 这会影响到SHOW STATUS 结果中对应的数字 而且不同的版本可能行为也不尽相同 比较前面通过SHOW PROFILES 获得的查询的执行计划的结果来看 至少临时表的计数器多加了

你可能会注意到通过EXPLAIN 查看查询的执行计划也可以获得大部分相同的信息 但EXPLAIN 是通过估计得到的结果 而通过计数器则是实际的测量结果 例如 EXPLAIN 无法告诉你临时表是否是磁盘表 这和内存临时表的性能差别是很大的 附录D 包含更多关于EXPLAIN 的内容

使用慢查询日志

那么针对上面这样的查询语句 Percona Server 对慢查询日志做了哪些改进？下面是 使用SHOW PROFILE 一节演示过的相同的查询执行后抓取到的结果

# Time: : :

# User@Host: root[root] @ localhost [ ]

# Thread_id: Schema: sakila Last_errno: Killed:

# Query_time: Lock_time: Rows_sent: Rows_examined:

Rows_affected: Rows_read:

# Bytes_sent: Tmp_tables: Tmp_disk_tables: Tmp_table_sizes:

# InnoDB_trx_id: E

# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: Yes Tmp_table_on_disk: Yes

# Filesort: Yes Filesort_on_disk: No Merge_passes:

# InnoDB_IO_r_ops: InnoDB_IO_r_bytes: InnoDB_IO_r_wait:

# InnoDB_rec_lock_wait: InnoDB_queue_wait:

# InnoDB_pages_distinct:

# PROFILE_VALUES … Copying to tmp table: … [omitted]

SET timestamp= ;

SELECT * FROM sakila nicer_but_slower_film_list;

从这里看到查询确实一共创建了三个临时表 其中两个是磁盘临时表 而SHOW PROFILE看起来则隐藏了信息（可能是由于服务器执行查询的方式有不一样的地方造成的） 这里为了方便阅读 对结果做了简化 但最后对该查询执行SHOW PROFILE 的数据也会写入到日志中 所以在Percona Server 中甚至可以记录SHOW PROFILE 的细节信息

lishixinzhi/Article/program/MySQL/201311/29706

Q4: mysql的特点是什么?

1) 功能强大

MySQL 中提供了多种数据库存储引擎高性能mysql怎么样，各引擎各有所长高性能mysql怎么样，适用于不同的应用场合，用户可以选择最合适的引擎以得到最高性能，可以处理每天访问量超过数亿的高强度的搜索 Web 站点。MySQL5 支持事务、视图、存储过程、触发器等。

2) 支持跨平台

MySQL 支持至少 20 种以上的开发平台，包括 Linux、Windows、FreeBSD 、IBMAIX、AIX、FreeBSD 等。这使得在任何平台下编写的程序都可以进行移植，而不需要对程序做任何的修改。

3) 运行速度快

高速是 MySQL 的显著特性。在 MySQL 中，使用了极快的 B 树磁盘表（MyISAM）和索引压缩；通过使用优化的单扫描多连接，能够极快地实现连接；SQL 函数使用高度优化的类库实现，运行速度极快。

4) 支持面向对象

PHP 支持混合编程方式。编程方式可分为纯粹面向对象、纯粹面向过程、面句对象与面向过程混合 3 种方式。

5) 安全性高

灵活和安全的权限与密码系统，允许基本主机的验证。连接到服务器时，所有的密码传输均采用加密形式，从而保证了密码的安全。

6) 成本低

MySQL 数据库是一种完全免费的产品，用户可以直接通过网络下载。

7) 支持各种开发语言

MySQL 为各种流行的程序设计语言提供支持，为它们提供了很多的 API 函数，包括 PHP、ASP.NET、Java、Eiffel、Python、Ruby、Tcl、C、C++、Perl 语言等。

8) 数据库存储容量大

MySQL 数据库的最大有效表尺寸通常是由操作系统对文件大小的限制决定的，而不是由 MySQL 内部限制决定的。InnoDB 存储引擎将 InnoDB 表保存在一个表空间内，该表空间可由数个文件创建，表空间的最大容量为 64TB，可以轻松处理拥有上千万条记录的大型数据库。

9) 支持强大的内置函数

PHP 中提供了大量内置函数，几乎涵盖了 Web 应用开发中的所有功能。它内置了数据库连接、文件上传等功能，MySQL 支持大量的扩展库，如 MySQLi 等，可以为快速开发 Web 应用提供便利。

高性能mysql怎么样的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于高性能mysql和高可用mysql、高性能mysql怎么样的信息别忘了在本站进行查找喔。