MySQL实践——sys schema介绍及使用

sys schema介绍
说到诊断MySQL的性能问题，都知道从performance_schema去获取想要的数据，但是其复杂程度让使用人员使用起来很不方便。在MySQL5.7中，performance_schema已经有80多张表，每张表都是各种统计信息的罗列。另外这些表和information_schema中的部分表也有关联，导致使用人员使用起来非常不便。
在MySQL5.7中新增了sys Schema。MySQL sys Schema是一个由一系列对象(视图、存储过程、存储方法、表和触发器)组成的database schema,它本身不采集和存储什么信息，而是将performance_schema和information_schema中的数据以更容易理解的方式总结出来归纳为“视图”。DBA和开发人员可以通过sys Schema方便、快速地读取Performance Schema收集的数据。接下来看一下sys Schema的视图中的数据是从哪里来的，如图12.1所示，举例说明如下。

通过视图定义可以看出，数据主要来源于information_schema中的COLUMNS和TABLES表。利用JOIN的方式连接查询，然后进行处理、过滤等，来展示实例中的自增量情况。sys Schema可用于典型的调优和诊断用例，这些对象包括如下三个。

• 将性能模式数据汇总到更易于理解的视图。
• 诸如性能模式配置和生成诊断报告等操作的存储过程。
• 用于查询性能模式配置并提供格式化服务的存储函数。

MySQL sys Schema默认包含在MySQL5.7中，并提供摘要视图以回答诸如下面所列的常见问题。

• 谁占了数据库服务的所有资源?
• 哪些主机对数据库服务器的访问量最大?
• 实例上的内存都去哪里了?

mysql> use sys;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show create table schema_auto_increment_columns\G
*************************** 1. row ***************************
                View: schema_auto_increment_columns
         Create View: CREATE ALGORITHM=MERGE DEFINER=`mysql.sys`@`localhost` SQL SECURITY INVOKER VIEW `schema_auto_increment_columns` AS select `information_schema`.`COLUMNS`.`TABLE_SCHEMA` AS `table_schema`,`information_schema`.`COLUMNS`.`TABLE_NAME` AS `table_name`,`information_schema`.`COLUMNS`.`COLUMN_NAME` AS `column_name`,`information_schema`.`COLUMNS`.`DATA_TYPE` AS `data_type`,`information_schema`.`COLUMNS`.`COLUMN_TYPE` AS `column_type`,(locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) = 0) AS `is_signed`,(locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0) AS `is_unsigned`,((case `information_schema`.`COLUMNS`.`DATA_TYPE` when 'tinyint' then 255 when 'smallint' then 65535 when 'mediumint' then 16777215 when 'int' then 4294967295 when 'bigint' then 18446744073709551615 end) >> if((locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0),0,1)) AS `max_value`,`information_schema`.`TABLES`.`AUTO_INCREMENT` AS `auto_increment`,(`information_schema`.`TABLES`.`AUTO_INCREMENT` / ((case `information_schema`.`COLUMNS`.`DATA_TYPE` when 'tinyint' then 255 when 'smallint' then 65535 when 'mediumint' then 16777215 when 'int' then 4294967295 when 'bigint' then 18446744073709551615 end) >> if((locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0),0,1))) AS `auto_increment_ratio` from (`INFORMATION_SCHEMA`.`COLUMNS` join `INFORMATION_SCHEMA`.`TABLES` on(((`information_schema`.`COLUMNS`.`TABLE_SCHEMA` = `information_schema`.`TABLES`.`TABLE_SCHEMA`) and (`information_schema`.`COLUMNS`.`TABLE_NAME` = `information_schema`.`TABLES`.`TABLE_NAME`)))) where ((`information_schema`.`COLUMNS`.`TABLE_SCHEMA` not in ('mysql','sys','INFORMATION_SCHEMA','performance_schema')) and (`information_schema`.`TABLES`.`TABLE_TYPE` = 'BASE TABLE') and (`information_schema`.`COLUMNS`.`EXTRA` = 'auto_increment')) order by (`information_schema`.`TABLES`.`AUTO_INCREMENT` / ((case `information_schema`.`COLUMNS`.`DATA_TYPE` when 'tinyint' then 255 when 'smallint' then 65535 when 'mediumint' then 16777215 when 'int' then 4294967295 when 'bigint' then 18446744073709551615 end) >> if((locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0),0,1))) desc,((case `information_schema`.`COLUMNS`.`DATA_TYPE` when 'tinyint' then 255 when 'smallint' then 65535 when 'mediumint' then 16777215 when 'int' then 4294967295 when 'bigint' then 18446744073709551615 end) >> if((locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0),0,1))
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)

sys Schema视图摘要

sys Schema中包含了很多以各种方式总结Performance Schema表的视图。这些视图大多数都是成对出现，使得每组视图中的一个成员具有与另一成员相同的名称，加上一个 x$ 前缀。例如，host_summary_by_file_io视图汇总按主机分组的文件I/O及延迟。没有 x$ 前缀的视图提供了更加友好且容易阅读的数据，x$ 前缀的视图提供了原始数据，更多用于需要对数据进行处理的其他工具。
视图按照展示信息可以分为如下几类。

• 主机相关信息：以host_summary开头的视图，主要汇总了IO延迟的信息，从主机、文件事件类型、语句类型等角度展示文件IO的信息。
• innodb相关信息：以innodb开头的视图，汇总了innodb buffer page信息和事务等待InnoDB锁信息。
• io使用情况：以io开头的视图，总结了io使用者的信息，包括等待I/O的情况、I/O使用量情况，从各个角度分组展示。
• 内存使用情况：以memory开头的视图，从主机、线程、用户、事件角度展示内存使用情况。
• 连接与会话信息：其中，processlist和session相关的视图，总结了会话相关信息。
• 表相关信息：以schema_table开头的视图，从全表扫描、InnoDB缓冲池等方面展示了表统计信息。
• 索引信息：其中包含index的视图，统计了索引使用情况，以及重复索引和未使用的索引情况。
• 语句相关信息：以statement开头的视图，统计的规范化后的语句使用情况，包括错误数、警告数、执行全表扫描的、使用临时表、执行排序等信息。
• 用户的相关信息：以user开头的视图，统计了用户使用的文件IO、执行的语句统计信息等。
• 等待事件相关信息：以wait开头的视图，从主机和事件角度展示等待类事件的延迟情况。

查看表的访问量

在一般的运维中，DBA维护了大量的数据库。每个业务上线某些SQL也许不会通知DBA,突然间某个实例的QPS上升，DBA如何查看问题并快速定位到底是哪个业务引起的QPS上升，或者说业务方上线一个业务，需要评估涉及的表访问量的增长情况，这时该怎么办? 在sys Schema中的schema_table_statistics视图，可以帮助我们定位到表的访问量情况。

mysql>  SELECT table_schema, table_name, sum(io_read_requests+io_write_requests) FROM `schema_table_statistics`;
+--------------+------------------------+-----------------------------------------+
| table_schema | table_name             | sum(io_read_requests+io_write_requests) |
+--------------+------------------------+-----------------------------------------+
| info_collect | google_detail_tbsget_0 |                                  110572 |
+--------------+------------------------+-----------------------------------------+
1 row in set (0.13 sec)

我们可以监控每张表访问量的变化情况，或者监控某个库的访问量变化等。如果某个库、某个表发生变化，DBA能够及时知道每个表的访问情况。

冗余索引与未使用的索引检查

线上使用数据库实例越来越多，每个表中都会创建索引，导致每个实例的索引非常多。一般都会有索引使用率很低或者是冗余索引的情况，这些索引是完全没有必要建立的。它们不仅消耗磁盘空间，而且还影响数据库的性能，DBA需要实时关注是否有该类索引的出现，出现时需要立即处理。那么时，sys Schema中的schema_redundant_indexes和schema_unused_indexes可以帮助我们快速查看索引情况。

tbs@localhost:[(none)]>select * from sys.schema_redundant_indexes \G
*************************** 1. row ***************************
              table_schema: dbt3
                table_name: a
      redundant_index_name: inx_a
   redundant_index_columns: a
redundant_index_non_unique: 1
       dominant_index_name: PRIMARY
    dominant_index_columns: a
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`a` DROP INDEX `inx_a`
*************************** 2. row ***************************
              table_schema: dbt3
                table_name: lineitem
      redundant_index_name: i_l_orderkey
   redundant_index_columns: l_orderkey
redundant_index_non_unique: 1
       dominant_index_name: i_l_orderkey_quantity
    dominant_index_columns: l_orderkey,l_quantity
 dominant_index_non_unique: 1
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`lineitem` DROP INDEX `i_l_orderkey`
*************************** 3. row ***************************
              table_schema: dbt3
                table_name: lineitem
      redundant_index_name: i_l_partkey
   redundant_index_columns: l_partkey
redundant_index_non_unique: 1
       dominant_index_name: i_l_suppkey_partkey
    dominant_index_columns: l_partkey,l_suppkey
 dominant_index_non_unique: 1
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`lineitem` DROP INDEX `i_l_partkey`
*************************** 4. row ***************************
              table_schema: dbt3
                table_name: lineitem
      redundant_index_name: i_l_orderkey
   redundant_index_columns: l_orderkey
redundant_index_non_unique: 1
       dominant_index_name: PRIMARY
    dominant_index_columns: l_orderkey,l_linenumber
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`lineitem` DROP INDEX `i_l_orderkey`
*************************** 5. row ***************************
              table_schema: dbt3
                table_name: orders
      redundant_index_name: idx_cust_date_status_80
   redundant_index_columns: o_custkey,o_orderDATE,o_orderstatus
redundant_index_non_unique: 1
       dominant_index_name: idx_a_b_c
    dominant_index_columns: o_custkey,o_orderDATE,o_orderstatus
 dominant_index_non_unique: 1
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`orders` DROP INDEX `idx_cust_date_status_80`
*************************** 6. row ***************************
              table_schema: dbt3
                table_name: orders
      redundant_index_name: i_o_custkey
   redundant_index_columns: o_custkey
redundant_index_non_unique: 1
       dominant_index_name: idx_a_b_c
    dominant_index_columns: o_custkey,o_orderDATE,o_orderstatus
 dominant_index_non_unique: 1
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`orders` DROP INDEX `i_o_custkey`
*************************** 7. row ***************************
              table_schema: dbt3
                table_name: orders
      redundant_index_name: i_o_custkey
   redundant_index_columns: o_custkey
redundant_index_non_unique: 1
       dominant_index_name: idx_cust_date_status_80
    dominant_index_columns: o_custkey,o_orderDATE,o_orderstatus
 dominant_index_non_unique: 1
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`orders` DROP INDEX `i_o_custkey`
*************************** 8. row ***************************
              table_schema: dbt3
                table_name: orders
      redundant_index_name: i_o_custkey
   redundant_index_columns: o_custkey
redundant_index_non_unique: 1
       dominant_index_name: inx_cust_date_status
    dominant_index_columns: o_custkey,o_orderdate2,o_orderstatus
 dominant_index_non_unique: 1
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`orders` DROP INDEX `i_o_custkey`
*************************** 9. row ***************************
              table_schema: dbt3
                table_name: partsupp
      redundant_index_name: i_ps_partkey
   redundant_index_columns: ps_partkey
redundant_index_non_unique: 1
       dominant_index_name: PRIMARY
    dominant_index_columns: ps_partkey,ps_suppkey
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`partsupp` DROP INDEX `i_ps_partkey`
*************************** 10. row ***************************
              table_schema: dbt3
                table_name: sougou
      redundant_index_name: cname
   redundant_index_columns: cname
redundant_index_non_unique: 1
       dominant_index_name: inx_dict_type
    dominant_index_columns: cname,dict_type
 dominant_index_non_unique: 1
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`sougou` DROP INDEX `cname`
*************************** 11. row ***************************
              table_schema: dbt3
                table_name: sougou
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dbt3`.`sougou` DROP INDEX `id`
*************************** 12. row ***************************
              table_schema: dpfm
                table_name: article_info
      redundant_index_name: periodical_id
   redundant_index_columns: article_id
redundant_index_non_unique: 1
       dominant_index_name: article_id
    dominant_index_columns: article_id
 dominant_index_non_unique: 1
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dpfm`.`article_info` DROP INDEX `periodical_id`
*************************** 13. row ***************************
              table_schema: dpfm
                table_name: operation_log
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dpfm`.`operation_log` DROP INDEX `id`
*************************** 14. row ***************************
              table_schema: dpfm
                table_name: operation_process
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dpfm`.`operation_process` DROP INDEX `id`
*************************** 15. row ***************************
              table_schema: dpfm
                table_name: operation_process_log
      redundant_index_name: task_id
   redundant_index_columns: task_id
redundant_index_non_unique: 1
       dominant_index_name: task_id_2
    dominant_index_columns: task_id,step_code
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dpfm`.`operation_process_log` DROP INDEX `task_id`
*************************** 16. row ***************************
              table_schema: dpfm
                table_name: operation_table
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dpfm`.`operation_table` DROP INDEX `id`
*************************** 17. row ***************************
              table_schema: dpfm
                table_name: operation_task
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dpfm`.`operation_task` DROP INDEX `id`
*************************** 18. row ***************************
              table_schema: dpfm
                table_name: operation_type
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dpfm`.`operation_type` DROP INDEX `id`
*************************** 19. row ***************************
              table_schema: dpfm
                table_name: task_chain_statistics
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `dpfm`.`task_chain_statistics` DROP INDEX `id`
*************************** 20. row ***************************
              table_schema: kmm
                table_name: attribute
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`attribute` DROP INDEX `id`
*************************** 21. row ***************************
              table_schema: kmm
                table_name: attribute_category
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`attribute_category` DROP INDEX `id`
*************************** 22. row ***************************
              table_schema: kmm
                table_name: attribute_tree
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`attribute_tree` DROP INDEX `id`
*************************** 23. row ***************************
              table_schema: kmm
                table_name: concept
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`concept` DROP INDEX `id`
*************************** 24. row ***************************
              table_schema: kmm
                table_name: concept_category
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`concept_category` DROP INDEX `id`
*************************** 25. row ***************************
              table_schema: kmm
                table_name: concept_tree
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`concept_tree` DROP INDEX `id`
*************************** 26. row ***************************
              table_schema: kmm
                table_name: neo4j_task
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`neo4j_task` DROP INDEX `id`
*************************** 27. row ***************************
              table_schema: kmm
                table_name: noumenon
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`noumenon` DROP INDEX `id`
*************************** 28. row ***************************
              table_schema: kmm
                table_name: noumenon_category
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `kmm`.`noumenon_category` DROP INDEX `id`
*************************** 29. row ***************************
              table_schema: tbsdrmt
                table_name: operation_log
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `tbsdrmt`.`operation_log` DROP INDEX `id`
*************************** 30. row ***************************
              table_schema: tbsrdps
                table_name: operation_log
      redundant_index_name: id
   redundant_index_columns: id
redundant_index_non_unique: 0
       dominant_index_name: PRIMARY
    dominant_index_columns: id
 dominant_index_non_unique: 0
            subpart_exists: 0
            sql_drop_index: ALTER TABLE `tbsrdps`.`operation_log` DROP INDEX `id`
30 rows in set, 2 warnings (0.82 sec)

tbs@localhost:[(none)]>select * from sys.schema_unused_indexes limit 0,1;
+---------------+-------------+------------+
| object_schema | object_name | index_name |
+---------------+-------------+------------+
| dbt3          | a           | inx_a      |
+---------------+-------------+------------+
1 row in set (0.10 sec)

针对冗余索引，DBA应该及时清理掉。针对长期未使用的索引，DBA应该与使用方沟通是否以后有使用该索引的SQL语句等情况，如果没有或暂时不使用的，可以删除掉该索引，减少磁盘压力，提高数据库性能。

表自增ID监控

随着DBA维护的数据库实例越来越多，表信息也越来越多，可能某张表自增量快要超过阈值了，继而导致业务出现问题。这时需要DBA清楚地知道每个表的增量列的情况。那么这时候如何查询呢?以前都是分别去查询每个表信息，或者通过INFROMATION SCHEMA来获取信息。从MySQL5.7以后可以用sys Schema中的schema_auto_increment_columns视图，就能很简单地查到每个表的自增量使用情况，甚至可以精确到某个表的自增量情况。

mysql> SELECT * FROM sys.schema_auto_increment_columns limit 0,2 \G
*************************** 1. row ***************************
        table_schema: gjts
          table_name: wenzhang_lingyu
         column_name: id
           data_type: tinyint
         column_type: tinyint(4)
           is_signed: 1
         is_unsigned: 0
           max_value: 127
      auto_increment: 29
auto_increment_ratio: 0.2283
*************************** 2. row ***************************
        table_schema: tbsdict
          table_name: language_type
         column_name: language_id
           data_type: tinyint
         column_type: tinyint(3)
           is_signed: 1
         is_unsigned: 0
           max_value: 127
      auto_increment: 29
auto_increment_ratio: 0.2283
2 rows in set, 10 warnings (3.75 sec)

在该视图中，详细地展示了表的自增量列名、数据类型、当前使用量、最大值及使用率情况。极大地方便了DBA快速了解数据库自增量的使用情况。甚至可以监控该使用率，如果超过某个阈值，可以通过告警的方式自动化的告知DBA某张表的自增量可能要出现问题了，达到预警的作用，DBA可以快速处理这些问题。

监控全表扫描的SQL语句

线上数据库每天跑的SQL语句会有很多，有部分SQL会由于未使用索引而导致全表扫描，这些SQL中的很大一部分会导致数据库性能急剧下降，甚至会导致数据库并发上升，从而使数据库响应变慢，直到夯住。这对DBA来说是非常可怕的事情。DBA需要尽早发现这些SQL,关注其是否可以优化。那么在sys Schema的statements_with_full_table_scans视图中，也许能够帮助我们定位哪些SQL语句走了全表扫描。

mysql> SELECT * FROM sys.statements_with_full_table_scans where db ='gjts' limit 0,2\G
*************************** 1. row ***************************
                   query: SELECT COUNT (?) AS `num` FROM ...  WHERE ( ( `title` LIKE ? ) ) 
                      db: gjts
              exec_count: 21
           total_latency: 9.31 ms
     no_index_used_count: 21
no_good_index_used_count: 0
       no_index_used_pct: 100
               rows_sent: 21
           rows_examined: 609
           rows_sent_avg: 1
       rows_examined_avg: 29
              first_seen: 2023-08-01 08:04:07
               last_seen: 2023-08-01 11:32:53
                  digest: 5b59d502d9fdfe1d226ae87886a9a451
*************************** 2. row ***************************
                   query: SELECT * FROM `gjts` . `academic_papers` LIMIT ?, ... 
                      db: gjts
              exec_count: 1
           total_latency: 8.97 ms
     no_index_used_count: 1
no_good_index_used_count: 0
       no_index_used_pct: 100
               rows_sent: 708
           rows_examined: 708
           rows_sent_avg: 708
       rows_examined_avg: 708
              first_seen: 2023-08-01 10:23:43
               last_seen: 2023-08-01 10:23:43
                  digest: c7c69d6e9fba968ff2b839adf4342c72
2 rows in set (0.01 sec)

查看实例消耗的磁盘l/0

数据库造成磁盘IO的消耗，对我们来说是需要关心的。业务方经常抱怨数据库慢了，这时DBA需要关心数据库到底慢在哪里?如果这时磁盘IO消耗过大，那么DBA需要知道在哪些数据库文件上消耗了大量的磁盘IO。如果DBA能够快速知道具体的文件消耗磁盘IO量，排查问题时就会简单很多。这时，sys Schema中的io_global_by_file_by_bytes视图也许可以帮助我们定位一下问题。

mysql> SELECT file, avg_read+avg_write as avg_io FROM io_global_by_file_by_bytes order by avg_io desc limit 10;
+-------------------------------------------------------+--------+
| file                                                  | avg_io |
+-------------------------------------------------------+--------+
| @@datadir/ebs_log/log20230801.frm                     |   1105 |
| @@datadir/sys/schema_tables_with_full_table_scans.frm |   1023 |
| @@datadir/jzqb/company_tudizhuanrang.frm              |   1019 |
| @@datadir/jzqb/company_xingzhengxukegongshangju.frm   |   1016 |
| @@datadir/kjdsj/baike.frm                             |   1015 |
| @@datadir/jzqb/company_gongsigongshi.frm              |   1015 |
| @@datadir/jzqb/company_gudongjichuzixinxi.frm         |   1015 |
| @@datadir/ctt/test_merge_data.frm                     |   1013 |
| @@datadir/gjts/books_yearbooks_1.frm                  |   1013 |
| @@datadir/jzqb/company_qianshuigonggao.frm            |   1013 |
+-------------------------------------------------------+--------+
10 rows in set (4.27 sec)

DBA可以通过该查询来大致地了解磁盘IO消耗在哪里，哪些文件消耗的最多。DBA可以根据该信息，针对某些表、某些库进行针对性的优化，提高数据库性能。