- 浏览: 496330 次
- 性别:
- 来自: 大连->北京
文章分类
最新评论
-
春天好:
写的很不错 推荐一个免费好用的云端爬虫开发平台不需要安装环境, ...
web爬虫 -
cpu88:
网络爬虫爬来爬去,网上信息可以瞬间扩散,但是也意味着,没有人愿 ...
web爬虫 -
biaoming:
牛。。学习了。。
MongoDB 关于索引的建议 -
biaoming:
楼主用mongo好早啊。
MongoDB 优化 -
biaoming:
好教程,学习了。。。
MongoDB 优化
MySQL程序剖析(Profiling)
我们将要详细的讲到MySQL的剖析(Profiling),因为它很少依赖于你的应用。应用和服务器级别的剖析有的时候都是有必要的。虽然应用级别的剖析可以给你整个应用性能的总揽。,但是对MySQL的剖析提供了信息是服务器级别所提供不了的。比如,对PHP代码进行剖析不会显示MySQL有多少行语句执行了。
与应用剖析一样,目标是找出MySQL哪部分消耗过多的时间。我们不会剖析MySQL源码的,虽然有的时候定制化MySQL安装很有用,但是这是另一本书的主题了。所替代的是,我们将教你一些可以技术来获取和分析不同种类的MySQL执行语句的信息。
你可以用在任意的颗粒级别以满足你的需求:你可能对整个服务器进行剖析或者单独检查一个语句或者一组语句。下列信息你可以一点点的收集:
- MySQL经常访问的那些数据
- MySQL经常执行语句的类型
- MySQL线程大部分时间的状态
- MySQL经常执行语句的子系统
- MySQL执行语句所访问的数据类型
- 不同活动的类型,比如扫描索引。
记录执行的语句
MySQL有两种记录语句的类型:general log和slow log。他们都是记录执行语句,但是却在语句执行进程的两端。general log记录了每个服务器收到的语句,因此它的语句可能包含了那些没有执行导致错误的语句。general Log记录了所有的语句,包括了一些非执行语句的事件,比如连接和断开连接。你可以用一个指令来启用它。
log = <file_name>
根据设计,general log不会包括执行时间和其他一些仅仅在语句执行完毕的信息。相比较而言,slow log记录执行完毕的语句。尤其是,它记录那些超过指定时间执行的语句。这两种日志都对程序剖析很有用,但是slow log是获取问题语句的主要工具。我们常常推荐把它开启。
下面列出的配置会开启这个日志。获取所有执行时间超过2s的语句,以及记录那些不使用索引的语句。它也会记录一些执行慢的管理语句,比如OPTIMIZE TABLE:
log-slow-queries = <file_name>
long_query_time = 2
log-queries-not-using-indexes
log-slow-admin-statements
你可以自定义这些配置,然后把它们放到my.conf文件中。更多的服务器配置将在以后的章节详细讲述。
long_query_time的默认值是10s。这个设置太慢了,因此我们一般都设置它为2s。然而,对于许多应用,可能1s都非常慢了。我们在下一部分将讲述如何获得颗粒度更细的日志。
在MySQL5.1中,提供了运行时调整slow_query_log,slow_query_log_file参数来控制slow log.但是在MySQL5.0中,在不启动MySQL的情况下,不能开闭slow log。对于MySQL5.0的变通方法是,可以动态的修改long_query_time变量。下面的语句虽然不是真正开启slow log的方式,但是取得了同样的效果。(如果有语句执行超过了10000s,那么你需要优化了这些语句了)
mysql> SET GLOBAL long_query_time = 10000;
相关配置变量,log_queries_not_using_indexes 使服务器记录没有使用索引的语句。而不管它们的执行时间。虽然开启了slow log会增加一些时间的消耗,导致语句执行速度减慢,但是没有使用索引的语句还是可以经常和非常快速的执行。(比如一些查询一些数据量小的表)这样会使降低服务器的速度,以及使用大量的硬盘空间保存日志。
不幸的是,在MySQL5.0中不能动态的开启或关闭日志。你必须修改MySQL配置文件,然后重启MySQL。当你想关闭日志而不想重启服务器,可以把日志文件做一个/dev/null的指向。在确定了MySQL关闭了日志文件描述以及在/dev/null重新打开它,那么你仅执行FLUSH LOGS就可以了。
相比较而言,MySQL5.1能实时更改日志以及能把日志记录到表中。这是个很大的进步了。
细颗粒度的日志
MySQL5.0以及更早的版本的slow log 都有一定的限制,在一些用途下就没用了。最首要的问题就是它的颗粒度仅仅是秒。以及long_query_time在MySQL5.0中最小单位就是1s。大部分交互的应用中,这个时间就比较长了。如果你正在开发一个高性能的WEB应用,你可能希望整个页面生成小于1s.以及在开始生成的过程中记录许多语句。这种情况下,一个语句执行了150ms,也会被认为是个很慢的语句。
另一个问题是,并不是所有的执行语句都记录在slow log中(尤其是,子节点的线程语句不能被记录)。general log记录了所有的语句,但是是在这些语句解析之前记录的,只要就不能记录一些如执行时间,锁时间,以及执行的行数的记录了。只有slow log包含这些信息。
最终,如果你开启了log_queries_not_using_indexes参数。可能slow log就被大量的实体,高效的语句所填满。比如,如果你过你生成一个下拉菜单的数据,你可能执行SELECT * FROM STATES。这个语句就被记录了,因为它是整张表的扫描。
当程序剖析的目标是性能优化,你应该查看让MySQL服务器大量工作的语句。这并不是意味着总是执行慢的语句。所以记录执行慢的语句可能也没什么用处了。一个例子,一个10ms的语句在一秒内执行了1000次对服务器的压力高于10s语句每秒运行一次。为了发现这个问题,你必须记录每条语句和分析结果。
一起查看执行慢的语句和导致服务器压力过大的语句执行总量是非常有用的方法。这会让你发现不同的问题。如一个语句导致了很差的用户体验。
我们已经开发了一个MySQL的补丁。基于Georg Richter工作之上而开发的。让你指定slow log语句时间到毫秒级别,而不是原来的秒。通过设置long_query_time=0,它也能让你记录所有的语句。这个补丁的地址是http://www.mysqlperformanceblog.com/mysql-patches/。它的主要缺点就是你需要自己编译MySQL。因为这个补丁在MySQL5.1之前并没有包含在MySQL发行包中。
目前,MySQL5.1包含了这个补丁,但仅能修改时间的颗粒度。这个补丁的新版本,将不会包含在MySQL的发行包中。新版本将添加一些有用的功能。这些功能包含了语句执行的连接ID,也包含了语句执行的缓存,连接类型,临时表,以及排序。也添加了InnoDB的统计,比如I/O行为以及锁等待。
新版本的补丁可以记录子节点所执行的语句。如果在子节点复制的过程中出现问题,这个功能就尤其有用。它也能让你选择一些会话的日志。这些功能对程序剖析来说已经足够了,我们认为这就是最佳实践了。
这个补丁是比较新的,因此如果你要应用,要小心的使用它。我们想它已经很安全了,但是它在其他的MySQL服务器还没有经过足够的考验。如果你担心这个还有补丁的MySQL服务器的稳定性,你不一定要一直运行它,你可以先运行它几个小时记录一些语句,然后在恢复你自己的MySQL版本。
当程序剖析的时候,把参数long_query_time=0记录所有语句是个很好的方法。如果大部分的读取来自于非常简单的语句,你可能想知道这些情况。记录所有语句会影响一些性能以及它要求更多的硬盘空间-这就是另一个不需要记录所有语句的理由。幸运的是,你可以随时修改long_query_time而不用去重新启动服务器。因此很容易在一段时间内获取所有语句。然后在恢复记录那些执行比较慢的语句。
怎样读取slow log
这是一个slow log的例子
1 # Time: 030303 0:51:27
2 # User@Host: root[root] @ localhost []
3 # Query_time: 25 Lock_time: 0 Rows_sent: 3949 Rows_examined: 378036
4 SELECT ...
第一行显示了日志记录的时间,第二行显示谁执行了这些语句。第三行显示这语句执行的时间,在MySQL服务器级别等待表锁的时间,执行语句返回的行数,以及语句检索的行数。这些语句都是被注视掉的。因此如果你把日志提供给MySQL Client,他们也不会执行。最后一行就是执行的语句。
这个例子是MySQL5.1版本的
1 # Time: 070518 9:47:00
2 # User@Host: root[root] @ localhost []
3 # Query_time: 0.000652 Lock_time: 0.000109 Rows_sent: 1 Rows_examined: 1
4 SELECT ...
和上个日志基本相同,除了第三行,精度变得更高了。上一部分我们提到的补丁提供了更全面的信息
1 # Time: 071031 20:03:16
2 # User@Host: root[root] @ localhost []
3 # Thread_id: 4
4 # Query_time: 0.503016 Lock_time: 0.000048 Rows_sent: 56 Rows_examined: 1113
5 # QC_Hit: No Full_scan: No Full_join: No Tmp_table: Yes Disk_tmp_table: No
6 # Filesort: Yes Disk_filesort: No Merge_passes: 0
7 # InnoDB_IO_r_ops: 19 InnoDB_IO_r_bytes: 311296 InnoDB_IO_r_wait: 0.382176
8 # InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.067538
9 # InnoDB_pages_distinct: 20
10 SELECT ...
第五行显示了这个语句是否使用了缓存,是否检索了整张表,是否没有用索引进行表连接,是否是否临时表,以及临时表是否创建在硬盘上。第六行给出了是否进行了文件排序以及,如果是,是否保存到硬盘上以及有多少合并排序通过它执行的。
如果语句执行在InnoDB上,第7,8,9行就会显示。第7行显示了在执行语句的时候,InnoDB计划读取的页数,与它一起的是byte数值。第7行最后的一个值是InnoDB从硬盘读取数据的时间。第8行显示了语句等待行锁以及用了多少时间等待进入InnoDB内核。
第9行显示了语句访问唯一InnoDB大约的页面数。这个数值越大,准确度貌似就越低了。这个信息的一种用处就是估计在页面中语句的工作集。这个就是InnoDB缓冲池缓存数据的方式。它也能显示你的集群索引是非常的有用。如果这个语句的行很好的集群索引了,它们会填充更少的页面。以后会讲到集群索引。
使用slow log去解决慢语句并不总是很简单。虽然log包含了很多有用的信息,但是一个非常重要的信息却丢失了:那就是语句执行为什么会这么慢的一个想法。有的时候,这是显而易见的。如果log得出了12,000,000行被检查以及1,200,000被发送到了客户端,你知道为什么这么慢的原因了--这是个很大的执行语句。然而,这是很难的的清晰。
要注意的是,不要给slow log添加过多的含义。如果你看到一条语句在log中出现多次,那就发现了这语句很慢以及需要优化。但是仅仅因为一个语句在log出现的频率并不意味着它是个糟糕的语句或者甚至并不是缓慢的。你可能找到了一个很慢的语句,运行它,以及发现它执行的时间只是一眨眼的时间。出现在日志中只能说明在过去的那个时候这个语句执行时间很长,并不意味着现在或以后它会执行很长时间。一个语句有的时候很慢,在另外的时间却很快,这种情况原因是很多的:
- 一个表可能被锁定了,导致了语句必须去等待。Lock_time指明了这个语句等待锁释放的时间。
- 数据或者索引没有被缓存。在MySQL刚启动的时候或还没有调整好的情况下,这种问题很常见。
- 可能是备份正在执行,导致了硬盘I/O很慢。
- 这个服务器同时还运行着其他语句,导致了这个语句很慢。
日志分析工具
现在你已经记录了一些执行的语句了。是时候分析结果了。一般的策略是找出对服务器影响最大的语句,用Explain检查它们执行计划进行必要的调整。在调整之后不断地重复这个过程。因为你的修改可能会影响其他语句的执行。比较常见的就是索引可以提高SELECT的速度但是会降低INSERT或UPDATE语句。
一般来说你应该在日志中查找如下的执行语句:
- Long queries(运行时间长的语句):固定时间的批量任务使语句执行缓慢,但是正常的语句不应该执行的很慢。
- High-impact queries(影响大的语句):找出那些占用服务器执行大部分时间的语句。还记得上一部分说过的执行时间短的语句占用了很多时间。
- new queries(新出现的语句):找出那些昨天还没有在前100个,但是今天却出现的语句。这些语句可能是新出现的也可能是被很快的运行以及正在变得糟糕。可能因为不同的索引或者其他别的什么改变。
mysqldumpslow:
mysql_slow_log_filter:
发表评论
-
查询性能的优化 - 语句执行的基础 - 查询优化的过程 (一)
2010-01-20 12:00 3458在语句生命周期的下一步就是把一个SQL查询放入一个可执行 ... -
查询性能的优化 - 语句执行的基础 - 已缓存的查询语句
2009-12-01 09:58 1157在解析一个查询之前,如果缓存开启,MySQL要检查它的缓存。这 ... -
查询性能的优化 - 语句执行的基础 - MySQL 客户端/服务端 协议
2009-12-01 01:25 1927MySQL 客户端/服务端 协 ... -
查询性能的优化 - 语句执行的基础
2009-11-30 00:36 1012如果你想从MySQL服务器获得很高的性能,建议你花费一定的时间 ... -
查询性能的优化 - 重新构建查询的方法 - 分解JOIN查询
2009-11-29 11:54 1827分解JOIN查询 许多高性能的网站都分解了JOIN查询。你可 ... -
查询性能的优化 - 重新构建查询的方法 - 拆分一个查询语句
2009-11-28 23:17 1491拆分一个查询语句 另一个分解查询的方法是分步解决。本质上来 ... -
查询性能的优化 - 重新构建查询的方法 - 复杂查询VS多个查询语句
2009-11-28 01:32 1510当开始优化有问题的查 ... -
查询性能的优化 - 查询慢的基础知识:优化数据访问
2009-08-19 14:50 1557一个查询执行的不是 ... -
查询性能的优化 - 前言
2009-08-12 16:49 986上一章,我们解释了怎样优化schema.这是高性能的一个必要条 ... -
Schema的优化和索引 - 关于存储引擎的简单记录
2009-08-12 15:26 1051这一章的结束,我们来说一下关于设计模型的存储引擎的选择,这些你 ... -
Schema的优化和索引 - 加速ALTER TABLE
2009-08-12 14:02 1826当对于一个大表进行ALTER TABLE的时候,性能问题就产生 ... -
Schema的优化和索引 - 范式和非范式
2009-08-12 11:35 1675有很多方法来展现给定的数据。从完全范式到完全的非范式以及介于两 ... -
Schema的优化和索引 - 索引和表的维护
2009-08-10 15:38 1400当你已经创建了一张表 ... -
Schema的优化和索引 - 学习一个索引示例
2009-08-06 14:09 1036用例子来理解索引的概 ... -
Schema的优化和索引 - 高性能的索引策略 - 索引和锁
2009-07-31 15:48 1007InnoDB中,索引所扮演的角色是非常重要的。因为它们可以能让 ... -
Schema的优化和索引 - 高性能的索引策略 - 冗余和重复的索引
2009-07-31 11:37 2046MySQL可以在一个列上创建多个索引;这么做并不会提醒和防止发 ... -
Schema的优化和索引 - 高性能的索引策略 - 压缩索引(Packed Indexes)
2009-07-30 21:30 1407MyISAM使用前缀压缩来降低索引的大小,这样就可以把更多的索 ... -
Schema的优化和索引 - 高性能的索引策略 - 使用索引扫描来进行排序
2009-07-28 10:43 2184MySQL有两种方法生成有序的结果:使用文件排序或者按顺序的扫 ... -
Schema的优化和索引 - 高性能的索引策略 - 覆盖索引(Covering Indexes)
2009-07-22 15:25 2573索引是高效找到行的一 ... -
Schema的优化和索引 - 高性能的索引策略 - 聚簇索引(Clustered Indexes)
2009-07-20 23:29 3128聚簇索引并不是一个独立的索引类型。确切的说它们是存储数据的一个 ...
相关推荐
MySQL 的Query Profiler 是一个使用非常方便的Query 诊断分析工具,通过该工具可以获取一条Query 在整个执行过程中多种资源的消耗情况。
profiling是个很好用的mysql性能分析工具,今儿就来试验下profiling的功能。感谢 有爱玫瑰的博文:mysql 的 sql 性能分析器主要用途是显示 sql 执行的整个过程中各项资源的使用情况。分析器可以更好的展示出不良 SQL...
Mysql自带profiling性能分析工具使用分享,需要的朋友可以参考下
MYSQL的profiling功能要在Mysql版本5.0.37以上才能使用。 查看profile是否开启 mysql> show variables like '%profil%'; +------------------------+-------+ | Variable_name | Value | +---------------------...
是mysql提供可用来分析当前会话中语句执行的资源消耗情况,可以用于SQL的调优测量。 默认情况下,参数处于关闭状态,并保存最近15次的运行结果 分析步骤 1、查看当前版本sql是否支持show profiles mysql> show ...
第2章:寻找瓶颈:基准测试(Benchmarking)与性能分析(Profiling) 32 第3章:架构优化和索引 80 第4章:查询性能优化 152 第5章:MySQL高级特性 204 第6章:优化服务器设置 265 第7章:操作系统和硬件优化 305 第...
●架构设计篇则主要以设计一个高可用可扩展的分布式企业级数据库集群环境为目标,分析介绍了通过MySQL实现这一目标的多种架构方式。主要包括可扩展和高可用两部分内容,可扩展部分包括设计原则、Replication的利用、...
PROFILING:性能分析工具 MysqlDUMP:备份工具 Mysql的配置文件有多个目录,顺序分别为: /etc/my.cnf /etc/mysql/my.cnf $MYSQL_HOME/my.cnf 编译目录下的my.cnf ~/.my.cnf 当Mysql启动的时候会依次读取这几个文件...
(如果将profiling_history_size参数设置为0,同样具有关闭MySQL的profiling效果。) 此工具可用来查询SQL执行状态,System lock和Table lock 花多少时间等等, 对定位一条语句的I/O消耗和CPU消耗 非常重要。(SQL ...
在MySQL数据库中,可以通过配置profiling参数来启用SQL剖析。该参数可以在全局和session级别来设置。对于全局级别则作用于整个MySQL实例,而session级别紧影响当前session。该参数开启后,后续执行的SQL语句都将记录...
mysql> SET profiling = 1; 之后在运行一个查询 mysql> SELECT COUNT(DISTINCT actor.first_name) AS cnt_name, COUNT(*) AS cnt -> FROM sakila.film_actor -> INNER JOIN sakila.actor USING(actor_id)
使用profile来分析慢sql mysql 的 sql 性能分析器主要用途是显示 sql 执行的整个过程中各项资源的使用情况。分析器可以更好的展示出不良 SQL 的性能问题所在。...mysql> set profiling=1; -- 开启profile Query
Laravel Web和控制台应用程序的数据库探查器。 一个简单的工具,即使在代码中使用dd()也可以正常使用。 Laravel 数据库探查器 8.x 7.x 6.x 5.8。* 5.7。* 5.6。* 5.5。* 5.4。* 5.3。* 5.2。* 5.1。* ...
可以在“数据质量报告”工作流程中执行数据验证,最终导致生成数据质量分析报告。 这在非交互模式下最有用,在非交互模式下,必须定期检查数据库表和磁盘上数据文件的数据质量。 为Pointblank代理提供了一组验证功能...