您的位置:四不像必中一肖动物图 > 四不像必中一肖正牌 > performance_schema全方位介绍

performance_schema全方位介绍

发布时间:2019-10-10 19:43编辑:四不像必中一肖正牌浏览(129)

    原标题:初相识|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)

    当大家见到PE奔驰M级FORMANCE_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表示这些检查测验代码在哪些源文件中以致行号;放大计时器字段TIME奥迪Q5_START、TIMER_END、TIMER_WAIT分别代表该事件的最早时间、截止时间、以致总的开支时间,借使该事件正在运营而从未完毕,那么TIME兰德奥迪Q3_END和TIMER_WAIT的值呈现为NULL。注:沙漏总计的值是类似值,实际不是截然可信赖)

    _current表中每一种线程只保留一条记下,且一旦线程实现专门的学业,该表中不会再记录该线程的轩然大波音讯,_history表中著录种种线程已经实行到位的风云消息,但每一种线程的只事件新闻只记录10条,再多就能够被遮掩掉,*_history_long表中记录全部线程的事件音信,但总记录数据是一千0行,超越会被覆盖掉,现在大家查看一下历史表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(*)、事件记录的TIMEENCORE_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奥迪Q5_LOCK_malloc互斥事件是最热的。注:TH福特Explorer_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全方位介绍

    关键词:

上一篇:没有了

下一篇:廉价版新MacBook曝光