mysql性能
监控MySQL的性能指标
这个职位是一个3部分组成的系列关于MySQL的第1部分监控。 第二 部分是关于从MySQL收集度量和第3部分解释了如何使用MySQL的Datadog进行监控。
什么是MySQL？
MySQL的是世界上最流行 的开源关系数据库服务器。 属于Oracle，MySQL是在免费下载的社区版，以及在商业版本添加了功能和支持可用。 最初于1995年发布，MySQL已经催生以来高调叉子竞争性技术，如MariaDB的和Percona的。
重点统计的MySQL
如果你的数据库运行缓慢，或未能提供查询服务以任何理由，你的筹码的每一个部分取决于该数据库上会遇到性能问题也是如此。 为了保持你的数据库运行平稳，你可以主动监测指标涵盖了性能和资源利用四个方面：
- 查询吞吐量
- 查询执行性能
- 连接
- 缓冲池的使用
MySQL的用户可以访问数据库中的上百个指标，因此在本文中，我们将重点放在关键指标，这将使你获得实时洞察到你的数据库的健康和性能屈指可数。 在第二部分，这一系列我们将向你展示如何访问和收集所有这些指标。
本文参考指标术语在介绍我们的监控101系列 ，它提供了指标收集和警报的框架。
版本和技术之间的兼容性
一些在本系列中讨论的监测策略是特定的MySQL版本5.6和5.7。 这些版本之间的差异将沿途指出。
大多数这里列出的度量和监控策略也适用于MySQL的兼容技术，MariaDB的和Percona的服务器，有一些明显的差异。 例如，一些在MySQL工作台，其详述的特征2部分这一系列的，不与MariaDB的当前可用版本兼容。
亚马逊RDS用户应该检查出我们的专业导游监控MySQL中RDS和MySQL的兼容亚马逊的极光 。
查询吞吐量
| 名称 | 描述 | 公制型 | 可用性 |
|---|---|---|---|
| 问题 | 算上执行的语句（由客户端发送） | 工作：吞吐量 | 服务器状态变量 |
| Com_select | SELECT语句 | 工作：吞吐量 | 服务器状态变量 |
| 写 | 插入，更新或删除 | 工作：吞吐量 | 从服务器状态的变量进行计算 |
在监测系统中任何你最关心的是确保它的工作正在做有效。 数据库的工作运行查询，让你的第一个监测应优先确保MySQL正在执行的查询预期。
MySQL有一个内部计数器（“服务器状态变量”，在MySQL中的说法）被称为Questions ，这是为增加客户端应用程序发送的所有语句。 通过提供客户为中心的视图Questions指标往往更容易比相关解释Queries柜台，这也算作的一部分执行的语句存储程序 ，以及如命令PREPARE和DEALLOCATE PREPARE运行服务器端的一部分预处理语句 。
要查询服务器的状态变量，如Questions或Com_select ：
SHOW GLOBAL STATUS LIKE "Questions"; +---------------+--------+ | Variable_name | Value | +---------------+--------+ | Questions | 254408 | +---------------+--------+
您还可以监视读写命令的细分，以更好地了解你的数据库的工作量和识别潜在的瓶颈。 阅读查询通常由捕获Com_select指标。 写增量三种状态变量，根据不同的命令：
写= Com_insert + Com_update + Com_delete
公制，提醒：问题
查询目前的速度自然会上升和下降，因此它并不总是基于固定阈值的一个可操作的指标。 但是值得在在可以通过查询体积急剧下降突然变化提醒，尤其是，可以指示一个严重的问题。
查询性能
| 名称 | 描述 | 公制型 | 可用性 |
|---|---|---|---|
| 查询运行时间 | 平均运行时间，每个模式 | 工作表现 | 性能架构查询 |
| 查询错误 | 生成错误的SQL语句数 | 工作：错误 | 性能架构查询 |
| Slow_queries要花 | 超过配置的查询数long_query_time限制 |
工作表现 | 服务器状态变量 |
MySQL用户有一些用于监视查询延迟功能，既可通过利用MySQL的内置度量和通过查询性能架构。 默认情况下启用从MySQL 5.6.6中，的表performance_schema内有关服务器事件和查询执行的MySQL存储低级别的统计数据库。
性能架构声明摘要
许多关键指标包含在性能模式的events_statements_summary_by_digest表，它捕获有关延迟，错误和为每个标准化语句查询量信息。 从表中的样本行显示已运行两次，并且花了325毫秒，平均执行（所有定时测量是皮秒）的声明：
*************************** 1. row *************************** SCHEMA_NAME: employees DIGEST: 0c6318da9de53353a3a1bacea70b4fce DIGEST_TEXT: SELECT * FROM `employees` WHERE `emp_no` > ? COUNT_STAR: 2 SUM_TIMER_WAIT: 650358383000 MIN_TIMER_WAIT: 292045159000 AVG_TIMER_WAIT: 325179191000 MAX_TIMER_WAIT: 358313224000 SUM_LOCK_TIME: 520000000 SUM_ERRORS: 0 SUM_WARNINGS: 0 SUM_ROWS_AFFECTED: 0 SUM_ROWS_SENT: 520048 SUM_ROWS_EXAMINED: 520048 ... SUM_NO_INDEX_USED: 0 SUM_NO_GOOD_INDEX_USED: 0 FIRST_SEEN: 2016-03-24 14:25:32 LAST_SEEN: 2016-03-24 14:25:55
摘要表 归所有的语句（如被看见在DIGEST_TEXT以上字段），忽略数据值和规范的空白和资本，使下面两个查询将被认为是相同的：
select * from employees where emp_no >200; SELECT * FROM employees WHERE emp_no > 80000;
要提取微秒每个模式平均运行时间，可以查询的性能架构：
SELECT schema_name , SUM(count_star) count , ROUND( (SUM(sum_timer_wait) / SUM(count_star)) / 1000000) AS avg_microsec FROM performance_schema.events_statements_summary_by_digest WHERE schema_name IS NOT NULL GROUP BY schema_name; +--------------------+-------+--------------+ | schema_name | count | avg_microsec | +--------------------+-------+--------------+ | employees | 223 | 171940 | | performance_schema | 37 | 20761 | | sys | 4 | 748 | +--------------------+-------+--------------+
同样，要计算每生成错误模式语句总数：
SELECT schema_name , SUM(sum_errors) err_count FROM performance_schema.events_statements_summary_by_digest WHERE schema_name IS NOT NULL GROUP BY schema_name; +--------------------+-----------+ | schema_name | err_count | +--------------------+-----------+ | employees | 8 | | performance_schema | 1 | | sys | 3 | +--------------------+-----------+
sys架构
查询如上图所示的性能架构编程方式从数据库中检索指标的伟大工程。 对于即席查询和调查，但是，它通常是更容易使用MySQL的sys架构 。 sys架构提供了更加人性化的可读格式的有组织的衡量标准，使得相应的查询要简单得多。 例如，要找到最慢的语句（那些由运行时的第95百分位）：
SELECT * FROM sys.statements_with_runtimes_in_95th_percentile;
或者，看看哪些归报表生成的错误：
SELECT * FROM sys.statements_with_errors_or_warnings;
许多其他有用的例子sys架构中详细说明文档 。 sys架构包含在MySQL的开始5.7.7版本，但MySQL的5.6的用户可以只用几个命令进行安装。见第2部分本系列指令。
慢查询
除了 在性能模式和sys架构提供的性能数据的财富，MySQL的拥有Slow_queries计数器，每递增一个查询的执行时间超过了指定的秒数时间long_query_time参数。 将阈值设定为10秒默认：
SHOW VARIABLES LIKE 'long_query_time'; +-----------------+-----------+ | Variable_name | Value | +-----------------+-----------+ | long_query_time | 10.000000 | +-----------------+-----------+
该long_query_time参数可以用一个命令进行调整。 例如，要设置慢查询阈五秒：
SET GLOBAL long_query_time = 5;
（请注意，您可能需要关闭会话并重新连接到数据库，在会话级要应用的变化。）
调查查询性能问题
如果你的查询执行速度比预期慢，往往是最近更改的查询是罪魁祸首的情况。 如果没有查询被确定为过度缓慢，接下来的事情就来评估是系统级的指标，了解核心资源（CPU，磁盘I / O，内存和网络）的约束。 CPU饱和度和I / O瓶颈是常见的罪魁祸首。 您可能还希望检查Innodb_row_lock_waits指标，它计算InnoDB存储引擎有多久等待获取一个特定行上的锁。 InnoDB的一直以来的MySQL 5.5版的默认存储引擎，MySQL使用行级锁的InnoDB表。
为了提高读写操作的速度，不少用户希望调整大小缓冲池 InnoDB用来缓存表和索引数据。 更多关于监测和调整缓冲池下方 。
度量，提醒
- 查询运行时：对关键数据库管理延迟是至关重要的。 如果平均运行时间在生产数据库查询开始攀升，寻找你的数据库实例资源的限制，可能争用行或表锁，而变化的查询模式在客户端上。
- 查询错误：在查询错误的突然增加可能表明您的客户端应用程序或数据库本身的问题。 您可以使用sys架构来快速探索哪些查询可能导致问题。 例如，要列出已返回最错误的10规范化语句：
SELECT * FROM sys.statements_with_errors_or_warnings ORDER BY DESC错误 LIMIT 10;
Slow_queries：你如何定义一个慢查询（因此如何配置long_query_time参数）取决于你的使用情况。 无论你的定义“慢”，你可能会希望进行调查，如果慢查询的数量上升到高于基线水平。 为了确定执行缓慢的实际查询，可以查询SYS方案或潜入MySQL的可选慢查询日志，该日志默认情况下禁用。 扶持和访问慢查询日志的详细信息，请MySQL的文档中 。
连接
| 名称 | 描述 | 公制型 | 可用性 |
|---|---|---|---|
| threads_connected的 | 当前打开的连接 | 资源：利用 | 服务器状态变量 |
| Threads_running | 当前正在运行的连接 | 资源：利用 | 服务器状态变量 |
| Connection_errors_ 内部 |
连接计数拒绝由于服务器错误 | 资源：错误 | 服务器状态变量 |
| Aborted_connects | 算上失败尝试连接到服务器 | 资源：错误 | 服务器状态变量 |
| Connection_errors_ MAX_CONNECTIONS |
连接计数拒绝因max_connections极限 |
资源：错误 | 服务器状态变量 |
检查并设置连接数限制
监控您的客户端连接是至关重要的，因为一旦你已用尽可用的连接，新的客户端连接将被拒绝。 MySQL连接限制的默认值为151，但可以用一个查询来验证：
SHOW VARIABLES LIKE 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 151 | +-----------------+-------+
MySQL的文件表明，强大的服务器应该能够处理在高几百或几千个连接：
“Linux或Solaris应该能够支持500个到1000个并发连接经常和多达10,000连接，如果您有可用的RAM许多GB和工作量从每个低或响应时间要求不高的目标。 窗户被限制在（打开表×2 +打开的连接）<2048由于在该平台上使用了POSIX兼容层“。
连接限制可以动态进行调整：
SET GLOBAL max_connections = 200;
该设置将返回到默认的服务器重新启动时，但是。 要永久设置的连接限制，加上这样一行到你my.cnf配置文件（见这个帖子寻求帮助，查找配置文件）：
max_connections = 200
监控连接利用率
MySQL的暴露了Threads_connected threads-度量计算连接每个连接一个线程 。 通过监测这一指标的旁边配置连接限制，可以确保你有足够的能力来处理新的连接。 MySQL也暴露了Threads_running指标以分离的线程在任何时候都在积极处理查询，而不是打开的，但目前的空闲连接。
如果您的服务器确实达到max_connections限制，它会开始拒绝连接。在这种情况下，该度量Connection_errors_max_connections将递增，如将在Aborted_connects度量跟踪所有连接尝试失败。
MySQL的公开各种对连接错误等指标，它可以帮助您调查连接问题的。 度量Connection_errors_internal是一个很好的观看，因为只有当误差来自服务器本身它递增。 内部错误反映内存外的一个条件或服务器无法启动一个新的线程。
度量，提醒
Threads_connected：如果客户端试图连接到MySQL时，所有可用的连接都在使用，MySQL将返回“太多的连接”的错误和增量Connection_errors_max_connections。 为了避免这种情况，你应该监视打开的连接数，并确保它仍然安全地低于配置max_connections限制。Aborted_connects：如果此计数器增加，您的客户尝试和失败来连接到数据库。 调查问题的细粒度连接指标，如源Connection_errors_max_connections和Connection_errors_internal。
缓冲池的使用
| 名称 | 描述 | 公制型 | 可用性 |
|---|---|---|---|
| Innodb_buffer_pool_pages_total | 在缓冲池总页数 | 资源：利用 | 服务器状态变量 |
| 缓冲池的利用率 | 在缓冲池中用来总页数的比例 | 资源：利用 | 从服务器状态的变量进行计算 |
| Innodb_buffer_pool_read_requests | 缓冲池的请求 | 资源：利用 | 服务器状态变量 |
| Innodb_buffer_pool_reads | 请该缓冲池不能满足 | 资源：饱和度 | 服务器状态变量 |
MySQL的默认存储引擎，InnoDB的，使用的内存被称为缓冲池表和索引缓存数据的区域。 缓冲池指标资源指标，而不是工作的指标 ，并且因此是用于调查（而不是检测）的性能问题，主要是有用的。 如果数据库的性能开始下滑，而磁盘I / O呈上升趋势，扩大了缓冲池往往能带来好处。
浆纱缓冲池
缓冲池默认为一个相对较小的128 mebibytes，但MySQL的建议，你可以增加它到高达80％的物理内存专用的数据库服务器上。 MySQL也增加了谨慎的几个音符，但是，由于InnoDB的内存开销约10％增加了内存占用量超出分配的缓冲池大小。 如果你用完物理内存，系统将采取分页，性能就会显著受到影响。
缓冲池也可以分成独立的区域，被称为实例。 使用多个实例可以提高并发性在多吉布范围的缓冲池。
缓冲池大小调整操作在组块执行，并且缓冲池的大小必须被设置为块大小倍实例的数目的倍数：
innodb_buffer_pool_size = N * innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances
块大小默认为128 MIB但是配置从MySQL 5.7.5的。 这两个参数的数值可以被检查如下：
SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_chunk_size"; SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_instances";
如果innodb_buffer_pool_chunk_size查询不返回任何结果，参数没有在你的MySQL版本可调，可假设为128 MIB。
要设置缓冲池大小，并在服务器启动的实例数：
$ mysqld --innodb_buffer_pool_size=8G --innodb_buffer_pool_instances=16
在MySQL 5.7.5，你也可以调整缓冲池的即时通过SET命令来指定以字节为单位所需的大小。 例如，有两个缓冲池的情况下，可以通过设置总大小8吉布设置每个4吉布尺寸：
SET GLOBAL innodb_buffer_pool_size=8589934592;
关键InnoDB缓冲池指标
MySQL的暴露了美国在缓冲池和利用率度量了一把。 一些最有用的是指标跟踪缓冲池的总大小，有多少是在使用中，而缓冲池是如何有效地服务读取。
的指标Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads是了解缓冲池的利用率。 Innodb_buffer_pool_read_requests跟踪逻辑读取请求的数目，而Innodb_buffer_pool_reads跟踪缓冲池不能满足，因此，必须从盘读出的请求的数量。 鉴于从存储器中读出通常是数量级比从磁盘读取速度更快，如果性能将受到影响Innodb_buffer_pool_reads开始攀升。
缓冲池的利用率是检查你考虑调整缓冲池前，一个有用的指标。 利用度量不可开箱但可以如下容易地计算出：
(Innodb_buffer_pool_pages_total - Innodb_buffer_pool_pages_free) / Innodb_buffer_pool_pages_total
如果您的数据库提供了大量的从磁盘中读取，但缓冲池远未充分，这可能是因为你的缓存最近被清除，还在升温。 如果您的缓冲池未填满，但有效地服务读取数据的工作集可能舒适适合在内存中。
高缓冲池的利用率，而另一方面，也未必就是孤立一件坏事，因为旧的或不用的数据将自动过期使用高速缓存的LRU策略。 但是，如果缓冲池没有有效地服务你读的工作量，它可能是时间来扩展你的缓存。
转换缓冲池指标字节
大多数缓冲池度量报告为内存页的计数，但这些指标可以被转换为字节，这使得它更容易与您的缓冲池的实际大小，这些指标进行连接。 例如，要找到缓冲池的使用字节的总大小服务器状态变量跟踪缓冲池总页数：
Innodb_buffer_pool_pages_total * innodb_page_size
InnoDB的页面大小可调，但默认为16昆明植物研究所，或16,384字节。 当前值可以用检查SHOW VARIABLES查询：
SHOW VARIABLES LIKE "innodb_page_size";
结论
在这篇文章中，我们已经探索最重要的指标屈指可数应监视，监视MySQL的活动和性能。 如果你正在构建你的MySQL监控，捕捉下面列出的指标将会把你的道路上对理解你的数据库的使用模式和潜在的制约因素。 他们还将帮助您确定何时需要进行扩展，或移动您的数据库实例，以更强大的主机，以保持良好的应用性能。
- 查询吞吐量
- 查询延迟和错误
- 客户端连接和错误
- 缓冲池的利用率
第2部分本系列提供了用于收集和监视你从MySQL需要的所有指标的说明。
致谢
非常感谢戴夫·斯托克斯甲骨文和艾文财富的VividCortex本文出版之前就 提供了宝贵的意见。