sysbench

做性能测试的必备知识系列，可以看下面链接的文章哦 https://www.cnblogs.com/poloyy/category/1806772.html 课前准备，安装 sysbench 下载 sysbench git clone https: // github.com/akopytov/sysbench.git 安装依赖 yum install autoconf automake libtool -y 编译安装 cd sysbench/ . /autogen. sh . /configure --without- mysql make && make install 百度云链接 链接：https://pan.baidu.com/s/1a9qR9GNzEbj1rkDp2wXfIw 提取码：kone 下载压缩包放到服务器，然后解压即可 如何查看系统的上下文切换情况 vmstat 使用 vmstat 这个工具，来查询系统的上下文切换情况 vmstat 是一个常用的系统性能分析工具，主要用来分析系统的 内存使用情况 ，也常用来 分析 CPU 上下文切换和中断的次数 了解 vmstat 输出的参数含义 每隔 2s 输出一次结果 vmstat 2 这里我们只了解必备参数，后面有单独一篇文章展开来讲解 vmstat 命令 参数分析 cs（context switch）：

MYSQL数据库学习系列四 四．MYSQL的应用优化 4.1-MySQL索引优化与设计 什么是索引 索引的意义 —— 快速定位要查找的数据 数据库索引查找 全表扫描 VS 索引查找 如何根据首字母找到所在行 二分查找 B+tree InnoDB表聚簇索引 索引中只放着排序字段和ID 创建索引 单列索引 create index idx_test1 on tb_student (name); 联合索引 create index idx_test2 on tb_student (name, age); 索引中先根据name排序，name相同的情况下，根据age排序 索引维护 索引维护由数据库自动完成 插入/修改/删除每一个索引行都会变成一个内部封装的事务 索引越多，事务越长，代价越高 索引越多对表的插入和索引字段修改就越慢 控制表上索引的数量，切忌胡乱添加无用索引 如何使用索引 依据WHERE查询条件建立索引 select a, b from tab_a where c=? ; idx_c (c)select a, b from tab_a where c=? and d=?; idx_cd (c, d) 排序order by, group by, distinct字段添加索引 select from tb_a order by a;select a,

GaussDB(for MySQL)数据库在写入性能上，在业界同类产品中是最好的，这主要得益于GaussDB(for MySQL)在MySQL内核方面的诸多优化。其中有一项从“送快递”得来灵感的优化——事务异步提交，值得我们分析。 背景 我们先来看看MySQL 8.0的事务提交的大致流程 图1 MySQL 8.0事务执行流程 以上流程，是MySQL8.0对WAL原则的一种实现，这个流程意味着，任何一个事务的提交，一定要完成write buffer和flush to disk流程。 然而那么这个流程中，有一个问题：每个服务器的CPU是有限的，服务器能处理的Thread也是有上限的，那么当我们的业务的并发数量，远远大于我们服务器能并行处理的数量时，那么后来的事务，只能等待前面的事务提交后才能被处理。在这之前，他们什么也做不了。因此，在大并发场景下，如何进一步提升线程的使用率，是大并发事物写入的一个关键。 灵感来源于生活 一个优化，并不是凭空想象出来的，有时候，往往来源于现实生活。下面，我们先来看看我们身边，和事务提交流程非常类似的一个例子：快递。 现在的快递配送，一般一个快递员会负责一片区域，快递刚开始兴起时，数量不多，那么一个快递员基本上可以在规定时间内完成配送。 图2 过去的快递配送 但是，随着快递数量越来越多，一个快递员要在一个小区配送很长的时间，才能到下一个小区

