目录
简介
performance_schema
作用
分类
简单配置与使用
查看最近执行失败的SQL语句
查看最近的事务执行信息
sys系统库
作用
使用
查看慢SQL语句慢在哪
information_schema
作用
分类
应用
查看索引列的信息
mysql系统库
权限系统表
统计信息表
日志记录表
general_log
slow_log
InnoDB的统计信息
分类
信息参考:MySQL官网
简介
MySQL有4个系统数据库,这4个数据库包含了MySQL服务器运行过程中所需的一些信息以及一些运行状态信息。
-
performance_schema:这个数据库里主要保存MySQL服务器运行过程中的一些状态信息,算是对MySQL服务器的一个性能监控。其中包括统计最近执行了哪些语句,在执行过程的每个阶段都花费了多长时间,内存的使用情况等等信息。
-
information_schema:这个数据库保存着MySQL服务器维护的所有其他数据库的信息,比如有哪些表、哪些视图、哪些触发器、哪些列、哪些索引。这些是一些描述性信息,称之为元数据。
-
sys:通过视图的形式把information_schema和performance_schema结合起来,让程序员可以更方便的了解MySQL服务器的一些性能信息。
-
mysql:主要存储了MySQL的用户账户和权限信息,还有一些存储过程、事件的定义信息,一些运行过程中产生的日志信息,一些帮助信息以及时区信息等。
performance_schema
MySQL的performance_schema 是运行在较低级别的用于监控MySQL Server运行过程中的资源消耗、资源等待等情况的一个功能特性。
运行时较低级别:采集的信息相比底层,比如磁盘文件、表IO、表锁等。
作用
-
提供数据库运行时实施检查Server内部执行情况的方法。
-
通过监听Server的事件来实现监听其内部执行情况。采集事件可以方便地提供Server中的相关存储引擎对磁盘文件、表I/O、表锁等资源的同步调用信息。
-
当前活跃事件、历史事件和事件摘要相关表中记录的信息,能提供某个事件的执行次数、使用时长,进而可用于分析与某个特定线程、特定对象(如mutex或file)相关联的活动。
-
performance_schema存储引擎使用Server源代码中的“检测点”来实现事件数据的收集。对于performance_schema实现机制本身的代码没有相关的单独线程来检测,这与其他功能(如复制或事件计划程序)不同。
-
表中数据不会持久化存储在磁盘中,而是保存在内存中,一旦服务器重启,这些数据就会丢失
分类
在MySQL 5.7及之后的版本中才修改为默认启用。
performance_schema库下的表可以按照监视的不同维度进行分组,例如:按照不同的数据库对象进行分组、按照不同的事件类型进行分组,或者按照事件类型分组之后,再进一步按照账号、主机、程序、线程、用户等进行细分。
-
语句事件记录表【events_statement】 包括:events_statements_current(当前语句事件表)、events_statements_history(历史语句事件表)、events_statements_history_long(长语句历史事件表)以及一些summary表(聚合后的摘要表)。其中,summary表还可以根据账号(account)、主机(host)、程序(program)、线程(thread)、用户(user)和全局(global)再进行细分。
-
等待事件记录表【events_wait】
-
阶段事件记录表【events_stage】
-
事务事件记录表【events_transaction】
-
监视文件系统层调用的表【file】
-
监控内存【memory】
-
动态对performance_schema进行配置的配置表【setup】
使用 show tables like '%memory%' 类似的语句查询哈~
简单配置与使用
当数据库初始化完成并启动时,并非所有的instruments和consumers都启用了,所以默认不会收集所有的事件。
可能你想检测的事件并没有打开,需要进行设置。可以使用如下两条语句打开对应的instruments和consumers,我们以配置监测等待事件数据为例进行说明。
-- 打开等待事件的采集器配置项开关,需要修改setup_instruments 配置表中对应的采集器配置项。
update setup_instruments set enabled='yes',timed='yes' where name like 'wait%';
-- 打开等待事件的保存表配置项开关,修改setup_consumers 配置表中对应的配置项。
update setup_consumers set enabled='yes' where name like 'wait%';
配置好之后,就可以查看Server当前正在做什么了。
可以通过查询events_waits_current表来得知,该表中每个线程只包含一行数据,用于显示每个线程的最新监视事件(正在做的事情)。
_current表中每个线程只保留一条记录,且一旦线程完成工作,该表中就不会再记录该线程的事件信息了。history表中记录每个线程已经执行完成的事件信息,但每个线程的事件信息只记录10条,再多就会被覆盖掉。*history_long表中记录所有线程的事件信息,但总记录数量是10000行,超过会被覆盖掉。
summary表提供所有事件的汇总信息。该组中的表以不同的方式汇总事件数据(如:按用户、按主机、按线程等汇总)。
查看最近执行失败的SQL语句
使用代码对数据库的某些操作(比如:使用Java的ORM框架操作数据库)报出语法错误,但是代码并没有记录SQL语句文本的功能,在MySQL数据库层能否查看到具体的SQL语句文本,看看是否哪里写错了?这个时候,大多数人首先想到的就是去查看错误日志。很遗憾,对于SQL语句的语法错误,错误日志并不会记录。
实际上,在performance_schema的语句事件记录表中针对每一条语句的执行状态都记录了较为详细的信息
例如:events_statements表和events_statements_summary_by_digest表(events_statements表记录了语句所有的执行错误信息,而events_statements_summary_by_digest表只记录了语句在执行过程中发生错误的语句记录统计信息,不记录具体的错误类型,例如:不记录语法错误类的信息)下面看看如何使用这两个表查询语句发生错误的语句信息。
-- 查询event_statements_history 错误号为1064的记录
select * from events_statements_history where mysql_errno=1064\G-- 如果不知道错误号是多少,可以查询发生错误次数不为0的语句记录,
-- 在里边找到SQL_TEXT和MESSAGE_TEXT字段(提示信息为语法错误的就是它)。
查看最近的事务执行信息
我们可以通过慢查询日志查询到一条语句的执行总时长,但是如果数据库中存在着一些大事务在执行过程中回滚了,或者在执行过程中异常中止,这个时候慢查询日志就爱莫能助了;这时我们可以借助performance_schema的events_transactions_*表来查看与事务相关的记录,在这些表中详细记录了是否有事务被回滚、活跃(长时间未提交的事务也属于活跃事务)或已提交等信息。
-- 首先需要进行配置启用,事务事件默认并未启用
update setup_instruments set enabled='yes',timed='yes' where name like 'transaction%';
update setup_consumers set enabled='yes' where name like '%transaction%';
当然performance_schema的用途不止上面这些,它还能提供比如查看SQL语句执行阶段和进度信息、MySQL集群下复制功能查看复制报错详情等等。
sys系统库
sys系统库支持MySQL 5.6或更高版本,不支持MySQL 5.5.x及以下版本。
sys系统库通常都是提供给专业的DBA人员排查一些特定问题使用的,其下所涉及的各项查询或多或少都会对性能有一定的影响。因为sys系统库提供了一些代替直接访问performance_schema的视图,所以必须启用performance_schema(将performance_schema系统参数设置为ON),sys系统库的大部分功能才能正常使用。同时要完全访问sys系统库,用户必须具有以下数据库的管理员权限。
-- 启用所有的wait instruments:
CALL sys.ps_setup_enable_instrument('wait');
-- 启用所有事件类型的current表:
CALL sys.ps_setup_enable_consumer('current');
作用
在sys系统库下包含很多视图,它们以各种方式对performance_schema表进行聚合计算展示。
这些视图大部分是成对出现的,两个视图名称相同,但有一个视图是带 x host_summary_by_file_io和 x$host_summary_by_file_io 带x前缀的视图显示的是原始的数据(单位是皮秒)
使用
查看慢SQL语句慢在哪
如果我们频繁地在慢查询日志中发现某个语句执行缓慢,且在表结构、索引结构、统计信息中都无法找出原因时,则可以利用sys系统库中的撒手锏:sys.session视图结合performance_schema的等待事件来找出症结所在。
那么session视图有什么用呢?使用它可以查看当前用户会话的进程列表信息,看看当前进程到底再干什么
这个视图在MySQL 5.7.9中才出现。
select * from session where command='query' and conn_id !=connection_id()\G
查询表的增、删、改、查数据量和I/O耗时统计
select * from schema_table_statistics_with_buffer\G
除此之外,通过sys还可以查询查看InnoDB缓冲池中的热点数据、查看是否有事务锁等待、查看未使用的,冗余索引、查看哪些语句使用了全表扫描等等。
information_schema
作用
information_schema提供了对数据库元数据、统计信息以及有关MySQL Server信息的访问
(例如:数据库名或表名、字段的数据类型和访问权限等)。该库中保存的信息也可以称为MySQL的数据字典或系统目录。
在每个MySQL 实例中都有一个独立的information_schema,用来存储MySQL实例中所有其他数据库的基本信息。information_schema库下包含多个只读表(非持久表),所以在磁盘中的数据目录下没有对应的关联文件,且不能对这些表设置触发器。虽然在查询时可以使用USE语句将默认数据库设置为information_schema,但该库下的所有表是只读的,不能执行INSERT、UPDATE、DELETE等数据变更操作。
针对information_schema下的表的查询操作可以替代一些SHOW查询语句(例如:SHOW DATABASES、SHOW TABLES等)。
PS:根据MySQL版本的不同,表的个数和存放是有所不同的。
在MySQL 8.0版本中,该schema下的数据字典表(包含部分原Memory引擎临时表)都迁移到了mysql schema下,且在mysql schema下这些数据字典表被隐藏,无法直接访问,需要通过information_schema下的同名表进行访问。
information_schema下的所有表使用的都是Memory和InnoDB存储引擎,且都是临时表,不是持久表,在数据库重启之后这些数据会丢失。在MySQL 的4个系统库中,information_schema也是唯一一个在文件系统上没有对应库表的目录和文件的系统库。
分类
-
Server层统计信息字典表
-
Columns 查询表中列信息
-
key_columns_usage 查询哪些索引列存在约束条件 该表中的信息包含主键、唯一索引、外键等约束信息
-
Referential_constraints 提供查询关于外键约束的一些信息。
-
STATISTICS 提供查询关于索引的一些统计信息,一个索引对应一行记录。
-
TABLE_CONSTRAINTS 提供查询与表相关的约束信息
-
FILES 提供查询与MySQL的数据表空间文件相关的信息。
-
ENGINES 提供查询MySQL Server支持的引擎相关信息。
-
TABLESPACES 提供查询关于活跃表空间的相关信息
-
SCHEMATA 提供查询MySQL Server中的数据库列表信息,一个schema就代表一个数据库。
-
-
Server层表级别对象字典表
-
Views 提供查询数据库中的视图相关信息。
-
Triggers 提供查询关于某个数据库下的触发器相关信息。
-
Tables 提供查询与数据库内的表相关的基本信息。
-
Routines 提供查询关于存储过程和存储函数的信息
-
Partitions 提供查询关于分区表的信息。
-
Events 提供查询与计划任务事件相关的信息。
-
Parameters 提供有关存储过程和函数的参数信息,以及有关存储函数的返回值信息。
-
-
Server层混杂信息字典表
-
GLOBAL_STATUS、GLOBAL_VARIABLES、SESSION_STATUS、SESSION_VARIABLES
-
OPTIMIZER_TRACE
-
PLUGINS
-
·············太多了
-
-
InnoDB层的锁、事务、统计信息字典表
提供查询有关InnoDB外键列的状态信息,等同于InnoDB数据字典内部SYS_FOREIGN_COLS表的信息。
-
INNODB_SYS_DATAFILES 提供查询InnoDB所有表空间类型文件的元数据(内部使用的表空间ID和表空间文件的路径信息),包括独立表空间、常规表空间、系统表空间、临时表空间和undo空间(如果开启了独立undo空间的话)。
-
INNODB_SYS_VIRTUAL 提供查询有关InnoDB虚拟生成列和与之关联的列的元数据信息,等同于InnoDB数据字典内部SYS_VIRTUAL表的信息。该表中展示的行信息是与虚拟生成列相关联列的每个列的信息。
-
INNODB_SYS_INDEXES 提供查询有关InnoDB索引的元数据信息,等同于InnoDB数据字典内部SYS_INDEXES表中的信息。
-
INNODB_SYS_TABLES 提供查询有关InnoDB表的元数据信息,等同于InnoDB数据字典内部SYS_TABLES表的信息。
-
INNODB_SYS_FIELDS 提供查询有关InnoDB索引键列(字段)的元数据信息,等同于InnoDB数据字典内部SYS_FIELDS表的信息
-
INNODB_SYS_TABLESPACES 提供查询有关InnoDB独立表空间和普通表空间的元数据信息(也包含了全文索引表空间),等同于InnoDB数据字典内部SYS_TABLESPACES表的信息。
-
INNODB_SYS_FOREIGN_COLS
-
INNODB_SYS_COLUMNS 提供查询有关InnoDB外键的元数据信息,等同于InnoDB数据字典内部SYS_FOREIGN表的信息。
-
INNODB_SYS_FOREIGN 提供查询有关InnoDB外键的元数据信息,等同于InnoDB数据字典内部SYS_FOREIGN表的信息。
-
INNODB_SYS_TABLESTATS 提供查询有关InnoDB表的较低级别的状态信息视图。 MySQL优化器会使用这些统计信息数据来计算并确定在查询InnoDB表时要使用哪个索引。这些信息保存在内存中的数据结构中,与存储在磁盘上的数据无对应关系。在InnoDB内部也无对应的系统表。
-
-
InnoDB层的锁、事务、统计信息字典表
-
InnoDB层的全文索引字典表
-
InnoDB层的压缩相关字典表
应用
查看索引列的信息
INNODB_SYS_FIELDS表提供查询有关InnoDB索引列(字段)的元数据信息,等同于InnoDB数据字典中SYS_FIELDS表的信息。
INNODB_SYS_INDEXES表提供查询有关InnoDB索引的元数据信息,等同于InnoDB数据字典内部SYS_INDEXES表中的信息。
INNODB_SYS_TABLES表提供查询有关InnoDB表的元数据信息,等同于InnoDB数据字典中SYS_TABLES表的信息。
mysql系统库
权限系统表
-
user:包含用户账户、全局权限和其他非权限列表(安全配置字段和资源控制字段)。
-
db:数据库级别的权限表。该表中记录的权限信息代表用户是否可以使用这些权限来访问被授予访问的数据库下的所有对象(表或存储程序)。
-
tables_priv:表级别的权限表。
-
columns_priv:字段级别的权限表。
-
procs_priv:存储过程和函数权限表。
-
proxies_priv:代理用户权限表。
统计信息表
持久化统计功能是通过将内存中的统计数据存储到磁盘中,使其在数据库重启时可以快速重新读入这些统计信息而不用重新执行统计,从而使得查询优化器可以利用这些持久化的统计信息准确地选择执行计划(如果没有这些持久化的统计信息,那么数据库重启之后内存中的统计信息将会丢失,下一次访问到某库某表时,需要重新计算统计信息,并且重新计算可能会因为估算值的差异导致查询计划发生变更,从而导致查询性能发生变化)。
-- 当innodb_stats_persistent = ON时全局的开启统计信息的持久化功能,默认是开启的
show variables like 'innodb_stats_persistent';
-
innodb_table_stats 提供查询与表数据相关的统计信息。
-
innodb_index_stats 提供查询与索引相关的统计信息。
日志记录表
MySQL的日志系统包含:普通查询日志、慢查询日志、错误日志(记录服务器启动时、运行中、停止时的错误信息)、二进制日志(记录服务器运行过程中数据变更的逻辑日志)、中继日志(记录从库I/O线程从主库获取的主库数据变更日志)、DDL日志(记录DDL语句执行时的元数据变更信息。在MySQL 5.7中只支持写入文件中,在MySQL 8.0中支持写入innodb_ddl_log表中。在MySQL5.7中,只有普通查询日志、慢查询日志支持写入表中(也支持写入文件中),可以通过log_output=TABLE设置保存到mysql.general_log表和mysql.slow_log表中,其他日志类型在MySQL 5.7中只支持写入文件中。
general_log
提供查询普通SQL语句的执行记录信息,用于查看客户端到底在服务器上执行了什么SQL语句。
set global log_output='TABLE'; -- 'TABLE,FILE'表示同时输出到表和文件
set global general_log=on;
show variables like 'general_log';
slow_log
slow_log表提供查询执行时间超过long_query_time设置值的SQL语句、未使用索引的语句(需要开启参数log_queries_not_using_indexes=ON)或者管理语句(需要开启参数log_slow_admin_statements=ON)。
set global log_queries_not_using_indexes=on;
set global log_slow_admin_statements=on;
show variables like 'log_queries_not_using_indexes';
show variables like 'log_slow_admin_statements';-- 打开慢查询日志
set GLOBAL slow_query_log=1;-- show VARIABLES like '%long_query_time%'; 默认十秒
InnoDB的统计信息
分类
永久性的统计数据,这种统计数据存储在磁盘上,也就是服务器重启之后这些统计数据还在。
非永久性的统计数据,这种统计数据存储在内存中,当服务器关闭时这些这些统计数据就都被清除掉了,等到服务器重启之后,在某些适当的场景下才会重新收集这些统计数据。
MySQL给我们提供了系统变量innodb_stats_persistent来控制到底采用哪种方式去存储统计数据。在MySQL 5.6.6之前,innodb_stats_persistent的值默认是OFF,也就是说InnoDB的统计数据默认是存储到内存的,之后的版本中innodb_stats_persistent的值默认是ON,也就是统计数据默认被存储到磁盘中。
InnoDB默认是以表为单位来收集和存储统计数据的,我们也可以单独为某个表设置是否自动重新计算统计数的属性,设置方式就是在创建或修改表的时候通过指定STATS_AUTO_RECALC属性来指明该表的统计数据存储方式:
CREATE TABLE 表名 (...)
Engine=InnoDB, STATS_AUTO_RECALC = (1|0);
ALTER TABLE 表名
Engine=InnoDB, STATS_AUTO_RECALC = (1|0);
当STATS_AUTO_RECALC=1时,表明我们想让该表自动重新计算统计数据,当STATS_AUTO_RECALC=0时,表明不想让该表自动重新计算统计数据。如果我们在创建表时未指定STATS_AUTO_RECALC属性,那默认采用系统变量innodb_stats_auto_recalc的值作为该属性的值。