澳门皇冠真人-官网娱乐平台

澳门皇冠真人在线观看;澳门皇冠真人网站音乐;澳门皇冠a免费;澳门皇冠真人网站app;澳门皇冠真人55817;澳门皇冠真人视频;澳门皇冠真人tv;澳门皇冠真人网站黄;澳门皇冠a级手机版;澳门皇冠手机在线视频;澳门皇冠手机免费网址;澳门皇冠紧急网址更换;澳门皇冠四虎免费大片;澳门皇冠视频网站地址;免费网站;澳门澳门皇冠视频网站;澳门皇冠啪啪唯一平台;澳门皇冠金沙网站;亚洲澳门皇冠;澳门新葡8455最新网站;澳门皇冠金沙官网娱乐;澳门皇冠真人网址;澳门皇冠;澳门皇冠免费93399; 澳门皇冠真人a;澳门皇冠a真人;澳门皇冠真人官网;澳门皇冠真人tv;澳门皇冠a真人v; 澳门皇冠

您的位置:澳门皇冠真人 > 技术 > 澳门皇冠真人官网初相识|performance_schema全方位

澳门皇冠真人官网初相识|performance_schema全方位

发布时间:2019-10-25 10:37编辑:技术浏览(125)

    原标题:初相识|performance_schema全方位介绍(大器晚成)

    澳门皇冠真人官网 1

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

    出品:沃趣科技(science and technology)

    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)

    当大家见到PEENCOREFORMANCE_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表示那一个检查测量检验代码在哪个源文件中以至行号;放大计时器字段TIMELAND_START、TIMER_END、TIMER_WAIT分别表示该事件的起始时间、停止时间、以至总的费用时间,借使该事件正在运作而从未终结,那么TIMEEnclave_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 |

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

    # 这个结果注脚,THEnclave_LOCK_malloc互斥事件是最热的。注:THSportage_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全方位

    关键词: