SQL查询优化

数据库服务器优化步骤

整个流程划分成了观察(Show status)和行动(Action)两个部分。字母 S 的部分代表观察(会使用相应的分析工具),字母 A 代表的部分是行动(对应分析可以采取的行动)。


image.png
  1. 在S1部分,需要观察服务器的状态是否存在周期性的波动。如果存在周期性的波动,有可能是周期性节点的原因,比如双十一,促销活动等。这样的话,可以通过A1 加缓存或者更改缓存失效策略;
  2. 如果缓存策略没有解决,或者不是周期性波动的原因,需要进一步分析查询延迟和卡顿的原因。进行S2这一步,此时需要打开慢查询。慢查询可以帮我们定位执行慢的SQL语句。通过设置long_query_time参数定义“慢”的阈值,如果SQL执行时间超过了long_query_time,则会认为是慢查询。收集到慢查询后,通过分析工具对慢查询日志进行分析;
  3. 知道了执行慢的SQL语句之后,可以针对性地用EXPLAIN查看对应SQL语句的执行计划,或者使用SHOW PROFILE查看SQL中每一个步骤的时间成本。这样就可以了解SQL查询慢是因为执行时间长,还是等待时间长;
  4. 如果是SQL等待时间长,则进入A2步骤中。可以调优服务器的参数,比如适当增加数据库缓冲池等。如果是SQL执行时间长,就可以进入A3。此时需要考虑是索引涉及的问题?还是查询关联的数据表过多?还是因为数据表的字段设计问题。
  5. 如果A2和A3都不能解决问题,需要思考数据库自身的SQL查询性能是否已经达到了瓶颈,如果没有达到性能瓶颈,需要重新检查。若已经到达了性能瓶颈,进入A4阶段,需要考虑增加服务器,采用读写分离的架构,或者考虑对数据库分库分表等。

SQL调优的三个步骤

  1. 获取慢查询SQL

    // 查看慢查询是否开启,以及慢查询日志文件的位置
    mysql > show variables like '%slow_query_log';
    // 开启慢查询
    mysql > set global show_query_log='ON';
    // 查看慢查询的时间阈值
    mysql > show variables like '%long_query_time%';
    // 设置慢查询的时间阈值
    mysql > set global long_query_time = 3;
    

    通过mysqldumpslow工具(这个工具是个 Perl 脚本,你需要先安装好 Perl)提取想要查询的SQL语句,mysqldumpslow命令的具体参数如下:

    • -s:采用 order 排序的方式,排序方式可以有以下几种。分别是 c(访问次数)、t(查询时间)、l(锁定时间)、r(返回记录)、ac(平均查询次数)、al(平均锁定时间)、ar(平均返回记录数)和 at(平均查询时间)。其中 at 为默认排序方式;
    • -t:返回前 N 条数据 ;
    • -g:后面可以是正则表达式,对大小写不敏感;
  2. 使用EXPLAIN查看执行计划
    EXPLAIN 可以帮助我们了解数据表的读取顺序、SELECT 子句的类型、数据表的访问类型、可使用的索引、实际使用的索引、使用的索引长度、上一个表的连接匹配条件、被优化器查询的行的数量以及额外的信息(比如是否使用了外部排序,是否使用了临时表等)等

    mysql >  EXPLAIN SELECT comment_id, product_id, comment_text, product_comment.user_id, user_name FROM product_comment JOIN user on product_comment.user_id = user.user_id ;
    
    image.png

    数据表的访问类型所对应的 type 列是我们比较关注的信息。type 可能有以下几种情况:
    image.png
    • all 是最坏的情况,因为采用了全表扫描的方式。index 和 all 差不多,只不过 index 对索引表进行全扫描,这样做的好处是不再需要对数据进行排序,但是开销依然很大;
    • range 表示采用了索引范围扫描,这里不进行举例,从这一级别开始,索引的作用会越来越明显,因此我们需要尽量让 SQL 查询可以使用到 range 这一级别及以上的 type 访问方式;
  3. 使用SHOW PROFILE查看SQL的具体执行成本
    SHOW PROFILE 相比 EXPLAIN 能看到更进一步的执行解析,包括 SQL 都做了什么、所花费的时间等。

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

推荐阅读更多精彩内容