日期：2011-01-25 22:43:00 来源：本站整理
一次MySQL性能优化实战[MySQL防范]
本文“一次MySQL性能优化实战[MySQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
过年这段时间由于线上数据库常常压力过大招致呼应非常迟钝乃至死机,咬咬牙下大决计来办理效率不高的问题!
首先是由于公司秉持快速开辟原则,频繁上线,招致每次轻忽了性能问题!日积月累,所以招致系统越来越慢,所以假如你的系统查询语句本来就优化的很好了大概参考意义不大!
提取慢查询日记文件,应当在你的DataDir目录下面
通历程序处理慢查询文件,将文件格局的慢查询导入到数据库中:
| 1 mysql> desc slow_query; 2 +---------------+-------------+------+-----+---------+-------+ 3 | Field | Type | Null | Key | Default | Extra | 4 +---------------+-------------+------+-----+---------+-------+ 5 | Date | varchar(32) | NO | | | | 查询发生的时间 6 | user | varchar(64) | NO | | | | 7 | host | varchar(64) | NO | | | | 8 | content | text | NO | | | | 将Statement举行Mask后的语句,便于Group By 9 | query_time | int(11) | NO | | | | 查询所用时间,直接性能指标 10 | lock_time | int(11) | YES | | 0 | | 等候锁定的时间 11 | rows_sent | int(11) | YES | | 0 | | 返回的后果行数 12 | rows_examined | int(11) | YES | | 0 | | 扫描行数（很重要,上万今后就要重点注意了 13 | statement | text | YES | | NULL | | 实际查询语句 14 +---------------+-------------+------+-----+---------+-------+ |
然后施展您的想象力在这个表中极力捕捉你想捕捉的,那范例语句压力最大、扫描行数最多、等锁最久……
比方:
优化后:
| 1 mysql> select sum(query_time)/count(*),count 2 (*),sum(query_time),min(Date),Max(Date) from slow where Date>'2008-02-20 22:50:52' and Date<'2008-02-21 17:34:35'; 3 +--------------------------+----------+-----------------+---------------------+---------------------+ 4 | sum(query_time)/count(*) | count(*) | sum(query_time) | min(Date) | Max(Date) | 5 +--------------------------+----------+-----------------+---------------------+---------------------+ 6 | 5.7233 | 2197 | 12574 | 2008-02-20 22:51:16 | 2008-02-21 17:34:10 | 7 +--------------------------+----------+-----------------+---------------------+---------------------+ 8 1 row in set (0.09 sec) |
优化前:
| 1 mysql> select sum(query_time)/count(*),count(*),sum(query_time),min(Date),Max(Date) from slow where Date>'2008-02-17 22:50:52' and Date<'2008-02-18 17:34:35'; 2 +--------------------------+----------+-----------------+---------------------+---------------------+ 3 | sum(query_time)/count(*) | count(*) | sum(query_time) | min(Date) | Max(Date) | 4 +--------------------------+----------+-----------------+---------------------+---------------------+ 5 | 2.5983 | 16091 | 41810 | 2008-02-17 22:50:58 | 2008-02-18 17:34:34 | 6 +--------------------------+----------+-----------------+---------------------+---------------------+ 7 1 row in set (0.15 sec) |
再比方,优化前:
基本信息:
慢查询统计从 2008-02-17 17:59:34 到2008-02-18 22:45:22时间段,接近29个小时的数据;
总共有慢查询28914个,平均一小时有1000个慢查询;(花了一天优化降到每小时100个的模样了,成就感啊)
全部慢查询耗费总时间75690秒;
慢查询时间设置是大于2秒
参数阐明:
sum--总履行时间(秒);
count--履行次数;
avg--平均履行时间(秒);
content--近似SQL语句的表达通式,此中'DD'代表数字;
statement--某一条具体履行的SQL语句
由于拜候时的锁,招致update非常慢:
| 1 mysql> select count(*) as n,sum(query_time) as s, sum(query_time)/count(*) as avg,substring_index(statement,' ',2) as u from slow where statement like 'update%' and query_time>14 group by u; 2 +-----+------+---------+--------------------------+ 3 | n | s | avg | u | 4 +-----+------+---------+--------------------------+ 5 | 7 | 112 | 16.0000 | update conversation | 6 | 151 | 2413 | 15.9801 | update user | 7 | 4 | 65 | 16.2500 | update user_modification | 8 +-----+------+---------+--------------------------+ |
阐明程序中还是存在一些忘掉释放事件锁的情形
最耗费资源的10个查询:
此中第1,2,5应当是同一类查询,这样的话这一类查询占总查询的一半以上,每分钟呈现10个以上这样的慢查询,需求重点办理!
| 1 mysql> select sum(query_time) as sum, count(*) as count, sum(query_time)/count(*) as avg,statement from slow wher 2 e host like '%69.12.23.%' group by content order by sum desc limit 0,10\G 3 *************************** 1. row *************************** 4 sum: 27326 5 count: 11681 6 avg: 2.3394 7 ………… |
以上是“一次MySQL性能优化实战[MySQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“一次MySQL性能优化实战”更多相关内容
中查找“一次MySQL性能优化实战”更多相关内容评论内容只代表网友观点，与本站立场无关！
评论摘要(共 0 条，得分 0 分，平均 0 分)
查看完整评论