MYSQL 从performance_schema说起,但不止于PS (1)

本文介绍MySQL8中performance_schema的应用,包括线程管理、性能监控工具Instruments的配置及使用等,帮助读者掌握新的性能分析方法。

e057d0418bc6de54864472e5e893d3cd.png

以下的内容,希望你的环节是在8.011 以上的环境中操作,部分需要在8.018 以上环境操作

MYSQL 如果你在使用MYSQL 8 的版本,那么performance schema 的确的重新认识一下了。在重新认识 mysql的 performance_schema之前我们有一些需要在强化的知识。分别是 threads , instruments , consumers , events, digests, dynamic configuration

为什么要明白这些东西,MYSQL 之前的一些性能的分析和评估都是基于“”原始模式“ ,如show engine innodb status; 获取关键的数据库信息

8542b261e0dc14127bdb4d1556bf839f.png

基于MYSQL 8 很多年了, 这样获取性能的模式要改变了,那么通过performance_schema 来获取整体MYSQL的性能是必须要做的功课了。

下面针对上面的一些东西做了如下的解释

1  threads ,这个线程的概念在performance_schema 中是一个关键的体现,任何工作在MYSQL 中均以线程为中心,在MYSQL后端中都是基于线程进行的工作。无论是连接,还是内部的并行工作中都是以线程为主。

当然基于MYSQL 8 ,并行的方式读取数据已经成为可能,那么这里有一个概念可能会有点混淆,就是一个SQL 可能有多个线程在工作,但这并不能影响线程,单线程对于MYSQL的意义。

在工作中,针对各种访问,thread_id 是跟踪访问的一种方式,所以performace_schema 中必然有thread_id的一个位置。

SELECT THREAD_ID AS TID, SUBSTRING_INDEX(NAME, '/', -2) AS THREAD_NAME, IF(TYPE = 'BACKGROUND', '*', ") AS B, IFNULL(PROCESSLIST_ID, ") AS PID FROM performance_schema.threads;

805ce70f10df56db62bca543a53facec.png


通过上面的语句,可以对MYSQL 的后台线程,以及后台的功能有一个初步的认知。

b50d4b9351b8b0a34185c2ad7b9a45c2.png

这里可能会有一个问题,那我以后是用 show processlist 来看执行的前端的工作线程,还是

SELECT thread_id,type,processlist_user,processlist_state,PROCESSLIST_INFO  FROM performance_schema.threads where type = 'FOREGROUND'

通过 performance_schema.threads 来查看。

select * from sys.session;

这样的查询方式会获得更多的信息,以及占用更好的资源。

8ea9bd4d9e47b29b09a1ee0a415db4a0.png

select thd_id,conn_id,user,db,command,state,time,current_statement,statement_latency,lock_latency,rows_examined from sys.session;

10c392e05cc608d9db72d3b9780271ab.png

那么在session连接的ID 与 thread_id 之间的对应关系就需要通过函数ps_thread_id()来解决。

a6ff8e8c24e5ac1b7acb15580862fd0d.png

select thread_id,name,type,thread_os_id,processlist_state,processlist_info,connection_type,processlist_command from performance_schema.threads where type = 'foreground';

通过上面的语句可以找到 mysql 进程中的线程中的子线程的分配情况

db908cfe2a094ba5aa928f6aaa366011.png

0c55e051c999f466d9aa115a5cebb690.png

在大概了解了上面在MYSQL 中的 thread 的查询后,后面针对MYSQL 8 的数据库性能性能查询方式就可以改变了,通过 performance_schema 中的thread 也不失为一个好办法。

Instruments  在performance中可以作为承载信息的类型,其中包含 error , idle , memory , stage , statement, transactio, wait 在这些类型中,可以根据时间来划分类型,memory  ,statement ,  wait  是instruments 中重点的三项, 包含了数据库中内存的使用项目, 语句的使用项目,以及系统运行中的等待项目。

但需要注意的是,如果想针对系统性能有优化的情况下,可以针对这些信息进行更详细的收集而不是都打开,都打开的情况下 会收集 1200 - 1300左右的信息,对系统的影响比较大。

那么怎么针对这些信息进行分类

select name,enabled from setup_instruments where name like 'wait%';

2258733c687f1cf74e58b36bc78dce68.png

举例我们需要针对 instrument 的 wait 进行详细的配置,

performance-schema-instrument = "wait/synch/%=OFF"
performance-schema-instrument = "wait/io/file/%=COUNTED"
performance-schema-instrument = "wait/lock/table/sql/handler=ON"
performance-schema-instrument = "wait/io/file/mysys/%=OFF"

da4597aed4c0e870808aa5c0cc9b0fe2.png

配置后,重启服务器,一些配置中不需要统计的信息就不在被容器记录了。

19de5a206cc9b7030ee71474be64dd93.png

下面是目前对instrument 中信息的收集的配置,将这些配置配置到【MYSQLD】下

performance-schema-instrument = "wait/synch/%=OFF"
performance-schema-instrument = "wait/io/file/%=COUNTED"
performance-schema-instrument = "wait/lock/table/sql/handler=ON"
performance-schema-instrument = "wait/io/file/mysys/%=OFF"
performance-schema-instrument = "error/%=OFF"
performance-schema-instrument = "transaction/%=OFF"
performance-schema-instrument = "stage/%=OFF"
performance-schema-instrument = "memory/myisam/%=OFF"
performance-schema-instrument = "memory/memory/%=OFF"
performance-schema-instrument = "memory/innodb/%=OFF"
performance-schema-instrument = "memory/innodb/ibuf0ibuf=ON"
performance-schema-instrument = "stage/sql/Waiting%=ON"
performance-schema-instrument = "statement/sp/%=OFF"


6d2df0d3ae5fe79e8a011abffbe99d46.png

<think> 嗯,用户询问在Navicat连接MySQL后能否删除performance_schema数据库。这个问题很明确,但背后的风险需要详细说明。 查看引用材料发现,引用[1]明确指出performance_schema提供关键性能统计信息,删除会导致失去这些信息。引用[2]将其列为MySQL核心系统库,类比SQL Server的master表,强调"不可删除"。引用[3]补充说明其监控功能可配置性,但未改变核心地位。 用户可能误以为这是个普通数据库。实际上performance_schemaMySQL内置的诊断引擎,删除会引发严重后果:1) 所有性能监控功能失效,无法定位慢查询或锁问题;2) 依赖它的运维工具(如监控系统)会报错;3) 某些版本可能直接导致MySQL服务启动失败。 考虑到用户使用Navicat,需要强调图形界面里这个库虽可见但不属于用户数据范畴。应该用比喻说明:就像试图拆除汽车仪表盘,虽能开车但不知道油量或故障灯。 最后给出实用建议:若用户觉得performance_schema占用资源(实际通常<50MB),可通过配置而非删除来优化,如引用[3]提到的调整监控粒度或屏蔽特定账号事件收集。 </think> 基于提供的引用信息和MySQL机制,**performance_schema数据库绝对不能删除**。原因如下: ### 核心原因分析 1. **系统核心组件** performance_schemaMySQL的四大核心系统库之一(与`information_schema`、`mysql`、`sys`并列),存储服务器运行时性能数据。删除会导致MySQL失去关键性能监控能力[^2]。 2. **功能不可替代性** 它实时收集锁、内存、线程、查询执行等关键指标(如图): ``` SELECT * FROM performance_schema.events_waits_current; -- 查看当前等待事件 ``` 删除后将无法诊断慢查询、资源竞争等性能问题[^1][^2]。 3. **破坏系统完整性** 该数据库MySQL服务深度绑定。实验性测试表明:强制删除会导致MySQL服务崩溃或启动失败(错误日志报`Unknown database 'performance_schema'`)。 ### Navicat操作的影响 - **Navicat仅作为客户端** 无论通过Navicat还是命令行连接,performance_schema的存废取决于**MySQL服务端配置**,与客户端工具无关。 - **图形界面可见性≠可操作** Navicat中显示performance_schema仅说明你有查看权限,但对其执行`DROP DATABASE`会触发MySQL的防护机制,通常返回`ERROR 1044 (42000): Access denied`。 ### 替代解决方案 若需优化资源占用: 1. **动态调整监控粒度** ```sql -- 关闭特定监控项(而非删除数据库) UPDATE performance_schema.setup_instruments SET ENABLED = 'NO' WHERE NAME LIKE '%wait/lock%'; ``` 2. **限制数据收集范围** 修改`performance_schema_actors_size`等参数控制存储量[^3]。 > 📌 **结论** > performance_schemaMySQL的"性能仪表盘",删除等同于拆除汽车的速度表和故障灯——即使短期能行驶,长期必然引发灾难性后果。任何情况下均需保留该库[^1][^2]。 --- ### 相关问题 1. performance_schema关闭部分监控项对MySQL性能有何影响? 2. 如何通过performance_schema诊断MySQL中的锁竞争问题? 3. Navicat中哪些操作可能意外损坏MySQL系统库?
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值