MySQL setup_instruments中关于部分信息不能修改

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
云数据库 RDS PostgreSQL,高可用系列 2核4GB
简介: MySQL setup_instruments中关于部分信息不能修改

朋友告诉我如下操作不能修改

  1. mysql> update setup_instruments set enabled='no' where name='memory/performance_schema/table_handles';
  2. Query OK, 1 row affected (2.61 sec)
  3. Rows matched: 1 Changed: 1 Warnings: 0

  4. mysql> select * from setup_instruments where name='memory/performance_schema/table_handles';
  5. +-----------------------------------------+---------+-------+
  6. | NAME | ENABLED | TIMED |
  7. +-----------------------------------------+---------+-------+
  8. | memory/performance_schema/table_handles | YES | NO |
  9. +-----------------------------------------+---------+-------+
  10. 1 row in set (0.00 sec)

我测试发现所有memory/performance_schema/* 的值都不能更改,但是其他值可以更改。8.0.17依然如此。

既然不能修改则跟一下update接口,我一共跟踪了:

  • table_setup_instruments::update_row_values:修改接口
  • table_setup_instruments::make_row:update_enabled 变量传入值
  • table_setup_instruments::rnd_next():update_enabled 定义值

几个接口。


一、为什么不能修改

查看table_setup_instruments::update_row_values函数你会发现memory/performance_schema/* 这几行值这里都会进入如下逻辑:

  1. case 1: /* ENABLED */
  2. /* Do not raise error if m_update_enabled is false, silently ignore. */
  3. if (m_row.m_update_enabled) //这里是 false
  4. {
  5. value= (enum_yes_no) get_field_enum(f);
  6. m_row.m_instr_class->m_enabled= (value == ENUM_YES) ? true : false;
  7. }
  8. break;

因为m_row.m_update_enabled==false 因此不能修改。其他的值这里是true。这里我们也会看到实际上值只有两个YES或者是NO,不能是其他值。如果update修改为其他值会直接报错。


二、mupdateenabled来源

也就是table_setup_instruments::rnd_next()函数进行判断如果是VIEW_BUILTIN_MEMORY则会设置update_enabled为false,具体如下:

  1. case pos_setup_instruments::VIEW_BUILTIN_MEMORY:
  2. update_enabled= false;//这里设置了false
  3. update_timed= false;
  4. ...

当然何为VIEW_BUILTIN_MEMORY,不太清楚,没仔细看了。

最后本表访问是全表扫描方式。因为上层接口为handler::ha_rnd_next,其含义为如下:

  1. The number of requests to read the next row in the data file. This value is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
  2. 源码函数解释:Reads the next row in a table scan (also used to read the FIRST row in a table scan).
  3. 全表扫描访问下一条数据

debug会发现不断的会访问下一条数据。最后performance_schema是一个独立的引擎,虽然很简单。


三、备用栈帧

1、修改数据

  1. #0 PFS_engine_table::update_row (this=0x7ffe7c1026c0, table=0x7ffe7c1b0370, old_buf=0x7ffe7c1b13f8 "'", new_buf=0x7ffe7c1b1270 "'", fields=0x7ffe7c1b1580)
  2. at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/perfschema/pfs_engine_table.cc:573
  3. #1 0x0000000001942680 in ha_perfschema::update_row (this=0x7ffe7c1b0d70, old_data=0x7ffe7c1b13f8 "'", new_data=0x7ffe7c1b1270 "'")
  4. at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/perfschema/ha_perfschema.cc:293
  5. #2 0x0000000000f90b70 in handler::ha_update_row (this=0x7ffe7c1b0d70, old_data=0x7ffe7c1b13f8 "'", new_data=0x7ffe7c1b1270 "'")
  6. at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/handler.cc:8509
  7. #3 0x000000000168ca00 in mysql_update (thd=0x7ffe7c012940, fields=..., values=..., limit=18446744073709551615, handle_duplicates=DUP_ERROR,
  8. found_return=0x7fffec0f4bd8, updated_return=0x7fffec0f4bd0) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_update.cc:887
  9. #4 0x0000000001692f28 in Sql_cmd_update::try_single_table_update (this=0x7ffe7c008f78, thd=0x7ffe7c012940, switch_to_multitable=0x7fffec0f4c7f)
  10. at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_update.cc:2896
  11. #5 0x0000000001693475 in Sql_cmd_update::execute (this=0x7ffe7c008f78, thd=0x7ffe7c012940) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_update.cc:3023
  12. #6 0x00000000015cc8e9 in mysql_execute_command (thd=0x7ffe7c012940, first_level=true) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:3756
  13. #7 0x00000000015d30c6 in mysql_parse (thd=0x7ffe7c012940, parser_state=0x7fffec0f6600) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5901
  14. #8 0x00000000015c6c5a in dispatch_command (thd=0x7ffe7c012940, com_data=0x7fffec0f6d70, command=COM_QUERY)
  15. at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1490

2、读取数据

  1. #0 table_setup_instruments::make_row (this=0x7ffe7c1026c0, klass=0x2f2e3c0, update_enabled=true, update_timed=true)
  2. at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/perfschema/table_setup_instruments.cc:260
  3. #1 0x00000000019a4b1f in table_setup_instruments::rnd_next (this=0x7ffe7c1026c0)
  4. at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/perfschema/table_setup_instruments.cc:172
  5. #2 0x0000000001942ab2 in ha_perfschema::rnd_next (this=0x7ffe7c1b0d70, buf=0x7ffe7c1b1270 "")
  6. at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/perfschema/ha_perfschema.cc:351
  7. #3 0x0000000000f83812 in handler::ha_rnd_next (this=0x7ffe7c1b0d70, buf=0x7ffe7c1b1270 "") at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/handler.cc:3146
  8. #4 0x00000000014e2b3d in rr_sequential (info=0x7fffec0f4870) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/records.cc:521
  9. #5 0x000000000168c7b3 in mysql_update (thd=0x7ffe7c012940, fields=..., values=..., limit=18446744073709551615, handle_duplicates=DUP_ERROR,
  10. found_return=0x7fffec0f4bd8, updated_return=0x7fffec0f4bd0) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_update.cc:811
  11. #6 0x0000000001692f28 in Sql_cmd_update::try_single_table_update (this=0x7ffe7c008f78, thd=0x7ffe7c012940, switch_to_multitable=0x7fffec0f4c7f)
  12. at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_update.cc:2896
  13. #7 0x0000000001693475 in Sql_cmd_update::execute (this=0x7ffe7c008f78, thd=0x7ffe7c012940) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_update.cc:3023
  14. #8 0x00000000015cc8e9 in mysql_execute_command (thd=0x7ffe7c012940, first_level=true) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:3756
  15. #9 0x00000000015d30c6 in mysql_parse (thd=0x7ffe7c012940, parser_state=0x7fffec0f6600) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5901
  16. #10 0x00000000015c6c5a in dispatch_command (thd=0x7ffe7c012940, com_data=0x7fffec0f6d70, command=COM_QUERY)
  17. at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1490



            </div>
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
安全 Java 数据库连接
实时数仓 Hologres产品使用合集之如果在映射中台表的时候ds被勾选为了字段,可以在分区信息那一页中直接写入 PARTITIONED BY (ds) 吗
实时数仓Hologres是阿里云推出的一款高性能、实时分析的数据库服务,专为大数据分析和复杂查询场景设计。使用Hologres,企业能够打破传统数据仓库的延迟瓶颈,实现数据到决策的无缝衔接,加速业务创新和响应速度。以下是Hologres产品的一些典型使用场景合集。
192 0
|
存储 分布式计算 算法
VLDB论文解读,业界首个自研智能信息传递系统,AnalyticDB Anser框架技术详解
论文提出了一个动态信息传递框架,及一个基于信息流依赖的自适应调度器,来进行执行中长查询的智能优化,有效提升查询性能
|
SQL 新零售 存储
让SQL优化器更准确!AnalyticDB PG版发布统计信息自动收集功能
本次发布的 Auto Analyze 功能解决了在 ADB PG 实例使用过程中,由于未能及时执行 ANALYZE 收集统计信息导致了 CBO 优化器生成计划退化进而导致业务分析变慢的问题。
1168 0
让SQL优化器更准确!AnalyticDB PG版发布统计信息自动收集功能
|
关系型数据库 MySQL 数据库
|
27天前
|
存储 人工智能 OLAP
AI Agent越用越笨?阿里云AnalyticDB「AI上下文工程」一招破解!
AI 上下文工程是管理大模型输入信息的系统化框架,解决提示工程中的幻觉、上下文溢出与信息冲突等问题。通过上下文的采集、存储、加工与调度,提升AI推理准确性与交互体验。AnalyticDB PostgreSQL 版提供增强 RAG、长记忆、Supabase 等能力,助力企业构建高效、稳定的 AI 应用。
|
4月前
|
运维 算法 机器人
阿里云AnalyticDB具身智能方案:破解机器人仿真数据、算力与运维之困
本文将介绍阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL推出的全托管云上仿真解决方案,方案采用云原生架构,为开发者提供从开发环境、仿真计算到数据管理的全链路支持。
|
25天前
|
存储 人工智能 OLAP
AI Agent越用越笨?阿里云AnalyticDB「AI上下文工程」一招破解!
AI上下文工程是优化大模型交互的系统化框架,通过管理指令、记忆、知识库等上下文要素,解决信息缺失、长度溢出与上下文失效等问题。依托AnalyticDB等技术,实现上下文的采集、存储、组装与调度,提升AI Agent的准确性与协同效率,助力企业构建高效、稳定的智能应用。
|
2月前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
307 0
|
3月前
|
存储 人工智能 分布式计算
数据不用搬,AI直接炼!阿里云AnalyticDB AI数据湖仓一站式融合AI+BI
阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL版(以下简称ADB)诞生于高性能实时数仓时代,实现了PB级结构化数据的高效处理和分析。在前几年,为拥抱大数据的浪潮,ADB从传统数仓拓展到数据湖仓,支持Paimon/Iceberg/Delta Lake/Hudi湖格式,为开放的数据湖提供数据库级别的性能、可靠性和管理能力,从而更好地服务以SQL为核心的大规模数据处理和BI分析,奠定了坚实的湖仓一体基础。

热门文章

最新文章