sys schema介紹
說(shuō)到診斷MySQL的性能問(wèn)題，都知道從performance_schema去獲取想要的數(shù)據(jù)，但是其復(fù)雜程度讓使用人員使用起來(lái)很不方便。在MySQL5.7中，performance_schema已經(jīng)有80多張表，每張表都是各種統(tǒng)計(jì)信息的羅列。另外這些表和information_schema中的部分表也有關(guān)聯(lián)，導(dǎo)致使用人員使用起來(lái)非常不便。
在MySQL5.7中新增了sys Schema。MySQL sys Schema是一個(gè)由一系列對(duì)象(視圖、存儲(chǔ)過(guò)程、存儲(chǔ)方法、表和觸發(fā)器)組成的database schema,它本身不采集和存儲(chǔ)什么信息，而是將performance_schema和information_schema中的數(shù)據(jù)以更容易理解的方式總結(jié)出來(lái)歸納為“視圖”。DBA和開發(fā)人員可以通過(guò)sys Schema方便、快速地讀取Performance Schema收集的數(shù)據(jù)。接下來(lái)看一下sys Schema的視圖中的數(shù)據(jù)是從哪里來(lái)的，如圖12.1所示，舉例說(shuō)明如下。
通過(guò)視圖定義可以看出，數(shù)據(jù)主要來(lái)源于information_schema中的COLUMNS和TABLES表。利用JOIN的方式連接查詢，然后進(jìn)行處理、過(guò)濾等，來(lái)展示實(shí)例中的自增量情況。sys Schema可用于典型的調(diào)優(yōu)和診斷用例，這些對(duì)象包括如下三個(gè)。
- 將性能模式數(shù)據(jù)匯總到更易于理解的視圖。
- 諸如性能模式配置和生成診斷報(bào)告等操作的存儲(chǔ)過(guò)程。
- 用于查詢性能模式配置并提供格式化服務(wù)的存儲(chǔ)函數(shù)。
MySQL sys Schema默認(rèn)包含在MySQL5.7中，并提供摘要視圖以回答諸如下面所列的常見問(wèn)題。
- 誰(shuí)占了數(shù)據(jù)庫(kù)服務(wù)的所有資源?
- 哪些主機(jī)對(duì)數(shù)據(jù)庫(kù)服務(wù)器的訪問(wèn)量最大?
- 實(shí)例上的內(nèi)存都去哪里了?
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中包含了很多以各種方式總結(jié)Performance Schema表的視圖。這些視圖大多數(shù)都是成對(duì)出現(xiàn)，使得每組視圖中的一個(gè)成員具有與另一成員相同的名稱，加上一個(gè) x$ 前綴。例如，host_summary_by_file_io視圖匯總按主機(jī)分組的文件I/O及延遲。沒(méi)有 x$ 前綴的視圖提供了更加友好且容易閱讀的數(shù)據(jù)，x$ 前綴的視圖提供了原始數(shù)據(jù)，更多用于需要對(duì)數(shù)據(jù)進(jìn)行處理的其他工具。
視圖按照展示信息可以分為如下幾類。
- 主機(jī)相關(guān)信息：以host_summary開頭的視圖，主要匯總了IO延遲的信息，從主機(jī)、文件事件類型、語(yǔ)句類型等角度展示文件IO的信息。
- innodb相關(guān)信息：以innodb開頭的視圖，匯總了innodb buffer page信息和事務(wù)等待InnoDB鎖信息。
- io使用情況：以io開頭的視圖，總結(jié)了io使用者的信息，包括等待I/O的情況、I/O使用量情況，從各個(gè)角度分組展示。
- 內(nèi)存使用情況：以memory開頭的視圖，從主機(jī)、線程、用戶、事件角度展示內(nèi)存使用情況。
- 連接與會(huì)話信息：其中，processlist和session相關(guān)的視圖，總結(jié)了會(huì)話相關(guān)信息。
- 表相關(guān)信息：以schema_table開頭的視圖，從全表掃描、InnoDB緩沖池等方面展示了表統(tǒng)計(jì)信息。
- 索引信息：其中包含index的視圖，統(tǒng)計(jì)了索引使用情況，以及重復(fù)索引和未使用的索引情況。
- 語(yǔ)句相關(guān)信息：以statement開頭的視圖，統(tǒng)計(jì)的規(guī)范化后的語(yǔ)句使用情況，包括錯(cuò)誤數(shù)、警告數(shù)、執(zhí)行全表掃描的、使用臨時(shí)表、執(zhí)行排序等信息。
- 用戶的相關(guān)信息：以u(píng)ser開頭的視圖，統(tǒng)計(jì)了用戶使用的文件IO、執(zhí)行的語(yǔ)句統(tǒng)計(jì)信息等。
- 等待事件相關(guān)信息：以wait開頭的視圖，從主機(jī)和事件角度展示等待類事件的延遲情況。
查看表的訪問(wèn)量
在一般的運(yùn)維中，DBA維護(hù)了大量的數(shù)據(jù)庫(kù)。每個(gè)業(yè)務(wù)上線某些SQL也許不會(huì)通知DBA,突然間某個(gè)實(shí)例的QPS上升，DBA如何查看問(wèn)題并快速定位到底是哪個(gè)業(yè)務(wù)引起的QPS上升，或者說(shuō)業(yè)務(wù)方上線一個(gè)業(yè)務(wù)，需要評(píng)估涉及的表訪問(wèn)量的增長(zhǎng)情況，這時(shí)該怎么辦? 在sys Schema中的schema_table_statistics視圖，可以幫助我們定位到表的訪問(wèn)量情況。
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)
我們可以監(jiān)控每張表訪問(wèn)量的變化情況，或者監(jiān)控某個(gè)庫(kù)的訪問(wèn)量變化等。如果某個(gè)庫(kù)、某個(gè)表發(fā)生變化，DBA能夠及時(shí)知道每個(gè)表的訪問(wèn)情況。
冗余索引與未使用的索引檢查
線上使用數(shù)據(jù)庫(kù)實(shí)例越來(lái)越多，每個(gè)表中都會(huì)創(chuàng)建索引，導(dǎo)致每個(gè)實(shí)例的索引非常多。一般都會(huì)有索引使用率很低或者是冗余索引的情況，這些索引是完全沒(méi)有必要建立的。它們不僅消耗磁盤空間，而且還影響數(shù)據(jù)庫(kù)的性能，DBA需要實(shí)時(shí)關(guān)注是否有該類索引的出現(xiàn)，出現(xiàn)時(shí)需要立即處理。那么時(shí)，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)
針對(duì)冗余索引，DBA應(yīng)該及時(shí)清理掉。針對(duì)長(zhǎng)期未使用的索引，DBA應(yīng)該與使用方溝通是否以后有使用該索引的SQL語(yǔ)句等情況，如果沒(méi)有或暫時(shí)不使用的，可以刪除掉該索引，減少磁盤壓力，提高數(shù)據(jù)庫(kù)性能。
表自增ID監(jiān)控
隨著DBA維護(hù)的數(shù)據(jù)庫(kù)實(shí)例越來(lái)越多，表信息也越來(lái)越多，可能某張表自增量快要超過(guò)閾值了，繼而導(dǎo)致業(yè)務(wù)出現(xiàn)問(wèn)題。這時(shí)需要DBA清楚地知道每個(gè)表的增量列的情況。那么這時(shí)候如何查詢呢?以前都是分別去查詢每個(gè)表信息，或者通過(guò)INFROMATION SCHEMA來(lái)獲取信息。從MySQL5.7以后可以用sys Schema中的schema_auto_increment_columns視圖，就能很簡(jiǎn)單地查到每個(gè)表的自增量使用情況，甚至可以精確到某個(gè)表的自增量情況。
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)
在該視圖中，詳細(xì)地展示了表的自增量列名、數(shù)據(jù)類型、當(dāng)前使用量、最大值及使用率情況。極大地方便了DBA快速了解數(shù)據(jù)庫(kù)自增量的使用情況。甚至可以監(jiān)控該使用率，如果超過(guò)某個(gè)閾值，可以通過(guò)告警的方式自動(dòng)化的告知DBA某張表的自增量可能要出現(xiàn)問(wèn)題了，達(dá)到預(yù)警的作用，DBA可以快速處理這些問(wèn)題。
監(jiān)控全表掃描的SQL語(yǔ)句
線上數(shù)據(jù)庫(kù)每天跑的SQL語(yǔ)句會(huì)有很多，有部分SQL會(huì)由于未使用索引而導(dǎo)致全表掃描，這些SQL中的很大一部分會(huì)導(dǎo)致數(shù)據(jù)庫(kù)性能急劇下降，甚至?xí)?dǎo)致數(shù)據(jù)庫(kù)并發(fā)上升，從而使數(shù)據(jù)庫(kù)響應(yīng)變慢，直到夯住。這對(duì)DBA來(lái)說(shuō)是非?？膳碌氖虑?。DBA需要盡早發(fā)現(xiàn)這些SQL,關(guān)注其是否可以優(yōu)化。那么在sys Schema的statements_with_full_table_scans視圖中，也許能夠幫助我們定位哪些SQL語(yǔ)句走了全表掃描。
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)
查看實(shí)例消耗的磁盤l/0
數(shù)據(jù)庫(kù)造成磁盤IO的消耗，對(duì)我們來(lái)說(shuō)是需要關(guān)心的。業(yè)務(wù)方經(jīng)常抱怨數(shù)據(jù)庫(kù)慢了，這時(shí)DBA需要關(guān)心數(shù)據(jù)庫(kù)到底慢在哪里?如果這時(shí)磁盤IO消耗過(guò)大，那么DBA需要知道在哪些數(shù)據(jù)庫(kù)文件上消耗了大量的磁盤IO。如果DBA能夠快速知道具體的文件消耗磁盤IO量，排查問(wèn)題時(shí)就會(huì)簡(jiǎn)單很多。這時(shí)，sys Schema中的io_global_by_file_by_bytes視圖也許可以幫助我們定位一下問(wèn)題。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-621238.html
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可以通過(guò)該查詢來(lái)大致地了解磁盤IO消耗在哪里，哪些文件消耗的最多。DBA可以根據(jù)該信息，針對(duì)某些表、某些庫(kù)進(jìn)行針對(duì)性的優(yōu)化，提高數(shù)據(jù)庫(kù)性能。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-621238.html
到了這里，關(guān)于MySQL實(shí)踐——sys schema介紹及使用的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
