MySQL 5.7 vs 8.0，性能PK

关于MySQL 5 .7 和8 .0的性能对比，有话要说。

我们先来说说高安全性的双配置。
5 .7 .2 2 和 8 .0.1 5 由同一个人在读写模式下使用。
但在 8 .0.1 5 中，当 1 2 0 个线程并发时，会出现明显的抖动。
老实说，我当时不明白为什么。
可能与内部资源的竞争有关。

在只读模式下，5 .7 .2 2 的使用人数比 8 .0.1 5 多约 1 /3 随着组合数量的增加，5 .7 .2 2 的性能逐渐下降。
在只写模式下，5 .7 .2 2 比8 .0.1 5 强大约1 /4 ，稳定性更好。

02 配置，我们先来说说高性能设置。
当上下文较低时，5 .7 .2 2 在读写模式下速度更快。
我通过了 8 .0.1 5 ，有超过 8 0 个线程。
然而，在极端并行的情况下，两者都会损失性能。
在只读模式下，5 .7 .2 2 仍然强 1 /3 左右。
只写模式下，5 .7 .2 2 TPS波动较大，但QPS比8 .0.1 5 高1 /3 左右。

为什么会有这样的差异？主要原因在于这几个方面。

一是交易和记录机制。
8 .0中新的原子数据字典和InnoDB事务系统提高了安全性。
然而，当以高币种书写时，Lockdown竞争大超缓存管理；造成性能波动。
5 .7 .2 2 的日志系统在双1 配置下更加稳定。

第二点是顺序控制优化。
当并发量较低时，8 .0.1 5 中的锁管理优化没有用处。
5 .7 .2 2 的元数据锁定和行锁定机制在测试场景中工作得更加平衡。

三是资源利用。
在8 .0.1 5 中，02 配置下，通过延迟日志刷新和事务优化来释放部分性能。
但当货币高位时，仍受到国内资源竞争的限制。

测试环境为4 核KVM，功能较少； innodb_buffer_pool_size只有1 2 8 M。
8 .0.1 5 的并行查询和资源分配权限可能受到限制。
实际生产环境中； 8 .0 改进的性能功能（例如资源组和并行复制）将在高配置硬件上表现更好。

总体来说，5 .7 .2 2 在低耦合或者资源有限的情况下更加稳定。
它在只读和只写任务方面表现出色。
8 .0.1 5 高兼容性阅读在写入场景中可能更高，但必须优化配置（例如调整 innodb_buffer_pool_instances 或升级硬件）。
用户可以选择自己的工作负载类型；必须根据相对规模和硬件条件选择版本。

请教：mysql 运行一段时间后速度变慢问题

MySQL慢诊断分为三步； 1 .1 内部观察：
进程列表：检查异常SQL。

解释：分析实施计划。

Profiling：SQL分析重复执行。

Performance_schema/sys_schema：高级诊断视图。

InnoDB_metrics：引擎诊断。
（注：实施先进方案成本较高，谨慎使用）
1 .2 外部资源观察：
正常运行时间：机器负载。

dmesg-T|tail：系统日志错误。

vmstat1 ：虚拟内存状态。

mpstat-PALL：相等的CPU核心权重。

pidstat1 进程资源利用率。

iostat-xz1 ：IO问题。

lib-m：内存使用情况。

sar：网络/TCP状态机消耗。

顶部：问题线程处理。
（1 0诫涵盖关键能力）
1 .3 外部需求转化：
业务 SQL 优化：将子查询连接到非连接子查询。

原理：代数相对等价变换。

案例：拆解子查询以降低成本。
（仅在诊断成本较高时使用）
实用建议：优先内部工具，其次是外部检查，最后是SQL改造。

mysql中的慢查询会不会影响速度

结论：MySQL5 .7 执行SQL缓慢是因为优化器做出了错误的猜测，并将其重写为相关子查询。

步骤： 1 、安装MySQL5 .7 环境。
2 . 脚本生成的表包括主键表和非主键表。
3 . 基本SQL执行时间为1 6 .8 0秒。
4 、分析执行计划，发现元数据表中没有统计信息。
5 、查看警告，发现SQL被改写为相关子查询。
6 、分析重写的原因。
非相关子查询可以缓存结果，而相关子查询则需要循环迭代。
7 .使用提示来指导优化器，将其重写为不相关的子查询。
8 、优化后的SQL执行时间为0.6 7 秒。

要点：
元数据表执行计划无效。

优化器做出了错误的猜测，并将其重写为相关子查询。

使用提示来自定义问题。