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 !