本文转载自：http://www.mysqlops.com/2011/09/23/performance-schema.html

    简单介绍performance_schema数据库

MySQL 5.5新增一个存储引擎：命名PERFORMANCE_SCHEMA  ,主要用于收集数据库服务器性能参数。MySQL用户是不能创建存储引擎为PERFORMANCE_SCHEMA的表

performance_schema提供以下功能：

  1. 提供进程等待的详细信息，包括锁、互斥变量、文件信息；
  2. 保存历史的事件汇总信息，为提供MySQL服务器性能做出详细的判断；
  3. 对于新增和删除监控事件点都非常容易，并可以随意改变mysql服务器的监控周期，例如（CYCLE、MICROSECOND）

通过以上得到的信息，DBA能够较明细得了解性能降低可能是由于哪些瓶颈？

l  performance_schema功能开启和部分表功能

Performance的开启很简单，在my.cnf中[mysqld]加入performanc_schema，检查性能数据库是否启动的命令:

SHOW VARIABLES LIKE ‘performance_schema’;

若是返回的 值为ON，则说明性能数据库正常开启状态。

 

接下来你能看到每个表的变化：

1.Threads

SHOW PROCESSLIST;

SELECT * FROM performance_schema.threads;

看到theads表的作用了吗?监控服务器所有连接， thread_id这个在接下来非常有用，

2.Performance_timers

设置一些监控信息

root@localhost : performance_schema 05:23:28> SELECT * FROM performance_timers;

+————-+—————–+——————+—————-+

| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |

+————-+—————–+——————+—————-+

| CYCLE       |      2603393034 |                1 |             66 |

| NANOSECOND  |      1000000000 |             1000 |            682 |

| MICROSECOND |         1000000 |                1 |            227 |

| MILLISECOND |            1039 |                1 |            247 |

| TICK        |             100 |                1 |            634 |

+————-+—————–+——————+—————-+

Performance_timers指定mysql服务可用的监控周期，CYCLE表示按每秒检测2603393034次。下面会设置监控周期

root@localhost : performance_schema 05:20:33> select * from setup_timers;

+——+————+

| NAME | TIMER_NAME |

+——+————+

| wait | CYCLE      |

+——+————+

UPDATE setup_timers SET TIMER_NAME= ‘NANOSECOND’ WHERE NAME=’wait’;

 

3.Setup_consumers\ Setup_instruments

接下来设置哪些事件能够被收集

root@localhost : performance_schema 05:23:45> SELECT * FROM setup_consumers;

+———————————————-+———+

| NAME                                         | ENABLED |

+———————————————-+———+

| events_waits_current                         | YES     |

| events_waits_history                         | YES     |

| events_waits_history_long                    | YES     |

| events_waits_summary_by_thread_by_event_name | YES     |

| events_waits_summary_by_event_name           | YES     |

| events_waits_summary_by_instance             | YES     |

| file_summary_by_event_name                   | YES     |

| file_summary_by_instance                     | YES     |

+———————————————-+———+

UPDATE setup_consumers SET ENABLED = ‘YES’ WHERE NAME=’ events_waits_history’;（表示能够被收集）

UPDATE setup_instruments SET ENABLED=’YES’ WHERE NAME=’ wait/synch/mutex/sql/PAGE::locK’;

 

实验收集等待信息的实例

到目前为止没有测试过是否能够检测到异常进程，见下来看看采集的数据

root@localhost : performance_schema 06:54:34> show processlist;

+——+——+———–+——————–+———+——+

| Id   | User | Host      | db                 | Command | Time |

+——+——+———–+——————–+———+——+

| 2731 | root | localhost | test               | Query   |   67 |

| 2732 | root | localhost | test               | Sleep   |  139 |

| 2733 | root | localhost | performance_schema | Query   |    0 |

+——+——+———–+——————–+———+——+

root@localhost : performance_schema 06:54:16> SELECT * FROM threads where PROCESSLIST_ID IN(2731,2732,2733);

+———–+—————-+—————————+

| THREAD_ID | PROCESSLIST_ID | NAME                      |

