首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >MySQL优化案例(二)

MySQL优化案例(二)

作者头像
jeanron100
发布于 2019-05-17 07:36:07
发布于 2019-05-17 07:36:07
70400
代码可运行
举报
运行总次数:0
代码可运行

这是学习笔记的第 1979 篇文章

近期收到慢日志监控报警,在慢日志平台查看,主要瓶颈在于几条创建临时表的SQL语句,占用了大量的临时空间,需要优化。

SQL语句为:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
create temporary table `tem_expireClassID`
 (
  select distinct class_id
  from dic_fsm_map_relation
  where game_id = 1
   and state = 0
   and class_id not in ( 
    SELECT distinct json_extract(fsm_info,'$.FSM.ClassID') 
     FROM dic_fsm_info 
     where state = 0
      and json_extract(fsm_info,'$.FSM.ETime') > unix_timestamp(now())
  )
  order by class_id;

两个表的数据量都在几千条,其实不算多,但是执行时间却差很多。

执行时间为150秒左右。

执行计划为:

+----+--------------------+----------------------+------------+------+---------------+------+---------+------+------+----------+------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+--------------------+----------------------+------------+------+---------------+------+---------+------+------+----------+------------------------------+ | 1 | PRIMARY | dic_fsm_map_relation | NULL | ALL | plat_id | NULL | NULL | NULL | 2403 | 1.00 | Using where; Using temporary | | 2 | DEPENDENT SUBQUERY | dic_fsm_info | NULL | ALL | NULL | NULL | NULL | NULL | 1316 | 10.00 | Using where | +----+--------------------+----------------------+------------+------+---------------+------+---------+------+------+----------+------------------------------+ 2 rows in set, 1 warning (0.00 sec)

系统层优化:

系统临时表空间占用150G左右

[root@hb30-dba-mysql-tgp-124-34 data]# ll total 157854040 -rw-r----- 1 mysql mysql 362 Apr 26 2018 ib_buffer_pool -rw-r----- 1 mysql mysql 2818572288 May 13 14:41 ibdata1 -rw-r----- 1 mysql mysql 158792155136 May 13 14:40 ibtmp1 drwxr-x--- 2 mysql mysql 4096 Apr 18 2018 infra drwxr-x--- 2 mysql mysql 4096 Apr 18 2018 mysql

经过系统优化和业务协调需要做MySQL实例重启,已重置为初始大小,设置阈值为10G。

SQL层优化

SQL语句的优化分析发现,基于json类型的解析差异和字符类型存在较大的性能差异,建议对json的子查询创建临时表。

测试步骤如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
create table dic_fsm_info3 (classid varchar(30),etime varchar(30));    --可以根据业务特点创建索引
mysql> insert into dic_fsm_info3 select  distinct json_extract(fsm_info,'$.FSM.ClassID') ,json_extract(fsm_info,'$.FSM.ETime') from tgp_db.dic_fsm_info where state=0;
Query OK, 334 rows affected (0.12 sec)
Records: 334  Duplicates: 0  Warnings: 0

重新执行语句,执行时长优化只0.2秒左右。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select distinct class_id from tgp_db.dic_fsm_map_relation
where game_id = 1
and state = 0
and class_id not in ( 
    SELECT distinct classid 
    FROM dic_fsm_info3 
    where etime > unix_timestamp(now())
)

|     2704 |
|     2705 |
|     2707 |
|     2715 |
+----------+
73 rows in set (0.23 sec)

JSON类型的解析效率可以通过profile的对比方式来分析:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
mysql> show profile cpu for query 1;
+--------------------+----------+----------+------------+
| Status             | Duration | CPU_user | CPU_system |
+--------------------+----------+----------+------------+
| Sending data       | 0.047225 |     NULL |       NULL |
| executing          | 0.000002 |     NULL |       NULL |
| Sending data       | 0.047196 |     NULL |       NULL |
| executing          | 0.000004 |     NULL |       NULL |

而根据字符类型匹配,效率要高两个数量级。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
+--------------------+----------+----------+------------+
| Status             | Duration | CPU_user | CPU_system |
+--------------------+----------+----------+------------+
| Sending data       | 0.000128 |     NULL |       NULL |
| executing          | 0.000001 |     NULL |       NULL |
| Sending data       | 0.000126 |     NULL |       NULL |
| executing          | 0.000001 |     NULL |       NULL |

后续对JSON类型的使用也需要注意以下。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-05-14,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
MySQL案例:count(*)和count(1)的效率问题
相信大多数DBA都看见过这样一条SQL优化原则:用count(1)替换count(*);相信也有不少DBA因这个问题被开发diss过,用count(*)非常慢,应该用count(1),然后改用count(1)后,还真是秒出结果;那么究竟是什么回事呢?count(1)真的比count(*)快那么多吗?count(1)和count(*)的区别究竟在哪里?接下来我们就来一一揭晓。
brightdeng@DBA
2020/10/26
3.9K0
MySQL案例:count(*)和count(1)的效率问题
MYSQL学习笔记——sql语句优化工具
一、定位慢查询                                                                                
Java架构师必看
2022/02/27
9370
MySQL进阶笔记-3(MySQL优化)
在应用的的开发过程中,由于初期数据量小,开发人员写 SQL 语句时更重视功能上的实现,但是当应用系统正式上线后,随着生产数据量的急剧增长,很多 SQL 语句开始逐渐显露出性能问题,对生产的影响也越来越大,此时这些有问题的 SQL 语句就成为整个系统性能的瓶颈,因此我们必须要对它们进行优化,本章将详细介绍在 MySQL 中优化 SQL 语句的方法。
千羽
2021/01/14
5060
MySQL进阶笔记-3(MySQL优化)
MySQL 有效利用 profile 分析 SQL 语句的执行过程
在日常的工作中,我们通常要分析 SQL 语句的性能,通过会使用到执行计划,利用执行计划来分析 SQL 语句的性能,并进行相应的优化;本文将利用 profile 分析 SQL 语句的执行过程来辅助的分析 SQL 语句,做好优化;
JiekeXu之路
2019/06/20
5K0
MySQL 有效利用 profile 分析 SQL 语句的执行过程
捅破窗户纸-入门MySQL调优之性能监控
MySQL Server的逻辑架构一般分为三层:服务层(专门为客户端服务)、MySQL Server核心层和存储引擎。
行百里er
2020/12/02
1.1K0
捅破窗户纸-入门MySQL调优之性能监控
MySQL 5.7 统计表记录数执行效率对比分析
墨墨导读:MySQL在统计表记录数时,指定使用主键查询反而慢,在执行效率上进行对比分析。
数据和云
2020/07/15
2.8K0
MySQL SQL剖析(SQL profile)
    分析SQL执行带来的开销是优化SQL的重要手段。在MySQL数据库中,可以通过配置profiling参数来启用SQL剖析。该参数可以在全局和session级别来设置。对于全局级别则作用于整个MySQL实例,而session级别紧影响当前session。该参数开启后,后续执行的SQL语句都将记录其资源开销,诸如IO,上下文切换,CPU,Memory等等。根据这些开销进一步分析当前SQL瓶颈从而进行优化与调整。本文描述了如何使用MySQL profile,不涉及具体的样例分析。
Leshami
2018/08/13
4.2K0
使用pt-query-digest分析mysql慢日志
首先分析报警的时间点,这里我们用alert_time来表示,那么导致报警的SQL很有可能在这个时间点附近,这里用到linux中的sed命令来把日志先截取出来,sed命令的使用方法如下:
AsiaYe
2019/11/06
2.2K0
使用pt-query-digest分析mysql慢日志
MySQL: 使用show profiles分析SQL性能
分析SQL执行带来的开销是优化SQL的重要手段。在MySQL数据库中,可以通过配置profiling参数来启用SQL剖析。该参数可以在全局和session级别来设置。对于全局级别则作用于整个MySQL实例,而session级别紧影响当前session。该参数开启后,后续执行的SQL语句都将记录其资源开销,诸如IO,上下文切换,CPU,Memory等等。根据这些开销进一步分析当前SQL瓶颈从而进行优化与调整
大忽悠爱学习
2021/11/15
1.5K0
MySQL 怼了架构师关于 optimize table 需求 与 为什么反对 optimize table
2024年1月某些星象的原因,导致我个人的星盘在1月大概率要和某些人要有不愉快。这不就来了,在一次关于mysql 数据库数据表清理后,关于optimize table 的问题上,我毫无悬念的和架构师们进行了一次非常不nice 的沟通。
AustinDatabases
2024/01/14
7650
MySQL  怼了架构师关于 optimize table 需求 与 为什么反对 optimize table
索引(MySQL)
索引:提高数据库的性能,索引是物美价廉的东西了。不用加内存,不用改程序,不用调sql,只要执行 正确的 create index ,查询速度就可能提高成百上千倍。但是天下没有免费的午餐,查询速度的提高 是以插入、更新、删除的速度为代价的,这些写操作,增加了大量的IO。所以它的价值,在于提高一个 海量数据的检索速度。
ljw695
2025/05/31
1360
索引(MySQL)
MySQL 8.0新特性: 数据字典
目前MySQL 8.0最新版本为8.0.23版本,针对8.0的新特性,从春节前开始做了一些相关学习和测试,后续会不阶段的分享一些8.0的新特性,供大家一起参考和学习;
SEian.G
2021/03/03
2.4K0
MySQL优化案例分享
临近十一,国庆放假的同时,往往会伴随着国庆期间业务要上相关的活动,那么今天就分享一个今年五一前夕(4月30日)上新活动中遇到的一个性能问题;
SEian.G
2021/10/12
8470
Mysql高级2-SQL性能分析
  MySQL客户端 连接成功后,通过show [session | global] status 命令可以提供服务器状态信息,通过如下指令,可以查看当前数据库的insert,update,dalete,select的访问频次
Se7eN_HOU
2023/07/31
2930
Docker下MySQL主从三部曲之三:binlog日志参数实战
本章是《Docker下MySQL主从三部曲》的终篇,前面的章节我们能够制作镜像来搭建主从同步环境,本章我们来观察binlog参数MASTER_LOG_POS;
程序员欣宸
2022/05/06
4840
MYSQL排查使用CPU多的SQL
问题sql: select count(*) from db1.sbtest1,db1.sbtest2;
大大刺猬
2022/11/01
1.6K0
傻瓜MySQL查询缓存都不知道...
我们知道,缓存的设计思想在RDBMS数据库中无处不在,就拿号称2500w行代码,bug堆积如山的Oracle数据库来说,SQL的执行计划可以缓存在library cache中避免再次执行相同SQL发生硬解析(语法分析->语义分析->生成执行计划),SQL执行结果缓存在RESULT CACHE内存组件中,有效的将物理IO转化成逻辑IO,提高SQL执行效率。
敖丙
2021/01/08
8670
傻瓜MySQL查询缓存都不知道...
MySQL 开发实践 8 问,你能 hold 住几个?
王昂
2016/11/16
11.3K4
MySQL 开发实践 8 问,你能 hold 住几个?
MySQL关于数据字典的一个疑问
今天看着MySQL的数据字典,突然想到一个问题:为什么MySQL数据字典 information_schema中的表名是大写,而performance_schema和其他库中的是小写? 带着这个问题,我开始了一些猜测和自我论证。 首先大小写的这个情况是相对不兼容的。 比如在performance_schema中,根据关键字user可以找到两个相关的表。 mysql> show tables like 'user%'; +--------------------------------------+ | T
jeanron100
2018/03/22
9510
MySQL关于数据字典的一个疑问
Mysql基础篇--面试如何定位低效率sql语句
当面对一个sql性能问题,我们应该从何处入手使得尽快定位问题sql,我们从基础的命令开始
小土豆Yuki
2020/06/15
1.1K0
相关推荐
MySQL案例:count(*)和count(1)的效率问题
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档