您的位置:彩神快三 > 公司简介 > 初相识|performance_schema全方位介绍(一)

初相识|performance_schema全方位介绍(一)

发布时间:2019-10-17 09:57编辑:公司简介浏览(120)

    原标题:初相识|performance_schema全方位介绍(一)

    图片 1

    罗小波·沃趣科学技术尖端数据库本领行家

    出品:沃趣科学和技术

    IT从业多年,历任运营技术员、高等运行程序员、运营高管、数据库程序员,曾涉足版本发布种类、轻量级监察和控制系统、运营处理平台、数据库管理平台的布署性与编写制定,领悟MySQL种类布局,Innodb存款和储蓄引擎,喜好专研开源技艺,追求完善。

    |目 录1、什么是performance_schema

    2、performance_schema使用便捷入门

    2.1. 检查当前数据库版本是或不是援助

    2.2. 启用performance_schema

    2.3. performance_schema表的归类

    2.4. performance_schema轻巧陈设与使用

    |导 语十分久此前,当小编还在品味着系统地球科学习performance_schema的时候,通过在网络各类搜索资料进行学习,但很缺憾,学习的法力实际不是很明朗,相当多标称类似 "深入显出performance_schema" 的稿子,基本上都以这种动不动就贴源码的作风,然后深切了后头却出不来了。对系统学习performance_schema的功力甚微。

    这段日子,很乐意的告知我们,我们依照 MySQL 官方文书档案加上大家的印证,整理了一份可以系统学习 performance_schema 的质地分享给大家,为了方便我们阅读,大家整理为了叁个文山会海,一共7篇文章。下边,请随行大家一同起来performance_schema系统的就学之旅吧。

    本文首先,大致介绍了哪些是performance_schema?它能做什么样?

    然后,简介了什么急忙上手使用performance_schema的方法;

    聊到底,简介了performance_schema中由哪些表组成,那些表大概的职能是何等。

    PS:本连串小说所使用的数据库版本为 MySQL 官方 5.7.17版本

    |1、**什么是performance_schema**

    MySQL的performance schema 用于监察和控制MySQL server在八个异常的低等别的运营进程中的财富消耗、能源等待等情景,它装有以下特点:

    1. 提供了一种在数据库运维时实时检查server的中间推市场价格况的秘技。performance_schema 数据库中的表使用performance_schema存款和储蓄引擎。该数据库着重关怀数据库运营进度中的质量相关的数目,与information_schema不同,information_schema主要关注server运转进度中的元数据音讯
    2. performance_schema通过监视server的风云来落到实处监视server内部运营状态, “事件”正是server内部活动中所做的别样工作以至对应的时日消耗,利用这么些音讯来判别server中的相关能源消耗在了哪个地方?常常的话,事件能够是函数调用、操作系统的等候、SQL语句施行的级差(如sql语句试行进度中的parsing 或 sorting阶段)或许全部SQL语句与SQL语句集合。事件的征集能够方便的提供server中的相关存款和储蓄引擎对磁盘文件、表I/O、表锁等财富的一块儿调用新闻。
    3. performance_schema中的事件与写入二进制日志中的事件(描述数据修改的events)、事件布署调治程序(那是一种存款和储蓄程序)的风浪分裂。performance_schema中的事件记录的是server实践有个别活动对少数能源的花费、耗费时间、这几个活动实践的次数等情状。
    4. performance_schema中的事件只记录在地点server的performance_schema中,其下的这个表中数据爆发变化时不会被写入binlog中,也不会通过复制机制被复制到别的server中。
    5. 日前活蹦乱跳事件、历史事件和事件摘要相关的表中记录的新闻。能提供有些事件的施行次数、使用时间长度。进而可用来深入分析某些特定线程、特定对象(如mutex或file)相关联的活动。
    6. PERFORMANCE_SCHEMA存款和储蓄引擎使用server源代码中的“检查实验点”来兑现事件数量的搜集。对于performance_schema达成机制自己的代码未有相关的单独线程来检验,那与别的职能(如复制或事件布署程序)区别
    7. 搜集的风浪数量存款和储蓄在performance_schema数据库的表中。那一个表能够使用SELECT语句询问,也能够应用SQL语句更新performance_schema数据库中的表记录(如动态修改performance_schema的setup_*初叶的多少个布局表,但要注意:配置表的改变会立刻生效,那会潜移暗化多少征求)
    8. performance_schema的表中的数目不会长久化存款和储蓄在磁盘中,而是保存在内部存款和储蓄器中,一旦服务重视启,这几个数量会甩掉(包罗配置表在内的整套performance_schema下的具有数据)
    9. MySQL帮忙的富有平台北事件监察和控制效用都可用,但分歧平桃园用来总计事件时间支付的定时器类型或许会怀有不同。

    performance_schema完结机制遵守以下设计指标:

    1. 启用performance_schema不会形成server的作为发生变化。举个例子,它不会转移线程调节机制,不会招致查询实践布置(如EXPLAIN)发生变化
    2. 启用performance_schema之后,server会持续不间断地监测,成本不大。不会招致server不可用
    3. 在该兑现机制中从未扩大新的尊敬字或讲话,深入分析器不会转换
    4. 即使performance_schema的监测机制在在那之中对某件事件施行监测战败,也不会影响server寻常运作
    5. 设若在起来搜集事件数量时遇上有任何线程正在针对这一个事件新闻举行查询,那么查询会优先实行事件数量的搜聚,因为事件数量的征采是四个不停不断的历程,而搜索(查询)那一个事件数量仅仅只是在须求查阅的时候才举办搜索。也说不定有个别事件数量长久都不会去寻找
    6. 必要很轻便地加多新的instruments监测点
    7. instruments(事件采访项)代码版本化:倘诺instruments的代码产生了改造,旧的instruments代码还足以一连专门的学业。
    8. 注意:MySQL sys schema是一组对象(蕴涵有关的视图、存款和储蓄进度和函数),能够平价地拜谒performance_schema收罗的数据。同期搜寻的数据可读性也越来越高(举例:performance_schema中的时间单位是微秒,经过sys schema查询时会转变为可读的us,ms,s,min,hour,day等单位),sys schem在5.7.x版本暗中认可安装

    |2、performance_schema使用高效入门

    当今,是还是不是感到上边的牵线内容太过雅淡呢?假令你这么想,那就对了,小编当场读书的时候也是这么想的。但后天,对于什么是performance_schema那些题目上,比起更早从前更显著了啊?假如您还尚未筹算要丢弃读书本文的话,那么,请随行大家伊始步向到"边走边唱"环节呢!

    2.1反省当前数据库版本是还是不是扶植

    performance_schema被视为存储引擎。举个例子该引擎可用,则应该在INFORMATION_SCHEMA.ENGINES表或SHOW ENGINES语句的出口中都能够观看它的SUPPORT值为YES,如下:

    使用 INFORMATION_SCHEMA.ENGINES表来查询你的数据库实例是还是不是协助INFORMATION_SCHEMA引擎

    qogir_env@localhost : performance_schema 02:41:41> SELECT * FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE ='PERFORMANCE_SCHEMA';

    +--------------------+---------+--------------------+--------------+------+------------+

    | ENGINE |SUPPORT | COMMENT |TRANSACTIONS | XA |SAVEPOINTS |

    +--------------------+---------+--------------------+--------------+------+------------+

    |PERFORMANCE_SCHEMA | YES |Performance Schema | NO |NO | NO |

    +--------------------+---------+--------------------+--------------+------+------------+

    1row inset (0.00sec)

    选拔show命令来询问你的数据库实例是不是帮助INFORMATION_SCHEMA引擎

    qogir_env@localhost : performance_schema 02:41:54> show engines;

    +--------------------+---------+----------------------------------------------------------------+--------------+------+------------+

    | Engine |Support | Comment

    |Transactions | XA |Savepoints |

    +--------------------+---------+----------------------------------------------------------------+--------------+------+------------+

    ......

    |PERFORMANCE_SCHEMA | YES |Performance Schema

    | NO |NO | NO |

    ......

    9rows inset (0.00sec)

    当咱们看来PEPolestar 1FORMANCE_SCHEMA 对应的Support 字段输出为YES时就象征大家当下的数据库版本是永葆performance_schema的。但敞亮咱们的实例帮衬performance_schema引擎就足以选拔了吗?NO,非常不满,performance_schema在5.6及其以前的版本中,暗中同意未有启用,从5.7及其之后的本子才修改为暗许启用。今后,大家来探视如何设置performance_schema默许启用吧!

    2.2. 启用performance_schema

    从上文中大家早已知道,performance_schema在5.7.x会同以上版本中暗中同意启用(5.6.x及其以下版本私下认可关闭),假若要显式启用或关闭时,大家须要利用参数performance_schema=ON|OFF设置,并在my.cnf中张开布置:

    [mysqld]

    performance_schema= ON# 注意:该参数为只读参数,需求在实例运转此前安装才生效

    mysqld运营之后,通过如下语句查看performance_schema是还是不是启用生效(值为ON表示performance_schema已早先化成功且能够行使了。假使值为OFF表示在启用performance_schema时发出一些错误。能够查看错误日志举办每一个核查):

    qogir_env@localhost : performance_schema 03:13:10> SHOW VARIABLES LIKE 'performance_schema';

    +--------------------+-------+

    | Variable_name |Value |

    +--------------------+-------+

    |performance_schema | ON |

    +--------------------+-------+

    1row inset (0.00sec)

    当今,你能够在performance_schema下行使show tables语句也许通过查询 INFORMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来打探在performance_schema下存在着什么表:

    通过从INFORMATION_SCHEMA.tables表查询有何样performance_schema引擎的表:

    qogir_env@localhost : performance_schema 03:13:22> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES

    WHERE TABLE_SCHEMA ='performance_schema'andengine='performance_schema';

    +------------------------------------------------------+

    | TABLE_NAME |

    +------------------------------------------------------+

    | accounts |

    | cond_instances |

    ......

    | users |

    | variables_by_thread |

    +------------------------------------------------------+

    87rows inset (0.00sec)

    直接在performance_schema库下利用show tables语句来查阅有何样performance_schema引擎表:

    qogir_env@localhost : performance_schema 03:20:43> use performance_schema

    Database changed

    qogir_env@localhost : performance_schema 03:21:06> show tables from performance_schema;

    +------------------------------------------------------+

    | Tables_in_performance_schema |

    +------------------------------------------------------+

    | accounts |

    | cond_instances |

    ......

    | users |

    | variables_by_thread |

    +------------------------------------------------------+

    87rows inset (0.00sec)

    近些日子,我们掌握了在 MySQL 5.7.17 版本中,performance_schema 下一齐有87张表,那么,那87帐表都以存放什么数据的吧?大家什么样行使他们来询问大家想要查看的多寡吧?先别焦急,大家先来会见那一个表是怎么分类的。

    2.3. performance_schema表的归类

    performance_schema库下的表能够根据监视分化的纬度进行了分组,举个例子:或根据分化数据库对象开展分组,或依据不一样的事件类型举行分组,或在依据事件类型分组之后,再进一步依照帐号、主机、程序、线程、客户等,如下:

    依据事件类型分组记录质量事件数量的表

    话语事件记录表,这个表记录了言语事件音讯,当前讲话事件表events_statements_current、历史语句事件表events_statements_history和长语句历史事件表events_statements_history_long、以致汇聚后的摘要表summary,当中,summary表还足以依据帐号(account),主机(host),程序(program),线程(thread),客商(user)和大局(global)再开展分割)

    qogir_env@localhost : performance_schema 03:51:36> show tables like 'events_statement%';

    +----------------------------------------------------+

    | Tables_in_performance_schema (%statement%) |

    +----------------------------------------------------+

    | events_statements_current |

    | events_statements_history |

    | events_statements_history_long |

    | events_statements_summary_by_account_by_event_name |

    | events_statements_summary_by_digest |

    | events_statements_summary_by_host_by_event_name |

    | events_statements_summary_by_program |

    | events_statements_summary_by_thread_by_event_name |

    | events_statements_summary_by_user_by_event_name |

    | events_statements_summary_global_by_event_name |

    +----------------------------------------------------+

    11rows inset (0.00sec)

    等候事件记录表,与话语事件类型的相干记录表类似:

    qogir_env@localhost : performance_schema 03:53:51> show tables like 'events_wait%';

    +-----------------------------------------------+

    | Tables_in_performance_schema (%wait%) |

    +-----------------------------------------------+

    | events_waits_current |

    | events_waits_history |

    | events_waits_history_long |

    | events_waits_summary_by_account_by_event_name |

    | events_waits_summary_by_host_by_event_name |

    | events_waits_summary_by_instance |

    | events_waits_summary_by_thread_by_event_name |

    | events_waits_summary_by_user_by_event_name |

    | events_waits_summary_global_by_event_name |

    +-----------------------------------------------+

    12rows inset (0.01sec)

    等第事件记录表,记录语句施行的级差事件的表,与话语事件类型的相关记录表类似:

    qogir_env@localhost : performance_schema 03:55:07> show tables like 'events_stage%';

    +------------------------------------------------+

    | Tables_in_performance_schema (%stage%) |

    +------------------------------------------------+

    | events_stages_current |

    | events_stages_history |

    | events_stages_history_long |

    | events_stages_summary_by_account_by_event_name |

    | events_stages_summary_by_host_by_event_name |

    | events_stages_summary_by_thread_by_event_name |

    | events_stages_summary_by_user_by_event_name |

    | events_stages_summary_global_by_event_name |

    +------------------------------------------------+

    8rows inset (0.00sec)

    业务事件记录表,记录事务相关的事件的表,与话语事件类型的连锁记录表类似:

    qogir_env@localhost : performance_schema 03:55:30> show tables like 'events_transaction%';

    +------------------------------------------------------+

    | Tables_in_performance_schema (%transaction%) |

    +------------------------------------------------------+

    | events_transactions_current |

    | events_transactions_history |

    | events_transactions_history_long |

    | events_transactions_summary_by_account_by_event_name |

    | events_transactions_summary_by_host_by_event_name |

    | events_transactions_summary_by_thread_by_event_name |

    | events_transactions_summary_by_user_by_event_name |

    | events_transactions_summary_global_by_event_name |

    +------------------------------------------------------+

    8rows inset (0.00sec)

    蹲点文件系统层调用的表:

    qogir_env@localhost : performance_schema 03:58:27> show tables like '%file%';

    +---------------------------------------+

    | Tables_in_performance_schema (%file%) |

    +---------------------------------------+

    | file_instances |

    | file_summary_by_event_name |

    | file_summary_by_instance |

    +---------------------------------------+

    3rows inset (0.01sec)

    监视内部存款和储蓄器使用的表:

    qogir_env@localhost : performance_schema 03:58:38> show tables like '%memory%';

    +-----------------------------------------+

    | Tables_in_performance_schema (%memory%) |

    +-----------------------------------------+

    | memory_summary_by_account_by_event_name |

    | memory_summary_by_host_by_event_name |

    | memory_summary_by_thread_by_event_name |

    | memory_summary_by_user_by_event_name |

    | memory_summary_global_by_event_name |

    +-----------------------------------------+

    5rows inset (0.01sec)

    动态对performance_schema实行配备的配置表:

    root@localhost : performance_schema 12:18:46> show tables like '%setup%';

    +----------------------------------------+

    | Tables_in_performance_schema (%setup%) |

    +----------------------------------------+

    | setup_actors |

    | setup_consumers |

    | setup_instruments |

    | setup_objects |

    | setup_timers |

    +----------------------------------------+

    5rows inset (0.00sec)

    今后,大家早就大概知道了performance_schema中的首要表的分类,但,怎样行使他们来为大家提供应和须要要的质量事件数量吧?上边,我们介绍如何通过performance_schema下的配备表来配置与运用performance_schema。

    2.4. performance_schema简单布署与使用

    数据库刚刚领头化并运转时,并不是全体instruments(事件采访项,在访谈项的配置表中各类都有三个按钮字段,或为YES,或为NO)和consumers(与征集项类似,也许有三个应和的事件类型保存表配置项,为YES就代表对应的表保存质量数据,为NO就意味着对应的表不保留质量数据)都启用了,所以暗中同意不会搜聚所有事件,恐怕您需求检查实验的风浪并不曾张开,供给开展安装,能够选取如下多少个语句张开对应的instruments和consumers(行计数只怕会因MySQL版本而异),举个例子,大家以布置监测等待事件数量为例实行求证:

    开拓等待事件的收罗器配置项按钮,须求修改setup_instruments 配置表中对应的搜聚器配置项

    qogir_env@localhost: performance_schema 03:34:40> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'where name like 'wait%';;

    QueryOK, 0 rowsaffected(0.00sec)

    Rowsmatched: 323 Changed: 0 Warnings: 0

    开采等待事件的保存表配置按键,修改修改setup_consumers 配置表中对应的配置i向

    qogir_env@localhost: performance_schema 04:23:40> UPDATE setup_consumers SET ENABLED = 'YES'where name like '%wait%';

    QueryOK, 3 rowsaffected(0.04sec)

    Rowsmatched: 3 Changed: 3 Warnings: 0

    安插好以后,大家就能够查阅server当前正在做什么样,能够由此查询events_waits_current表来获悉,该表中每一种线程只含有一行数据,用于体现每种线程的新型监视事件(正在做的业务):

    qogir_env@localhost : performance_schema 04:23:52> SELECT * FROM events_waits_current limit 1G

    ***************************

    1. row ***************************

    THREAD_ID: 4

    EVENT_ID: 60

    END_EVENT_ID: 60

    EVENT_NAME: wait/synch/mutex/innodb/log_sys_mutex

    SOURCE: log0log.cc:1572

    TIMER_START: 1582395491787124480

    TIMER_END: 1582395491787190144

    TIMER_WAIT: 65664

    SPINS: NULL

    OBJECT_SCHEMA: NULL

    OBJECT_NAME: NULL

    INDEX_NAME: NULL

    OBJECT_TYPE: NULL

    OBJECT_INSTANCE_BEGIN: 955681576

    NESTING_EVENT_ID: NULL

    NESTING_EVENT_TYPE: NULL

    OPERATION: lock

    NUMBER_OF_BYTES: NULL

    FLAGS: NULL

    1 row in set (0.02 sec)

    # 该事件信息表示线程ID为4的线程正在等候innodb存款和储蓄引擎的log_sys_mutex锁,那是innodb存款和储蓄引擎的一个互斥锁,等待时间为65664阿秒(*_ID列表示事件起点哪个线程、事件编号是不怎么;EVENT_NAME表示检验到的有血有肉的源委;SOURCE表示这些检查测量试验代码在哪些源文件中以至行号;计时器字段TIMEENCORE_START、TIMER_END、TIMER_WAIT分别代表该事件的发端时间、甘休时间、乃至总的开销时间,假诺该事件正在运维而并未有截至,那么TIME途达_END和TIMER_WAIT的值显示为NULL。注:沙漏计算的值是近乎值,实际不是全然可信赖)

    _current表中种种线程只保留一条记下,且若是线程完毕专门的学业,该表中不会再记录该线程的风云音信,_history表中记录每种线程已经实行到位的事件消息,但各个线程的只事件音信只记录10条,再多就能够被隐讳掉,*_history_long表中记录全部线程的平地风波音讯,但总记录数据是10000行,抢先会被覆盖掉,今后大家查看一下历史表events_waits_history 中著录了何等:

    qogir_env@localhost : performance_schema 06:14:08> SELECT THREAD_ID,EVENT_ID,EVENT_NAME,TIMER_WAIT FROM events_waits_history ORDER BY THREAD_ID limit 21;

    +-----------+----------+------------------------------------------+------------+

    | THREAD_ID |EVENT_ID | EVENT_NAME |TIMER_WAIT |

    +-----------+----------+------------------------------------------+------------+

    |4| 341 |wait/synch/mutex/innodb/fil_system_mutex | 84816 |

    | 4 |342| wait/synch/mutex/innodb/fil_system_mutex |32832|

    |4| 343 |wait/io/file/innodb/innodb_log_file | 544126864 |

    ......

    | 4 |348| wait/io/file/innodb/innodb_log_file |693076224|

    |4| 349 |wait/synch/mutex/innodb/fil_system_mutex | 65664 |

    | 4 |350| wait/synch/mutex/innodb/log_sys_mutex |25536|

    |13| 2260 |wait/synch/mutex/innodb/buf_pool_mutex | 111264 |

    | 13 |2259| wait/synch/mutex/innodb/fil_system_mutex |8708688|

    ......

    |13| 2261 |wait/synch/mutex/innodb/flush_list_mutex | 122208 |

    | 15 |291| wait/synch/mutex/innodb/buf_dblwr_mutex |37392|

    +-----------+----------+------------------------------------------+------------+

    21 rows inset (0.00 sec)

    summary表提供所有的事件的聚焦新闻。该组中的表以分歧的主意聚焦事件数量(如:按客商,按主机,按线程等等)。举例:要查看哪些instruments占用最多的年华,能够透过对events_waits_summary_global_by_event_name表的COUNT_STAR或SUM_TIMER_WAIT列进行询问(这两列是对事件的记录数实施COUNT(*)、事件记录的TIME库罗德_WAIT列执行SUM(TIMER_WAIT)总计而来),如下:

    qogir_env@localhost : performance_schema 06:17:23> SELECT EVENT_NAME,COUNT_STAR FROM events_waits_summary_global_by_event_name

    ORDER BY COUNT_STAR DESC LIMIT 10;

    | EVENT_NAME |COUNT_STAR |

    +---------------------------------------------------+------------+

    |wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 |

    | wait/io/file/sql/FRM |452|

    |wait/synch/mutex/sql/LOCK_plugin | 337 |

    | wait/synch/mutex/mysys/THR_LOCK_open |187|

    |wait/synch/mutex/mysys/LOCK_alarm | 147 |

    | wait/synch/mutex/sql/THD::LOCK_thd_data |115|

    |wait/io/file/myisam/kfile | 102 |

    | wait/synch/mutex/sql/LOCK_global_system_variables |89|

    |wait/synch/mutex/mysys/THR_LOCK::mutex | 89 |

    | wait/synch/mutex/sql/LOCK_open |88|

    +---------------------------------------------------+------------+

    qogir_env@localhost : performance_schema 06:19:20> SELECT EVENT_NAME,SUM_TIMER_WAIT FROM events_waits_summary_global_by_event_name

    ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

    +----------------------------------------+----------------+

    |EVENT_NAME | SUM_TIMER_WAIT |

    +----------------------------------------+----------------+

    | wait/io/file/sql/MYSQL_LOG |1599816582|

    |wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 |

    | wait/io/file/sql/binlog_index |1385291934|

    |wait/io/file/sql/FRM | 1292823243 |

    | wait/io/file/myisam/kfile |411193611|

    |wait/io/file/myisam/dfile | 322401645 |

    | wait/synch/mutex/mysys/LOCK_alarm |145126935|

    |wait/io/file/sql/casetest | 104324715 |

    | wait/synch/mutex/sql/LOCK_plugin |86027823|

    |wait/io/file/sql/pid | 72591750 |

    +----------------------------------------+----------------+

    # 那一个结果评释,TH途观_LOCK_malloc互斥事件是最热的。注:TH中华V_LOCK_malloc互斥事件仅在DEBUG版本中留存,GA版本不设有

    instance表记录了何等项指标靶子会被检查实验。那些目标在被server使用时,在该表中校会发生一条事件记录,举例,file_instances表列出了文本I/O操作及其关系文件名:

    qogir_env@localhost : performance_schema 06:27:26> SELECT * FROM file_instances limit 20;

    +------------------------------------------------------+--------------------------------------+------------+

    | FILE_NAME |EVENT_NAME | OPEN_COUNT |

    +------------------------------------------------------+--------------------------------------+------------+

    | /home/mysql/program/share/english/errmsg.sys |wait/io/file/sql/ERRMSG

    | 0 |

    | /home/mysql/program/share/charsets/Index.xml |wait/io/file/mysys/charset

    | 0 |

    | /data/mysqldata1/innodb_ts/ibdata1 |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/innodb_log/ib_logfile0 |wait/io/file/innodb/innodb_log_file | 2 |

    | /data/mysqldata1/innodb_log/ib_logfile1 |wait/io/file/innodb/innodb_log_file | 2 |

    | /data/mysqldata1/undo/undo001 |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/undo/undo002 |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/undo/undo003 |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/undo/undo004 |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/multi_master/test.ibd |wait/io/file/innodb/innodb_data_file | 1 |

    | /data/mysqldata1/mydata/mysql/engine_cost.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/gtid_executed.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/help_category.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/help_keyword.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/help_relation.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/help_topic.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/innodb_index_stats.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/innodb_table_stats.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/plugin.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    | /data/mysqldata1/mydata/mysql/server_cost.ibd |wait/io/file/innodb/innodb_data_file | 3 |

    +------------------------------------------------------+--------------------------------------+------------+

    20rows inset (0.00sec)

    正文小结

    本篇内容到这里就象是尾声了,相信广大人都认为,大家超越八分之四时候并不会直接利用performance_schema来查询品质数据,而是选择sys schema下的视图取代,为何不直接攻读sys schema呢?那你明白sys schema中的数据是从哪儿吐出来的呢?performance_schema 中的数据实际上首假如从performance_schema、information_schema中取得,所以要想玩转sys schema,全面摸底performance_schema不可缺少。另外,对于sys schema、informatiion_schema以致是mysql schema,我们承袭也会生产区别的数不胜数文章分享给大家。

    “翻过那座山,你就能够看来一片海”

    下卷将为大家分享"performance_schema之二(配置表详解)" ,多谢您的阅读,大家不见不散!回到和讯,查看更加多

    主编:

    本文由彩神快三发布于公司简介,转载请注明出处:初相识|performance_schema全方位介绍(一)

    关键词: