读高性能MySQL(第4版)笔记20_Performance Schema和其他

这篇具有很好参考价值的文章主要介绍了读高性能MySQL(第4版)笔记20_Performance Schema和其他。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

读高性能MySQL(第4版)笔记20_Performance Schema和其他文章来源地址https://www.toymoban.com/news/detail-711082.html

1. 线程

1.1. MySQL服务端是多线程软件。它的每个组件都使用线程

1.2. 每个线程至少有两个唯一标识符

1.2.1. 操作系统线程ID

1.2.2. MySQL内部线程ID

2. 对象类型

2.1. OBJECT_TYPE列

2.2. EVENT

2.3. FUNCTION

2.4. PROCEDURE

2.5. TABLE

2.6. TRIGGER

3. Performance Schema

3.1. 一个经常受到批评的特性

3.1.1. 早期版本的MySQL对其的实现不够理想,导致资源消耗较高

3.2. 提供了有关MySQL服务器内部运行的操作上的底层指标

3.3. 应该启用Performance Schema,按需动态地启用插桩和消费者表,通过它们提供的数据可以解决可能存在的任何问题——查询性能、锁定、磁盘I/O、错误等

3.4. 充分利用sys schema是解决常见问题的捷径。这样做将为你提供一种可以直接从MySQL中测量性能的方法

3.5. 程序插桩(instrument)

3.6. 消费者表(consumer)

3.7. 测量结果存储在Performance Schema数据库的多个表中

3.7.1. MySQL 8.0.25社区版的performance_schema中包含110个表

3.8. 摘要是一种通过删除查询中的变量来聚合查询的方法

3.9. 实例表(Instance)

3.9.1. 实例是指对象实例,用于MySQL安装程序

3.10. 设置表(Setup)

3.10.1. 用于performance_schema的运行时设置

3.11. metadata_locks表保存关于元数据锁的数据

3.12. Performance Schema收集的数据保存在内存中

3.13. 标准MySQL发行版包括一个和performance_schema数据配套使用的sys schema,它全部基于performance_schema上的视图和存储例程组成

3.14. 要启用或禁用Performance Schema,可以将变量performance_schema设置为ON或OFF

3.15. 启用或禁用performance_schema插桩

3.15.1. 使用setup_instruments表

3.15.1.1. 使用UPDATE语句更改instruments表的对应列值

3.15.2. 调用sys schema中的ps_setup_enable_instrument存储过程

3.15.2.1. ps_setup_enable_instrument

3.15.2.2. ps_setup_disable_instrument

3.15.3. 使用performance-schema-instrument启动参数

3.15.3.1. 变量支持performance-schema-instrument='instrument_name=value'这样的语法

3.16. 启用或禁用消费者表

3.16.1. 使用Performance Schema中的setup_consumers表

3.16.2. 调用sys     schema中的ps_setup_enable_consumer或ps_setup_disable_consuper存储过程

3.16.3. 使用performance-schema-consumer启动参数

3.17. 事务执行期间会一直持有元数据锁

3.17.1. 要启用元数据锁监测,需要启用wait/lock/meta-data/sql/mdl插桩

4. 升级MySQL

4.1. 新版本和稳定性之间的权衡

4.1.1. MySQL社区的长期成员Stewart Smith创造了著名的dot-20规则

4.1.2. 一款软件在dot-20版本发布之前永远不会真正成熟。

4.2. 进行版本升级是一个有风险的过程

4.2.1. 包括备份所有数据、测试更改,然后运行升级过程

4.3. 大版本的升级可能会让人望而却步

4.4. 升级的原因

4.4.1. 安全漏洞

4.4.1.1. 随着时间的推移,这种可能性会越来越小,但人们仍然有可能在MySQL中发现安全漏洞

4.4.2. 已知的bug

4.4.2.1. 在生产环境中遇到未知或无法解释的行为时,我们建议你确定当前运行的MySQL版本,然后阅读后续版本到最新版本的发布说明

4.4.3. 新功能

4.4.3.1. MySQL并不总是遵循严格的主要(major)/次要(minor)/点(point)的版本发布策略来添加功能

4.4.4. MySQL支持周期的终止

4.4.4.1. 建议保持在受支持的版本内,以便至少仍支持安全修复

4.5. 升级步骤

4.5.1. 制订一个计划

4.5.2. 阅读该版本的发行说明,包括任何微小的更改

4.5.3. 阅读官方文档中的升级说明

4.5.4. 对新版本进行测试

4.5.5. 最后执行升级

4.6. 降级

4.6.1. 对于所有主要和次要的版本变更(例如,从8.0降级到5.7或从5.7降级到5.6),降级的唯一方法是恢复升级前的备份

4.6.2. 自从MySQL 8.0以来,不能再降级点发布版本

4.6.3. 如果你运行的是8.0.25版本,除非导出所有数据并重新导入,否则不能再降级到8.0.24

4.7. 工具

4.7.1. Percona Toolkit提供的工具pt-upgrade

4.8. 最好的使用方法是首先使用慢速查询日志或二进制日志收集最关注的查询

4.9. 与直接登录到每台服务器相比,自动化可以使升级过程易于重复,并且效率更高,而且因出现拼写错误或者到错误的服务器上执行升级而导致意外停机的概率也更低

5. Kubernetes

5.1. 在Kubernetes技术流行之前,许多公司要么完全定制技术栈来供应和管理虚拟机和物理服务器,要么只完成了将资源生命周期管理一小部分的开源项目黏合在一起

5.2. MySQL不应该是在组织中Kubernetes上运行工作负载的第一个实验对象

到了这里,关于读高性能MySQL(第4版)笔记20_Performance Schema和其他的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 读高性能MySQL(第4版)笔记08_创建高性能索引(上)

    2.4.2.1. 按照索引列中的数据大小顺序存储的 2.4.3.1. 键前缀查找只适用于根据最左前缀的查找 2.4.4.1. 在查询某些条件的数据时,存储引擎不再需要进行全表扫描 2.4.4.2. 通过比较节点页的值和要查找的值可以找到合适的指针进入下层子节点,这些指针实际上定义了子节点页中

    2024年02月08日
    浏览(47)
  • 读高性能MySQL(第4版)笔记12_查询性能优化(下)

    2.3.1.1. 读取行指针和需要排序的字段,对其进行排序,然后再根据排序结果读取所需要的数据行 2.3.1.2. 即需要从数据表中读取两次数据,第二次读取数据的时候,因为是读取排序列进行排序后的所有记录,这会产生大量的随机I/O,所以两次传输排序的成本非常高 2.3.2.1. 先

    2024年02月08日
    浏览(48)
  • 读高性能MySQL(第4版)笔记10_查询性能优化(上)

    4.11.1.1. 在存储引擎层完成的 4.11.2.1. 直接从索引中过滤不需要的记录并返回命中的结 4.11.2.2. 在MySQL服务器层完成的,但无须再回表查询记录 4.11.3.1. 在MySQL服务器层完成 4.11.3.2. 需要先从数据表中读出记录然后过滤 4.13.2.1. 使用单独的汇总表 5.5.1.1. 定期清除大量数据时,

    2024年02月08日
    浏览(56)
  • 读高性能MySQL(第4版)笔记18_扩展MySQL

    4.2.2.1. 增加更多应用节点可以扩展服务用户请求的客户端数 4.2.2.2. 最终会被单源数据库主机的能力所限制,该数据库主机将要负责响应所有的读取请求 4.2.2.3. 高CPU使用率意味着服务器正花费所有的时间处理查询 4.2.2.4. CPU的使用率越高,查询的延迟也会越长 6.9.1.1. 负载均

    2024年02月08日
    浏览(51)
  • 读高性能MySQL(第4版)笔记03_监控

    7.1.1.1. 200响应代码 7.1.2.1. 202已接受 10.3.2.1. 连接的线程数(threads_connected)很高,但运行的线程数(threads_running)仍然很低 10.3.3.1. 连接的线程数(threads_connected)和运行的线程数(threads_running)都处于高值并持续增加 10.5.1.1. 数据库工程师不断努力的目标之一

    2024年02月12日
    浏览(36)
  • 读高性能MySQL(第4版)笔记02_MySQL架构(下)

    2.6.4.1. 失败的事务可能导致不一致的结果,因为某些部分可以回滚,而其他部分不能回滚 5.1.1.1. 在表的.ibd文件中 5.1.1.2. 减少了I/O,非常高效 5.2.1.1. 分区定义 5.2.1.2. 表定义 5.2.1.3. 存储程序定义 5.2.1.4. 字符集 5.2.1.5. 排序信息 5.2.2.1. 每个表的.ibd和.frm文件被替换为已经

    2024年02月12日
    浏览(54)
  • 读高性能MySQL(第4版)笔记01_MySQL架构(上)

    1.2.2.1. 存储过程 1.2.2.2. 触发器 1.2.2.3. 视图 3.3.2.1. 共享锁(shared lock) 3.3.2.2. 资源上的读锁是共享的,或者说是相互不阻塞的 3.3.3.1. 排他锁(exclusive lock) 3.3.3.2. 写锁则是排他的,也就是说,一个写锁既会阻塞读锁也会阻塞其他的写锁 3.3.3.3. 只有这样才能确保在特定的

    2024年02月13日
    浏览(42)
  • 读高性能MySQL(第4版)笔记17_复制(下)

    1.3.1.1. 安全补丁 1.3.1.2. 内核更新 1.3.1.3. 一些配置选项更改后需要重新启动才能生效 1.3.2.1. 确定将哪个副本切换为新的源 1.3.2.1.1. 一个包含所有数据的副本 1.3.2.2. 检查延时,确保延时在秒级别 1.3.2.3. 通过设置super_read_only停止数据写入源服务器 1.3.2.4. 等待副本与目标完

    2024年02月08日
    浏览(45)
  • 读高性能MySQL(第4版)笔记16_复制(上)

    4.1.1.1. 通过记录所有在源端执行的数据变更语句来实现的 4.1.1.2. 简单且紧凑 4.1.1.3. 一条更新了大量数据的SQL语句,在二进制日志中可能仅仅需要几十字节存储 4.1.1.4. “不确定性”的SQL语句问题 4.1.1.4.1. 如果在源和副本上,记录的排序不同,这条SQL语句在源和副本上删除

    2024年02月08日
    浏览(38)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包