weixin_43997319的博客

对于秒杀类的场景，我们前期一定是做好了系统预热的工作的，在预热之后，线程突增产生的压力，也是在可处理范围的。因为响应时间增加了，TPS 增加得却没有那么多，到第三个阶梯时，显然增加的 TPS 更少了，响应时间也在不断地增加，所以，性能瓶颈在加剧，越往后就越明显。显然，这是一个阶梯式增加的场景，非常好。这就是性能衰减的过程（题外话，在上图中，其实还有一个问题，就是在红线前面，性能在上升的过程中有几次抖动，这个抖动到后面变大了，也变频繁了，如果这是必然出现的抖动，那也是配置问题，希望你注意到这一点）。.....

导读：在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。SQL优化一般步骤1、通过慢查日志等定位那些执行效率较低的SQL语句2、explain 分析SQL的执行计划需要重点关注type、rows、filtered、extra。type由上至下，效率越来越高ALL 全表扫描index 索引全扫描range 索引范围扫描，常用语...

上面的这条 sql phone 字段类型是 字符串类型的，但是没有使用 '13088772233 ', SQL 就全表扫描了，所以字符串索引要使用 ‘’解决方式是什么呢，可以提前计算好条件，不要使用索引，或者可以使用其他的 sql 替换上面的，比如，上面的sql 可以使用 like 来代替。最左原则，就是要最左边的优先存在，我不在的话，你们自己就玩不动了，除非你自己单独创立一个索引，下面这几条 SQL 就可以走索引执行。使用 or 查询部分字段没有使用索引。or 查询部分字段没有使用索引。

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。2.应尽量避免在 where 子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。3.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：..

一、背景我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。例如 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果； 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱； 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的； 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题等等很多重要的情况都需要幂等的特性来支持。 二、幂等性概念幂等（idempotent

一、Kafka集群部署架构为了让读者能与小编在后续的问题分析中有更好的共鸣，小编先与各位读者朋友对齐一下我们 Kafka 集群的部署架构及服务接入Kafka集群的流程。为了避免超大集群我们按照业务维度将整个每天负责十万亿级消息的 Kafka 集群拆分成了多个 Kafka 集群。拆分粒度太粗会导致单一集群过大，容易由于流量突变、资源隔离、限速等原因导致集群稳定性和可用性受到影响，拆分粒度太细又会因为集群太多不易维护，集群内资源较少应对突发情况的抗风险能力较弱。由于 Kafka 数...

背景我负责的系统在去年初就完成了功能上的建设，然后开始进入到推广阶段。随着推广的逐步深入，收到了很多好评的同时也收到了很多对性能的吐槽。刚刚收到吐槽的时候，我们的心情是这样的：当越来越多对性能的吐槽反馈到我们这里的时候，我们意识到，接口性能的问题的优先级必须提高了。然后我们就跟踪了 1 周的接口性能监控，这个时候我们的心情是这样的：有 20 多个慢接口，5 个接口响应时间超过 5s，1 个超过 10s，其余的都在 2s 以上，稳定性不足 99.8%。作为一个优

背景最近频繁出现慢SQL告警，执行时间最长的竟然高达5分钟。导出日志后分析，主要原因竟然是没有命中索引和没有分页处理。其实这是非常低级的错误，我不禁后背一凉，团队成员的技术水平亟待提高啊。改造这些SQL的过程中，总结了一些经验分享给大家，如果有错误欢迎批评指正。MySQL性能最大数据量抛开数据量和并发数，谈性能都是耍流氓。MySQL没有限制单表最大记录数，它取决于操作系统对文件大小的限制。文件系统 单文件大小限制 FAT32 最大4G NTFS 最大64..

1前言在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。2SQL优化一般步骤1、通过慢查日志等定位那些执行效率较低的SQL语句2、explain 分析SQL的执行计划需要重点关注type、rows、filtered、extra。type由上至下，效率越来越高 ALL 全表扫描 index..

毫不夸张地说，咱们后端工程师，无论在哪家公司，呆在哪个团队，做哪个系统，遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套成熟的方法论，能让大家快速、准确的去选择出合适的优化方案，我相信能够快速准备解决咱们日常遇到的80%-90%的性能问题。从解决问题的角度出发，我们得先了解到问题的原因；其次我们得有一套思考、判断问题的流程方式，让我们合理的站在哪个层面选择方案；最后从众多的方案里面选择一个适合的方案进行解决问题，找到一个合适的方案的前提，是我们自己对各种方案之间的优缺点、场景有足够的了

双击jmeter.bat时无法正常打开，报错：解决办法：1、在任意编辑器中打开jmeter.bat2、将set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m改成set HEAP=-Xms256m -Xmx256m -XX:MaxMetaspaceSize=256m3、保存，重新打开JMeter即可。...

本章节主要给大家分享性能测试面试题以及答案的第一部分内容，下一章继续更新性能测试面试题以及答案的第二部分。一、常见的性能测试有哪些分类常见的性能测试分类包括：1、负载试验2、压力测试3、可靠性试验4、容量测试5、可扩展性测试二、用户面临常见的性能问题有哪些常见的性能问题包括：1、加载时间更长;2、响应时间很长3、可扩展性差4、瓶颈(编码错误或硬件问题)三、性能测试流程性能测试流程通常包括以下步骤：第一步：性能测试分析第二步：测试构建第三

原因match NO.（0 for random）这里没有选择正则匹配规则

在日常工作中，我们会有时会开慢查询去记录一些执行时间比较久的SQL语句，找出这些SQL语句并不意味着完事了，些时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描，这都可以通过explain命令来查看。所以我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。-- 实际SQL，查找用户名为Jefabc的员工select * from emp

打开工具选择Options->Look and Fell->选择自己喜欢的背景色即可

1.设置线程组以及线程数2.简单控制器：规范线程3.CSV data set config:参数化配置组件数据文件：4.HTTP 信息头管理器5.仅一次控制器：控制当前线程只运行一次6.注册接口 ：此处账号 密码用到 随机数 md5加密 时间戳 函数，需要另外安装插件 略7.正则提取器8.响应断言 例：响应代码9.循环控制器：控制当前线程循环次数 即在原线程数设置上再乘以倍数10.synchronizi...

首先根据报错信息去启动文件内搜索，查看是否是jmeter.bat内部配置，查找set HEAP参数

1、在线程组中添加两个JDBC Request取样器,一个用于读取数据表中的数据,一个查询出表的总数据行数,用于循环控制器的循环次数2.添加循环控制器和计数器,添加计数器是因为查询结果中有多条数据,需要循环读取数据,循环控制器的循环次数为${countsku_1} (填写${ countsku}未成功).计数器配置如下根据调试取样器来查看取最大值是否正确3嵌套变量取值需要用到__V函数生成特定变量.在Tools中打开函数助手对话框,选择功能函数__V,表达式中输入${ ...

​当察看结果树的响应数据出现中文乱码时，在Jmeter安装目录下 bin/jmeter.properties中，一般用notepad打开。查找到sampleresult.default.encoding=ISO-8859-1，将ISO-8859-1更改为UTF-8，即sampleresult.default.encoding=UTF-8。​