对于慢sql的诊断,有什么通用的套路?

群内IT疑难问题集锦01

问题:对于慢sql的诊断,有什么通用的套路?

投票最佳回答:

[回答6]:暮雨

一条sql语句的执行,对于我们来说就是一个黑盒,我们若要定位和解决问题,就要弄明白这条sql语句在数据库内部经历了怎样的过程?以下简单的对数据库的内部做下拆解(参考mysql)

第一步,客户端和服务端三次握手建立连接,服务端有一个被称为连接器的功能组件接受连接,签权,管理连接等

第二步,有一个被称为分析器的组件对sql语句做词法,语法分析,我们常看到的一些sql语法的报错,就来自它的处理

第三步,在数据库服务的内部有一个叫优化器的组件会对sql语句做一些优化,如外连接转换为内连接、表达式简化、子查询转为连接等,最终生成一个执行计划,我们可以使用explain来查看执行计划

第四步,这一步可以称作执行器,根据优化器得到的执行方案,调用底层存储引擎提供的API,完成对数据的操作。 当然,对于一个高性能的系统,缓存的设计是不可缺少的,连接器后,存在一个缓存的机制,在此就不做展开。

由以上的原理性东西解析可知,影响整个sql执行的在第四布,因为在这一步中,要和底层的数据存储引擎进行交互,会要大量的磁盘I/O,我们知道CPU对内存和磁盘的读写效率有很大的区别。 对于只存在read操作的sql的语句,我们可以通过添加索引来提高磁盘I/O的效率,但若,write大于read操作,这时索引又会导致write操作的效率,这也是常做数据库读写分离的一个原因。 对于sql语句的优化,现在有一些开源的sql优化平台,如:美团的https://github.com/Meituan-Dianping/SQLAdvisor, 小米的https://github.com/XiaoMi/soar/,这些融入了大量DBA工程师的经验,所以,我们可以借助这些平台对sql进行优化。

其它回答参考:

[回答1]:Zerp

先是检查:查看日志,检查执行计划。

再是解决:从业务层面,审查业务设计,调整不必要的跨大维度时间查询,如果要做模糊查询,走搜索引擎;

从代码层面:1)检查sql语句,where、order、join的地方都着重检查,看看有没有全表扫描;2)分库分表;

从环境层面:1)检查服务器性能;2)检查网络情况。

[回答2]:Adios.

系统层面:检查系统服务器运行情况,磁盘io等;

数据库层面:

1)多次执行showprocesslist查看是否存在异常的 SQL;

2)定位到目标执行很频繁并time很长的SQL语句,对该 SQL及相关的表进行分析,用explain、showindex、showtablestatus等命令

3)优化sql语句、优化索引、表关联等。

[回答3]:春晓

慢sql会引起内存和cpu占用率高,导致服务器负载高,严重可能影响业务的正常运行。

首先可以通过日志分析来定位慢sql,通过慢查询日志分析,就可以找到最耗时的SQL,然后进行具体的SQL分析;

其次需要确认sql语句引起慢查询的原因,可通过使用Explain分析SQL语句执行计划和使用Profiles分析SQL语句执行时间和消耗资源;

最后就是索引的优化了,但是并不是所有的字段都适合创建索引,还需要根据具体的字段内容进行选择。

[回答4]:Theodore

1、对于MySQL来说,通过慢日志定位慢SQL;

2、对于慢SQL,查看其执行计划,分析耗时的原因;

3、如果缺失索引,根据业务需求,创建合适的索引;如果由于SQL语句的写法有问题,需要根据业务逻辑优化语句的写法。

[回答5]:八咫琼勾玉

以mysql为例,慢查询不仅指select,delete、insert、update等dml操作若超时,都可以称作慢查询或者慢sql,出现慢查询,应从整个集群架构着手优化。

我从运维角度说说诊断+优化 物理硬件升级,使用ssd硬盘,怼内存,生产环境内存建议64G起步,提高数据库io性能。 操作系统调优,建议使用x86_64的Linux系统;使用xfs文件系统;优化tcp协议栈;优化系统套接字缓冲区。 数据库架构调整:mycat分库分表;搭建主从复制,主库只负责写,从库只负责读,能够有效缓解主库压力,提高并发能力。 使用MongoDB、Redis、memcache等NoSQL数据库,为mysql做一层缓存 网络层,数据库与应用服务器尽量在同一物理网络空间内,避免跨区域跨网段。

查找慢查询及sql语句的优化 :

-慢查询: 开启慢查询日志 主要参数: slow_query_log on开启 off关闭(默认) slow_query_log_file 指定慢查询日志保存位置 log_query_time 定义用时多久的的查询为慢查询 log_queries_not_using_indexes将未使用索引的语句记录 可以使用mysqldumpslow(mysql自带),mysqlsla等工具分析慢查询语句。 在查询到低效率sql语句后,使用explain或desc命令获取mysql如何执行语句的信息,为表建立索引。

-sql语句的优化: 1.严格区分大小写 2.避免全表扫描: 尽量使用(not)exists替代(not)in这样的操作 尽量避免在where字句中进行null判断 where字句中使用or时,所有条件都应是独立索引,否则避免使用 3.索引不是越多越好,索引会提高select,但也会降低insert、update的效率 ......更多sql语句优化,请自行百度!!!



©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,390评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,821评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,632评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,170评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,033评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,098评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,511评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,204评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,479评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,572评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,341评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,213评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,576评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,893评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,171评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,486评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,676评论 2 335

推荐阅读更多精彩内容