一、MySQL自带的压力测试工具——Mysqlslap mysqlslap是mysql自带的基准测试工具,该工具查询数据,语法简单,灵活容易使用.该工具可以模拟多个客户端同时并发的向服务器发出查询更新,给出了性能测试数据而且提供了多种引擎的性能比较。mysqlslap为mysql性能优化前后提供了直观的验证依据,系统运维和DBA人员应该掌握一些常见的压力测试工具,才能准确的掌握线上数据库支撑的用户流量上限及其抗压性等问题。 1、更改其默认的最大连接数 在对MySQL进行压力测试之前，需要更改其默认的最大连接数，如下： [root@mysql ~]# vim /etc/my.cnf ................ [mysqld] max_connections=1024 [root@mysql ~]# systemctl restart mysqld #查看最大连接数 mysql> show variables like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 1024 | +-----------------+-------+ 1 row in set (0.00 sec)

MySQL CPU 使用率高的原因和解决方法_产品性能_常见问题_云数据库 RDS 版-阿里云 https://help.aliyun.com/knowledge_detail/51587.html 常见原因 系统执行应用提交查询（包括数据修改操作）时需要大量的逻辑读（逻辑 IO，执行查询所需访问的表的数据行数），所以系统需要消耗大量的 CPU 资源以维护从存储系统读取到内存中的数据一致性。 本文通过一个简化的模型来说明系统资源、语句执行成本以及 QPS（Query Per Second 每秒执行的查询数）之间的关系： 条件：应用模型恒定（应用没有修改）。 avg_lgc_io：执行每条查询需要的平均逻辑 IO。 total_lgc_io：实例的 CPU 资源在单位时间内能够处理的逻辑 IO 总量。 关系公式： total_lgc_io = avg_lgc_io x QPS -- 单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量 。 避免出现 CPU 使用率达到 100% 的一般原则 设置 CPU 使用率告警，实例 CPU 使用率保证一定的冗余度。 应用设计和开发过程中，要考虑查询的优化，遵守 MySQL 优化的一般优化原则，降低查询的逻辑 IO，提高应用可扩展性。 新功能、新模块上线前，要使用生产环境数据进行压力测试（可以考虑使用阿里云 PTS

测试负载场景 配置信息 128G 缓冲池 64G 缓冲池 32G缓冲池 总结 附录 my.cnf 15.6.4 Doublewrite Buffer 原文链接：http://dimitrik.free.fr/blog/posts/mysql-80-perf-new-dblwr.html 作者：Dimitri 译者：孟维克 新的MySQL8.0.20版本重新设计了InnoDB Double Write（DBLWR），确实是一个大的历史烦人的事情。为什么在过去这么痛苦，让我们付出了这么多精力，我无法更好地解释，因为从2018年开始，我已经在下面一篇关于MySQL基于IO负载的文章中说过了。这个故事并不完整，因为它缺少2019年的那一篇（稍后再讲），但是如果你（重新）读过上面的这篇文章提到的内容，您会更好理解接下来的内容。 但至少现在这篇文章是关于好消息的——新的DBLWR以及它如何帮助解决历史上MySQL性能问题！由于一张图片胜过百万字，我将尽量节省三百万字（因为本文中有三张图片） 我会跳过所有的新的设计细节（我认为Sunny会更好的第一手解释所有的）——我只会提到以下内容： DBLWR不再是“系统表空间”的一部分，可以被放置在任何地方（如果您有可能使用不同的存储存放DBLWR文件，您完全可以摆脱DBLWR对您主存储的影响），但默认情况下，DBLWR和您的数据存储在相同的目录下。

