专栏首页AustinDatabasesMYSQL 从如何尝试抛弃慢查询谈起

MYSQL 从如何尝试抛弃慢查询谈起

MYSQL 的慢查询一般是开发人员和DBA,获取糟糕的SQL和可能缺少索引的一种方法,这样的方法已经伴随了MYSQL 一致到了MYSQL 5.7,但是否我们可以有其他的方法来获取这样的可用性的信息,进而减少对SLOW LOG的依赖,这是一个可以探讨的问题。(这里不是要替代,而是抱着学习和探索的心态,也抱着顺应发展的一种心态)

大部分关注MYSQL的 DBAer, 可能都知道从MYSQL5.6 开始MYSQL的风向标是靠近ORACLE的风格的,而众所周知,ORALCE, SQL SERVER 这样的数据库是没有例如MYSQL 这样的慢查询系统的。

那这里想说的是如果通过非慢查询的方式来去找到一些系统问题,并且行之有效,当然这里并不是说要抛弃慢查询,多一种方法,多一种程序设计者推荐给你的方法,自然是有很多好处的。

下面我们就此探讨一下

1 问题:我做DDL时是否可以得知多长时间做完?

这个问题估计,如果知识不更新的MYSQL DBA回答起来会比较费劲,的确传统是有方法的,但不是很准,具体怎么做,大家百度一下。(使用PT工具的活CQ的不在此次讨论范围)

今天想说的MYSQL 5.7 已经提供了准确的方法来提供你来知道你的DDL 到底做到哪里了,而不是一味的等待,等到那里算哪里。

那我们需要了解哪些知识

1 一个 alter 会产生哪些事件

1 read PK and internal sort

2 merge sort

3 insert

4 log apply index

5 flush

6 log apply table

7 end

如何操作,首先我们先打开 performance_schema_setup_instrumets 和 performance_schema.setup_consumers

然后我们可以找一个大表 100万以上的,去做一个DDL 的操作,然后执行下面的语句

我们可以很清晰的从上面的两个图中获知,我们的DDL操作到了哪一步,到底运行到哪里,稍微动一点手腕就可以通过百分比的方式展示。

2 对某些慢语句的监控,以及互斥锁的监控

对于只能在一个时间段中被独占的资源,必然会产生互斥,而如何监控他们在原来的MYSQL 中是比较麻烦的,如何识别等待较长的事件,或对象则是一个需要解决的问题。

MYSQL可以通过 events_stages_summry_global_by_event_name,来监控某些等待,通过这些参数去了解MYSQL中可能正在经历,或要面对的问题。

我们下面举一些列子,通过以下方法就可以直接跨过 SLOW_LOG的方式

SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT FROM performance_schema.events_statements_history_long where SQL_TEXT IS NOT NULL;

很明显通过下面的查询我们可以看到系统中运行的语句,并且很快得知每条语句的执行时间,从这点其实我们已经可以不通过慢查询来获得语句运行的时间,时间单位是秒。

我们可以通过对语句的分析,找到慢的语句而不使用慢查询系统,同时我们也可以通过监控系统的设计,来绘制出一个数据库系统的某些参数的变化,方便去查看一些突发事件,快速的发现问题。

select * from events_stages_summary_by_account_by_event_name where MIN_TIMER_WAIT <> 0 and user='app_collection';

上面的语句稍微变动一下,你就可以获得MYSQL 某个数据库的系统的等待时间,如果每几秒取一次,对某些问题的发现是会有好处的。

其实以上的东西仅仅是冰山一角,MYSQL的变化还未提及 MYSQL 8 ,MYSQL 8 将更适合更多环境,而非互联网的应用。我们还的继续学习,不松懈。

下面是毒鸡汤时间:

No matter how long night, the arrival of daylight association。

So just wait !

本文分享自微信公众号 - AustinDatabases(AustinDatabases),作者:carol11

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-03-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • “偶遇” 爱可生 与 MYSQL 大型应用

    今天“偶遇” 爱可生的技术人员,经过了两个小时的交流,又重塑的我对大型系统中对MYSQL 的应用, 这绝对不是广告,这绝对不是广告,这绝对不是广告,重要的还的说...

    AustinDatabases
  • MYSQL 8 GROUP REPLICATION 的新感觉

    MYSQL 8 Group Replication 最近开始做实验了,MYSQL 5.7的MGR 在使用了不到一年的时间里面,发现了不少问题,也解决了不少问题。...

    AustinDatabases
  • MYSQL 8 vs MYSQL 5.7 ORACLE 到底怎么想的? (二)

    1 在MYSQL 5.7 临时表包含了一个 "converting HEAP to on disk", 意思当临时表达到最大的内存使用的限制(一个表一个)16M...

    AustinDatabases
  • “偶遇” 爱可生 与 MYSQL 大型应用

    今天“偶遇” 爱可生的技术人员,经过了两个小时的交流,又重塑的我对大型系统中对MYSQL 的应用, 这绝对不是广告,这绝对不是广告,这绝对不是广告,重要的还的说...

    AustinDatabases
  • MYSQL 8 vs MYSQL 5.7 ORACLE 到底怎么想的? (二)

    1 在MYSQL 5.7 临时表包含了一个 "converting HEAP to on disk", 意思当临时表达到最大的内存使用的限制(一个表一个)16M...

    AustinDatabases
  • MYSQL 8 GROUP REPLICATION 的新感觉

    MYSQL 8 Group Replication 最近开始做实验了,MYSQL 5.7的MGR 在使用了不到一年的时间里面,发现了不少问题,也解决了不少问题。...

    AustinDatabases
  • MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

    MySQL 8 最终是要大面积替换MYSQL5.7 , 之前的文字可能给人感觉MYSQL 8 还不如 MYSQL 5.7 ,实际上不然,任何东西新的一定有问题,...

    AustinDatabases
  • MYSQL What's new in 优化和执行 来自旧金山的问候

    以下内容采集自 2019年9月19日 San Francisco Oracle open 大会内容。主题 What’s New in MySQL Optim...

    AustinDatabases
  • MYSQL 8 Serialized Dictionary Information

    随着MYSQL 8 越来越稳定,并且开始使用的人和公司越来越多起来,掌握MYSQL 8 的工具变得越来越重要。不赶到别人前头,那就只能follower.

    AustinDatabases
  • MYSQL VS PostgreSQL 外国佬怎么选--那个更好?

    MYSQL vs PostgreSQL 的话题应该属于经久不衰的话题,类似 REDIS VS MONGODB (我比较奇怪这两个是怎么被强拉硬拽到一起的)。作为...

    AustinDatabases

扫码关注云+社区

领取腾讯云代金券