当前位置: 主页 > 运维经验 > 经验之谈 >

生产环境高并发MySQL SQL语句优化案例(老男孩培

时间:2013-05-24 10:42来源:www.linuxyw.com 作者:admin 点击:
生产环境高并发MySQLSQL语句优化 10 条案例 声明:本案例为 老男孩 linux 运维实战培训 的数据库优化教学案例,如有转载务必保留本版权声明 在实际工作中,运维或 DBA 人员经常会根据数
欢迎大家分享自己的文档,请点击查阅:分享方法,Linux系统运维
如果你喜欢这文章,可以点击文章结尾处百度分享,分享到你的各种社区收藏,或推荐给朋友……


 

声明:本案例为老男孩linux运维实战培训数据库优化教学案例,如有转载务必保留本版权声明

在实际工作中,运维或DBA人员经常会根据数据库的慢查询日志来抓出执行慢的SQL语句,然后,或自行处理或扔给开发处理,好点的DBA可能会和开发商量共同解决慢查询的问题,如果是调参、索引问题,那就简单了,有的时候调参索引优化没余地了,还有根据语句的功能拆分或者改成程序解决,当然也可能会调整DB架构。下面的案例主要是告诉大家,数据库的优化不都是运维,DBA的事,这一点老男孩培训的学生也是有欠缺的,工作中遇到问题束手束脚,又不好意思问开发,总是自己扛,解决憋的头大的不行,还要半夜里苦苦找老男孩老师帮忙,其实,开发、架构、产品等所有部分都有义务配合,只有通力配合,运维及DBA才能完成数据库优化的工作,其他的职位也是如此的,因此,请不要把自己孤立在孤军奋战的情况,团队的力量才是最大的。

慢查询问题是几乎数据库性能的最直接的原因了,每个运维和DBA都必须要面对,例如首先要开启慢查询及没有走索引的日志,然后写程序分析归类有问题的日志,最后发到相关人的信箱里,紧急的可以短信提醒,这是我们工作中的做法,当然还包括分析binlog,及数据库的状态日志,掌握数据库的性能指标趋势。

下面分析归类后的慢查询日志,以及解决慢查询日志最终方法,这些都是实实在在的生产案例总结,与老男孩的博友们分享。

Slow log很多时候是由order by引起的,当explain语句有Using where; Using temporary; Using filesort的信息,有这个情况就会效率低了。解决这个的关键要在order by的字段上做索引。

请看下面的例子:

案例1:分析归类后的慢查询日志如下。

Report for slow logs: /data/3306/slow-log.log.1

6.26k queries total, 135 unique

Sorted by 't_sum'

Grand Totals: Time 34.11k s, Lock 0 s, Rows sent 57.67k, Rows Examined 3.84M

______________________________________________________________________ 001 ___

Count: 2.17k(34.64%)

Time: 11031 s total, 5.090448 s avg, 3 s to 18 s max(32.34%)

95% of Time : 9605 s total, 4.667153 s avg, 3 s to 11 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 10 avg, 0 to 10 max(36.35%)

Rows examined : 20 avg, 0 to 37 max(1.11%)

Database: docresource

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (2167) of query, 100.00% (6256) of all users

Query abstract:

SELECT t.cor_id,t.boy_title_upper,t.cor_boy_title,t.cor_boy_order,t.cor_boy_description,t.cor_boy_state FROM t_cordoc t WHERE t.cor_boy_state=N AND t.boy_title_upper='S' ORDER BY t.cor_boy_order ASC LIMIT N;

Query sample:

SELECT T.COR_ID,T.BOY_TITLE_UPPER,T.COR_BOY_TITLE,T.COR_BOY_ORDER,T.COR_BOY_DESCRIPTION,T.COR_BOY_STATE FROM t_cordoc T where T.COR_BOY_STATE=1 and T.BOY_TITLE_UPPER='铔嬪僵鐢? ORDER BY T.COR_BOY_ORDER ASC LIMIT 10;

最终解决方案:用java程序在内存排序。

老男孩点评:数据库优化不一定就要该参数,建索引,不适合数据库干的事也可以拿出来交给程序干。

案例2:分析归类后的慢查询日志如下。

______________________________________________________________________ 002 ___

Count: 911(14.56%)

Time: 5342 s total, 5.863886 s avg, 3 s to 63 s max(15.66%)

95% of Time : 4381 s total, 5.06474 s avg, 3 s to 14 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 9 avg, 1 to 10 max(14.53%)

Rows examined : 759 avg, 20 to 13.61k max(17.99%)

Database: docresource

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (911) of query, 100.00% (6256) of all users

Query abstract:

SELECT boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit FROM t_doc WHERE boy_state IN (N4) AND boy_creator_user_id_encrypt='S' ORDER BY boy_latest_edition_time DESC LIMIT N,N;

Query sample:

select boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit from t_docwhere boy_state in (1,2,3,4) and boy_creator_user_id_encrypt='tAQREAwRXWkJBUAoL' order by BOY_LATEST_EDITION_TIME DESC limit 0,10;

最终解决方案:添加适合的索引

alter table t_doc add index idx_create_user_iden_edittime(boy_creator_user_id_encrypt, boy_latest_edition_time);

案例3:分析归类后的慢查询日志如下。

______________________________________________________________________ 003 ___

Count: 1.00k(16.06%)

Time: 5114 s total, 5.088557 s avg, 3 s to 17 s max(14.99%)

95% of Time : 4426 s total, 4.639413 s avg, 3 s to 10 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 10 avg, 8 to 10 max(17.28%)

Rows examined : 10 avg, 8 to 10 max(0.26%)

Database: docresource

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (1005) of query, 100.00% (6256) of all users

Query abstract:

SELECT boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit FROM t_doc WHERE boy_title_upper IN (S10);

Query sample:

select boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit from t_docwhere boy_title_upper in ('銆婄鍏劅濂崇銆?,'灏斿啲鍗?,'銆婂€╁コ骞介瓊2?,'銆婄旱妯洓娴枫€?,'榛勭鐢?,'棣欐腐鐢靛奖閲戝儚濂?,'銆婁笢閭タ姣掋€?,'鐜嬬璐?,'绉︽矝','寰愬厠');

最终解决方案:有用到boy_title_upper的索引,慢的原因再观察

案例4:分析归类后的慢查询日志如下。

______________________________________________________________________ 004 ___

Count: 378(6.04%)

Time: 2604 s total, 6.888889 s avg, 3 s to 65 s max(7.63%)

95% of Time : 2031 s total, 5.657382 s avg, 3 s to 17 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 5 avg, 0 to 10 max(3.24%)

Rows examined : 2.81k avg, 92 to 24.91k max(27.61%)

Database: docresource

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (378) of query, 100.00% (6256) of all users

Query abstract:

SELECT h.boy_id ,MAX(h.boy_his_edit_time) AS boy_his_edit_time FROM t_boy_his h WHERE h.boy_his_isteammate=N AND h.boy_his_state=N AND h.boy_his_editor_user_id_encrypt='S' GROUP BY h.boy_id ORDER BY h.boy_his_edit_time DESC LIMIT N,N;

Query sample:

selecth.boy_id ,max(h.boy_his_edit_time) from t_boy_his hwhere h.boy_his_editor_user_id_encrypt='pGVpWQVlYdglTaQ0Z' and h.boy_his_isteammate=1 and h.boy_his_state=1 group by h.boy_id order by h.boy_his_edit_time desc limit 0,4; 

最终解决方案:

alter table t_boy_his add index editor_user_iden_docid(boy_his_editor_user_id_encrypt, boy_id);

1,sql改成:SELECT h.boy_id ,MAX(h.boy_his_edit_time) AS boy_his_edit_time FROM t_boy_his h WHERE h.boy_his_isteammate='pGVpWQVlYdglTaQ0Z' AND h.boy_his_state=1 AND h.boy_his_editor_user_id_encrypt='S' GROUP BY h.boy_id ORDER BY null

2,再在程序里,用javaboy_his_edit_time排序。

案例5:分析归类后的慢查询日志如下。

______________________________________________________________________ 005 ___

Count: 211(3.37%)

Time: 1218 s total, 5.772512 s avg, 3 s to 30 s max(3.57%)

95% of Time : 1022 s total, 5.11 s avg, 3 s to 13 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 2 avg, 0 to 2 max(0.72%)

Rows examined : 3.61k avg, 110 to 19.59k max(19.81%)

Database: 

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (211) of query, 100.00% (6256) of all users

Query abstract:

SELECT h.boy_id ,MAX(h.boy_his_edit_time) AS boy_his_edit_time FROM t_boy_his h WHERE h.boy_his_isteammate=N AND h.boy_his_state=N AND h.boy_his_editor_user_id=N GROUP BY h.boy_id ORDER BY h.boy_his_edit_time DESC LIMIT N,N;

Query sample:

selecth.boy_id ,max(h.boy_his_edit_time) as boy_his_edit_time from t_boy_his hwhere h.boy_his_isteammate=1 and h.boy_his_state=1 and h.boy_his_editor_user_id=300000178518 group by h.boy_id order by h.boy_his_edit_time desc limit 0,2;

最终解决方案:此sql由查前面一个sql代替,删除。

案例6:分析归类后的慢查询日志如下。

______________________________________________________________________ 006 ___

Count: 30(0.48%)

Time: 940 s total, 31.333333 s avg, 3 s to 77 s max(2.76%)

95% of Time : 790 s total, 28.214286 s avg, 3 s to 69 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 1 avg, 1 to 1 max(0.05%)

Rows examined : 10.96k avg, 1.82k to 28.12k max(8.56%)

Database: docresource

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (30) of query, 100.00% (6256) of all users

Query abstract:

SELECT COUNT(*) FROM t_boy_his WHERE boy_his_check_expert_id_en = 'S' AND boy_his_check_state=N AND boy_his_deal_time BETWEEN 'S' AND 'S';

Query sample:

SELECT COUNT(*)FROM T_BOY_HISWHEREBOY_HIS_CHECK_EXPERT_ID_EN = 'uAwgHUUNYU1lfUFkJ' AND BOY_HIS_CHECK_STATE=1 AND BOY_HIS_DEAL_TIME BETWEEN '2009-02-16 00:00:00' AND '2009-02-24 00:00:00';

最终解决方案:此sql有用到BOY_HIS_CHECK_EXPERT_ID_EN的索引,再观察

案例7:分析归类后的慢查询日志如下。

______________________________________________________________________ 007 ___

Count: 134(2.14%)

Time: 823 s total, 6.141791 s avg, 3 s to 23 s max(2.41%)

95% of Time : 698 s total, 5.496063 s avg, 3 s to 15 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max (0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 10 avg, 2 to 10 max(2.31%)

Rows examined : 792 avg, 53 to 9.55k max(2.76%)

Database: 

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (134) of query, 100.00% (6256) of all users

Query abstract:

SELECT boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit FROM t_doc WHERE boy_state IN (N4) AND boy_creator_user_id_encrypt='S' ORDER BY boy_goodcount DESC LIMIT N,N;

Query sample:

select boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit from t_docwhere boy_state in (1,2,3,4) and boy_creator_user_id_encrypt='lGwdcWgJBBAtVCnER' order by BOY_GOODCOUNT desc limit 380,10;

最终解决方案:跟产品确认已经没用的功能,去掉

老男孩点评:数据库优化不一定就要该参数,建索引,有些过时的功能,还有后台内部的全表扫描等查询,可以单独加个从库,这是老男孩培训的根据内外业务选择读库的重要思路。

案例8:分析归类后的慢查询日志如下。

______________________________________________________________________ 008 ___

Count: 130(2.08%)

Time: 730 s total, 5.615385 s avg, 3 s to 21 s max(2.14%)

95% of Time : 614 s total, 4.99187 s avg, 3 s to 14 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 10 avg, 5 to 10 max(2.24%)

Rows examined : 763 avg, 32 to 4.16k max(2.58%)

Database: 

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (130) of query, 100.00% (6256) of all users

Query abstract:

SELECT boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit FROM t_doc WHERE boy_state IN (N4) AND boy_creator_user_id_encrypt='S' ORDER BY boy_goodcount ASC LIMIT N,N;

Query sample:

select boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit from t_docwhere boy_state in (1,2,3,4) and boy_creator_user_id_encrypt='bAQReRlFZX0BZW1oD' order by BOY_GOODCOUNT asc limit 370,10;

最终解决方案:跟产品确认已经没用的功能,去掉。

老男孩点评:不战而屈人之兵,这个很棒。当然,分业务,读不同的库,等等都是好的解决办法,而不是动不动就拆表拆库,大手术不是那么容易的,关键是有时有更简单的解决方案,都是一些架构会议搞的大家总是东施效颦,有时并不是唯一的方法。

案例9:分析归类后的慢查询日志如下。

______________________________________________________________________ 009 ___

Count: 83(1.33%)

Time: 527 s total, 6.349398 s avg, 3 s to 29 s max(1.54%)

95% of Time : 408 s total, 5.230769 s avg, 3 s to 16 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 1 avg, 1 to 1 max(0.14%)

Rows examined : 1.08k avg, 96 to 3.84k max(2.34%)

Database: 

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (83) of query, 100.00% (6256) of all users

Query abstract:

SELECT COUNT(DISTINCT h.boy_id) FROM t_boy_his h WHERE h.boy_his_isteammate=N AND h.boy_his_editor_user_id=N;

Query sample:

SELECT COUNT(DISTINCT H.BOY_ID) FROM T_BOY_HIS H WHERE H.BOY_HIS_ISTEAMMATE=1 AND H.BOY_HIS_EDITOR_USER_ID=300000328622;

最终解决方案:

使用editor_user_iden_docid索引

1,sql:SELECT h.boy_id FROM t_boy_his h WHERE h.boy_his_isteammate=N AND h. BOY_HIS_EDITOR_USER_ID_ENCRYPT =N group by boy_id;

2,取得前一sql返回的结果集的size().

案例10:分析归类后的慢查询日志如下。

______________________________________________________________________ 010 ___

Count: 94(1.50%)

Time: 511 s total, 5.43617 s avg, 3 s to 21 s max(1.50%)

95% of Time : 428 s total, 4.808989 s avg, 3 s to 11 s max

Lock Time (s) : 0 total, 0 avg, 0 to 0 max(0.00%)

95% of Lock : 0 total, 0 avg, 0 to 0 max

Rows sent: 10 avg, 3 to 10 max(1.60%)

Rows examined : 747 avg, 32 to 5.14k max(1.83%)

Database: 

Users: 

ett_oldboy@ 10.0.1.28 : 100.00% (94) of query, 100.00% (6256) of all users

Query abstract:

SELECT boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit FROM t_doc WHERE boy_state IN (N4) AND boy_creator_user_id_encrypt='S' ORDER BY boy_score DESC LIMIT N,N;

Query sample:

select boy_id,boy_class,boy_title,boy_creator_user_id,boy_creator_user_nick,boy_latest_edition,boy_latest_url,boy_created_time,boy_latest_edition_time,boy_inner_pic_count,boy_outer_pic_count,boy_keywords,boy_click_count,boy_his_count,boy_attendee_count,boy_summary,boy_state,boy_goodcount,boy_badcount,boy_first_img,boy_title_upper,boy_import_tag,boy_topic_count,boy_post_count,boy_creator_user_id_encrypt,boy_id_encrypt,boy_score,last_edit_user_id_en,champion_user_nick,champion_user_id_en,champion_credit from t_docwhere boy_state in (1,2,3,4) and boy_creator_user_id_encrypt='icVpAUWBxB2xOUUB1' order by BOY_SCORE desc limit 490,3;

最终解决方案:

alter table t_doc add index creator_user_iden_docscore(boy_creator_user_id_encrypt, BOY_SCORE);

索引清理:这些索引没起到作用,删除索引

alter table t_doc drop index IDX_BOY_BOY_CLASS

alter table t_doc drop index IDX_BOY_IMPORT_TAG

alter table t_boy_his drop index IDX_BOY_CLASS

老男孩点评:索引并非越多越好,曾经给个企业做技术顾问,由于有慢查询,结果管理员把表的所有字段都建立了索引,以为能解决问题,结果不但没解决问题,反而更慢了。数据库优化和战场打仗是一样的,法无定法只要能打败敌人,所有的力量和方法都是可以用的,这也说明了思路决定出路的重要性。


转载请注明linux系统运维
http://www.linuxyw.com/linux/jinglizhitian/20130524/454.html

------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
验证码: 点击我更换图片
栏目列表
推荐内容