用户在使用 MySQL 实例时，会遇到 CPU 使用率过高甚至达到 100% 的情况。本文将介绍造成该状况的常见原因以及解决方法，并通过 CPU 使用率为 100% 的典型场景，来分析引起该状况的原因及其相应的解决方案。 常见原因 系统执行应用提交查询（包括数据修改操作）时需要大量的逻辑读（逻辑 IO，执行查询所需访问的表的数据行数），所以系统需要消耗大量的 CPU 资源以维护从存储系统读取到内存中的数据一致性。 说明：大量行锁冲突、行锁等待或后台任务也有可能会导致实例的 CPU 使用率过高，但这些情况出现的概率非常低，本文不做讨论。 本文通过一个简化的模型来说明系统资源、语句执行成本以及 QPS（Query Per Second 每秒执行的查询数）之间的关系： 条件：应用模型恒定（应用没有修改）。 avg_lgc_io：执行每条查询需要的平均逻辑 IO。 total_lgc_io：实例的 CPU 资源在单位时间内能够处理的逻辑 IO 总量。 关系公式： total_lgc_io = avg_lgc_io x QPS -- 单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量 解决方法 数据管理（DMS） 工具提供了几种辅助排查并解决实例性能问题的功能，主要有： 实例诊断报告 SQL 窗口提供的查询优化建议和查看执行计划 实例会话 其中

（1.10）常用SQL优化 insert优化、order by 优化 1、insert 优化 　　 2、order by 优化 【2.1】mysql排序方式： 　　（1）索引扫描排序：通过有序索引扫描直接返回有序数据 　　（2）filesort排序：所有不是索引扫描返回结果的数据均为filesort排序 　　filesort优化： 　　　　 3、优化group by 　　 　　 　　 　　 4、子查询优化 　　在！= 操作的子查询中，可以用left join + is null 来优化 5、or优化 　　or 在同字段下可以改成 in 　　在不同字段下可以使用Union all 6、limit优化 【6.1】子查询优化/join（id为索引字段） 　　 这种方式先定位偏移位置的 id，然后往后查询，这种方式适用于 id 递增的情况。 　　　　 SELECT * FROM product WHERE ID > = ( select id from product limit 866613 , 1 ) limit 20 　　　　　或者 SELECT * FROM product a JOIN ( select id from product limit 866613 , 20 ) b ON a.ID = b.id 【6.2】ID限定优化 　　　　　　 使用 id 限定优化 　

测试环境 本文档是在 99Cloud Lab OpenStack 平台虚机上面测试，仅供参考。 系统： CentOS 7.3 虚机： 2 核 4G 版本： MySQL 5.7 技术架构 MySQL Group Replication（简称 MGR）是官方推出的高可用解决方案，原生复制技术，基于插件的方式工作。其中 single primary mode 单主模式只有一个读写，其余都是只读。 multi primary mode多主模式全部可读写 不管组复制单主还是多主的故障切换都无法让应用无感知，需要自主实现，包含以下特性： 复制管理操作更为自动化。 通过 Paxos 协议提供数据库集群节点数据强一致性保证。 多主模式所有节点都可读写操作。 解决网络分区导致的脑裂问题，提升复制数据的可靠性。 一些不足 01、官方引言 Quite obviously, regardless the mode Group Replication is deployed, it does not handle client-side fail-over. That must be handled by the application itself, connector or a middleware framework such as a proxy or router. 意思就是 MGR

背景： MySQL5.7在主从复制上面相对之前版本多了一些新特性，包括多源复制、基于组提交的并行复制、在线修改Replication Filter、GTID增强、半同步复制增强等。因为都是和复制相关，所以本文将针对这些新特性放一起进行说明，篇幅可能稍长，本文使用的MySQL版本是5.7.13。 1， 多源复制 （多主一从） MySQL在5.7之后才支持多源复制，之前介绍过 MariaDB 多主一从 搭建测试 说明，现在介绍如何在MySQL上做多主一从，具体的方法说明可以查看 官方文档 。 原理： 多源复制 加入了一个叫做 Channel 的概念， 每一个Channel都是一个独立的Slave，都有一个IO_THREAD和SQL_THREAD。原理和普通复制一样。我们只需要对每一个Master执行Change Master 语句，只需要在每个语句最后使用For Channel来进行区分。由于复制的原理没有改变，在没有开启GTID的时候Master的版本可以是MySQL5.5、5.6、5.7。并且从库需要 master-info-repository 、 relay-log-info-repository 设置为table，否则会报错： ERROR 3077 (HY000): To have multiple channels, repository cannot be of type