更换某个数据库进行各种前期的测试和比对是非常正常的事情，但是再正常的事情中，可以包含无数的你意料以外的事情，今天就所说最近遇到了一次有意思的数据库测试POC中的问题。
CDB现在支持类型复制类型比较多，我这里选择以下几种复制类型压测对比： MySQL 5.6[异步|半同步|增强半同步]复制，5.7异步复制（当时5.7只支持异步复制).
最近看到一句话是MySQL的TPS是4000，这句话是不严谨的，因为没有说服务器的配置。所以自己买了个服务器做了一个压测。希望自己对数据有一个概念。 注意：服务器不同结果不同，结果不具有普适性。
mysql数据库已经没得连接了, 却使用了超过 80%的内存...., 导致其它应用没得内存用了, 触发了os的oom....
中间件dble测试成员，主要负责dble的日常测试工作，热衷于探索发现，学习新技术。
某项目压测后发现qps达标，服务器cpu和内存占用均在70%以下，然而mysql服务的内存占用高达100%，且并没有因为压测而产生波动。
在前面的压力测试过程中，主要关注的是对接口以及服务器硬件性能进行压力测试，评估请求接口和硬件性能对服务的影响。但是对于多数Web应用来说，整个系统的瓶颈在于数据库。
计划今年将数据库服务器的os 从centos 6 升级到centos 7,根据惯例,升级之前我们要进行一次性能压测。本文分享一下我们的压测记录和结果。
MySQL性能压测或者基准测试看起来很简单，使用sysbench，tpcc工具跑跑拿到数据就好，其实压测是一个技术活儿，尤其是涉及到性能对比的测试，因为不同场景/不同厂商的产品的参数设置不同，测试的结果也不一样。如果不阐明具体的参数配置差异，直接给出压测结果可能给其他人带来误导。
BenchmarkSQL 是一个支持众多关系型数据库的基准测试工具，通过使用 BenchmarkSQL 对数据库进行 TPC-C 标准测试，即模拟多种事务处理：新订单、支付操作、订单状态查询、发货、库存状态查询等，从而获得最终的压测值。相较于 Sysbench 的单一，它更能贴切的模拟出真实的应用场景，因此越来越多的客户在对数据库进行压测时，更多的选择使用 BenchmarkSQL 。
本节内容讲述线上的调优手段以及压力测试的相关工具，结合一些实际的命令参数，我们将会介绍运行结果的具体含义。本节内容为大致的介绍如何压力测试和如何阅读参数，具体的运行效果需要自己部署一台机器测试，关于这部分的内容受到不同的机器影响会出现完全不同的效果，需要实际测试所以没有进行记录。
在经历了惨痛的黑天鹅事件以及激烈的数据恢复过程后，作为微盟DBA的我们进行了深刻的反省和自查，作为公司的核心资产，数据库也得到了前所未有的重视。如何保证数据安全以及用户服务的高可用性是我们要解决的首要问题。
在对系统进行压测时有时要进行局部压测，比如对数据库的读写性能压测，使用过数据库以及搜索引擎的小伙伴相信对缓存这个东西一定不会陌生，如果我们在对数据库或者es之类的搜索引擎进行压测时一定要采用随机的参数，否则压测意义就不大了，因为从缓存返回数据跟从io读取数据后返回是两码事，这两种情况在性能上相差太大，当然是用一定固定值进行压测也不符合实际生产过程中使用场景，本文主要介绍一种使用jmeter压测mysql数据库时的一种随机参数生成方式，当然这也不符合实际应用场景，尤其是一些涉及多个关联查询的情况，如果一个查询查不到可能直接返回了，这样也不够真实，更真实一些的方式应该是将系统中已有的数据放在jmeter中进行压测，本文先简单介绍下jmeter随机参数压测mysql的方法：
本文的宗旨在于通过简单干净实践的方式，向读者展示 SpringBoot 应用程序对接 MySQL 时，在使用不同连接池以及不使用连接池时，在增删改查的一个性能对比。这也包括更新和查询时，索引字段的关键性。
事情的背景是这样的：一个朋友今年年初新开了一家公司，自己是公司的老板，不懂啥技术，主要负责公司的战略规划和经营管理，但是他们公司的很多事情他都会过问。手下员工30多人，涵盖技术、产品、运营和推广，从成立之初，一直在做一款社交类的APP。平时，我们一直保持联系，我有时也会帮他们公司处理下技术问题。
基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程
在大量并发读请求、读多写少的业务场景下，本文利用 Sysbench 性能测试工具，调研基于【负载均衡 + ProxySQL Cluster + MySQL MGR 的读写分离架构】能否有效利用横向扩展的 MySQL 实例的读能力，并最终提高应用系统 QPS。
Mysql在写入压力很大，怎么办？ 高并发下的性能最大的问题，大都在数据库，以前我们做二十万超级群，mongodb每个月都会出事故. 我们聊聊,高并发下如何缓解mysql的压力 ⚠️：mysql是锁锁表不锁库，sqlite是锁库不锁表 环境准备 Mac mysql navicat wrk压测工具 node.js环境 下载wrk brew install wrk 如果这里卡住，可以调整 `替换brew.git: cd "$(brew --repo)" git remote set-url origin htt
出自percona公司，是一款多线程系统压测工具，可以根据影响数据库服务器性能的各种因素来评估系统的性能。例如，可以用来测试文件IO，操作系统调度器，内存分配和传输速度，POSIX线程以及数据库服务器等。sysbench支持Lua脚本语言，Lua对各种测试场景的设置可以非常灵活。sysbench支持MySQL，操作系统和硬件的测试。
作者介绍： 赵守斌，十年银行业数据库管理经验，熟悉各种Oracle数据库系统方案，对MySQL开源数据库也有涉猎。目前牵头负责恒丰银行数据库管理和各类数据库服务化平台建设。 背景 Background 很多关注数据库技术的IT人士可能记不住去年双十二都剁手买了什么东西，但是一定会有人对当时一篇“Galera将死——MySQL Group Replication正式发布”的文章还有印象。 长期以来MySQL官方都缺少原生的MySQL集群多活方案，所以也给第三方公司提供了发展的机会。Galera就是其中的
作者介绍： 赵守斌，十年银行业数据库管理经验，熟悉各种Oracle数据库系统方案，对MySQL开源数据库也有涉猎。目前牵头负责恒丰银行数据库管理和各类数据库服务化平台建设。 背景 Backgroun
公司最近大量的MYSQL要上线，不做压力测试时说不过去的，所以拿出一直使用的sysbench 来压测一下MYSQL ，问题就开始了，最早用的是0.5 version.
本文是一篇译文，介绍 Percona 的工程师对 ScaleFlux 的性能压测报告。
前段时间，测试了国内主要云原生数据库PolarDB、TDSQL-C、GaussDB的性能，参考：《再测云原生数据库性能》。在上次测试结果中，由于地域版本差异，腾讯云的TDSQL-C并没有表现出“重磅升级”的效果，现在两个月过去了，我们再来重测TDSQL-C。先说结论：
MIUI 是小米公司旗下基于 Android 系统深度优化、定制、开发的第三方手机操作系统，也是小米的第一个产品。MIUI 在 Android 系统基础上，针对中国用户进行了深度定制，在此之上孕育出了一系列的应用，比如主题商店、小米音乐、应用商店、小米阅读等。
爱可生 DBA 团队成员，擅长故障分析、性能优化，个人博客：https://www.jianshu.com/u/a95ec11f67a8，欢迎讨论。
最近作者有一个针对ScaleFlux 的产品也叫做 CSD 2000 进行压测的机会. 本文中作者将介绍使用 Intel SSD 和ScaleFlux 存储设备进行压测的对比结果。
有赞的基础架构使用了UCloud的基础服务，我们有相当比例的数据库是UCloud的RDS(一部分使用云RDS，一部分使用购买他们的物理服务器自建数据库)。
在云上环境进行压测的场景，主要有单链路和全链路压测。其中，单链路压测用于业务添加新的接入模块和单业务架构迁移后稳定性评估；全链路压测则更多是在割接上云前演练，大促前容量评估等几个场景。
最近一直在做性能压测相关的事情，有公众号的读者朋友咨询有赞的数据库服务器有没有开启huge page，我听说过huge page会对性能有所提升，本文就一探究竟。对过程没有兴趣的可以直接看结论。
TiDB正式线上前，总是要对TiDB做个压测来为后续的业务接入做评估依旧；本次针对TiDB 5.0以及MySQL 8.0在同等规格配置下，性能做一个对比，尽管来说这么对比，可比性不是很强，但是起码能为后续业务的接入以及上线有一个理论依旧；
SysBench是一个跨平台且支持多线程的模块化基准测试工具，用于评估系统在运行高负载的数据库时相关核心参数的性能表现。可绕过复杂的数据库基准设置，甚至在没有安装数据库的前提下，快速了解数据库系统的性能。
在基于微服务的分布式应用架构下，业务需要的多个服务是通过一系列的服务、中间件的调用来完成，所以单个服务的压力测试已无法代表真实场景。在测试环境中，如果重新搭建一整套与生产环境类似的压测环境，成本过高，并且往往无法模拟线上环境的复杂度以及流量。因此，业内通常选择全链路压测的方式，即在生产环境进行压测，这样所获得的测试结果能够准确地反应系统真实容量和性能水平。
作为一个 MySQL DBA，查看分析 binlog 是日常工作的一部分。不知道你是否遇到过这样的需求：查询一个时间段内各个表的 dml 统计情况。但，如果 binlog 文件很多呢？又或者负责的业务线比较多，有多个业务都有这种需求呢？
在图解系列中, 我们介绍过组提交的概念 (MySQL 组提交), 这次我们通过实验来观察其作用
最近几年，云数据库市场日趋繁荣，进入百花齐放、百家争鸣的时代，头部云计算厂商相继推出了自己的数据库产品，特别是亚马逊的Aurora、阿里云的PolarDB、华为云的GaussDB等等。
压测之前要有压测方案（如压测接口、并发量、压测策略(突发、逐步加压、并发量)、压测指标(机器负载、QPS/TPS、响应时间)），之后要产出压测报告（压测方案、机器负载、QPS/TPS、响应时间(平均、最小、最大)、成功率、相关参数 等），最后根据压测报告分析的结果进行系统优化和容灾。
这几年，Serverless数据库大火，被业内称为数据库的下一代变革性技术，是云原生数据库发展的必然结果。作为早在2020年就于国内率先推出Serverless数据库的腾讯云，近年来不断在Serverless数据库领域深耕探索，今年更是推出预付费资源类型资源包，Serverless集群挂载只读实例等一系列更新，为用户的降本增效以及国内云原生技术普惠提供了一份自己的答卷。
作为一名测试行业的老兵，17年开始接触性能测试，从此就迷失在跳动的数据的世界里，距今为止已有5个年头了。
window安装可能要依赖它的子系统才方便安装，或者换成其他的压测工具例如JMeter。
Alex，专注于云计算领域数年，目前主要从事容器云平台的建设，推进各类基础设施服务的云原生化。
TPC-C是专门测试OLTP系统的规范，tpcc-mysql是percona基于TPC-C(下面简写成TPCC)衍生出来的产品，专用于MySQL基准测试。
TiDB 6.0 版本针对悲观事务引入了内存悲观锁的优化，带来了明显的性能提升。本文将从最初的乐观事务到悲观事务入手；介绍 6.0 版本针对悲观锁进行优化的原理，并结合压测数据验证其带来的性能提升。
ddcw_tool地址: https://github.com/ddcw/ddcw/blob/master/python/ddcw_tool.py
近日，腾讯云MySQL发布新架构，在基础硬件能力、自研内核及外部网络延迟等方面进行了全面升级。 在探究新版本实际性能的过程中，测试人员通过基准测试工具SysBench以及全仿真业务生产环境，分别针对只写、只读以及混合读写场景进行性能测试。其结果显示，新架构下的云数据库MySQL在性能上比原有架构提升20%。此外，通过TXSQL内核的更新，也为企业提供了更多实用的能力。 本次发布的云数据库MySQL新架构搭载最新的腾讯自研数据库内核TXSQL，不仅提供了如Parallel DDL、缓存快照主从同步等性能增强
其中值得关注的是用一台zuul网关节点和一个业务节点压测空接口，发现一个有意思的现象：
本篇使用tpcc-mysql压测工具对实验环境的三节点Galera集群进行一系列性能测试。
今天是中秋节放假前的最后一天，今天给大家带来假期前的最后一篇技术文，这也是我对MySQL使用UUID做主键与int数字做主键做的性能压测。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