+———–+—————-+—————————+

|      2742 |           2732 | thread/sql/one_connection |

|      2741 |           2731 | thread/sql/one_connection |

|      2743 |           2733 | thread/sql/one_connection |

+———–+—————-+—————————+

 

 

 Session1  PID=2732; THREAD_ID: 2742Session2  PID 2731;THREAD_ID: 2741Session3 查看监控信息
1LOCK TABLE task WRITE  
2 START TRANSACTIONupdate task set type=3 where uid=1238 and tdid=117004 and date=20110522;wait……………………. 
3  root@localhost : performance_schema 07:00:31> SELECT * FROM events_waits_current WHERE TIMER_END IS NULL\G;*************************** 1. row ***************************THREAD_ID: 2741EVENT_ID: 63EVENT_NAME: wait/synch/cond/sql/MDL_context::COND_wait_statusSOURCE: mdl.cc:983TIMER_START: 99074136559454208TIMER_END: NULLTIMER_WAIT: NULLSPINS: NULL

OBJECT_SCHEMA: NULL

OBJECT_NAME: NULL

OBJECT_TYPE: NULL

OBJECT_INSTANCE_BEGIN: 453433776

NESTING_EVENT_ID: NULL

OPERATION: timed_wait

NUMBER_OF_BYTES: NULL

FLAGS: 0

1 row in set (0.00 sec)

 

4  root@localhost : performance_schema 07:01:51> SELECT * FROM mutex_instances WHERE LOCKED_BY_THREAD_ID IS NOT NULL;+————————————————-+———————–+———————+| NAME                                                                | OBJECT_INSTANCE_BEGIN | LOCKED_BY_THREAD_ID |+————————————————-+———————–+———————+| wait/synch/mutex/sql/MDL_wait::LOCK_wait_status |              453433720 |                2741 |+————————————————-+———————–+———————+
5Unlock tables  

在3步的Session3中看到events_waits_current ,看到Seesion2正在等待某个一个前提条件的释放，这个表中包含有正在等待哪个前提条件、OPERATION什么类型、SOURCE源代码位置、OBJECT_INSTANCE_BEGIN内存开始的位置

在4步的session3中mutex_instances表，存储着session2正在等待的是一个MDL的互斥变量的释放，OBJECT_INSTANCE_BEGIN内存开始位置453433720



Logo
一门面向 Data 和 AI 的低代码、云原生的开源编程语言

无需安装部署，在线快速体验 Byzer

更多推荐

编译时权限控制

前言 权限控制，对于 MLSQL 而言的重要程度可以说是生命线。 MLSQL 需要面对各式各样的资源访问，比如 MySQL, Oracle,HDFS，Hive，Kafka，Sorl，ElasticSearch，Redis，API，Web等等，不同用户对这些数据源（以及表，列）的权限是不一样的。 传统模式是，每个用户都需要有个 proxy user，然后到每个数据源里面给这个 proxy user

avatar Byzer 白泽

Byzer 支持 JDBC 聚合下推

聚合下推PR链接聚合下推 我们知道 Byzer 支持多数据源和联邦查询，可以方便分析师在一个平台上快速的分析来自多种数据源的数据，从而进行灵活的探索式分析。 使用场景和优势 当前 Byzer 中加载数据的方式会拉取明细数据到 spark 中进行聚合计算，对于小数据量或者在分布式文件系统上的数据源来说是常规操作。但是对于 JDBC 数据源或者有分析能力的 OLAP 系统来说拉取明细数据可能就不是最

avatar Byzer 白泽

Byzer 术语表

Byzer-lang Byzer ，又称为 Byzer-lang，一门面向 Data 和 AI 的低代码、云原生的开源编程语言。 Byzer 是一门结合了声明式编程和命令式编程的混合编程语言，其低代码且类 SQL 的编程逻辑配合内置算法及插件的加持，能帮助数据工作者们高效打通数据链路，完成数据的清洗转换，并快速地进行机器学习相关的训练及预测。 Byzer 希望能够提供一套语言、一个引擎，就能覆盖整

avatar Byzer 白泽