目录一、性能测试的指标1、并发量2、响应时间3、错误率4、吞吐量5、资源使用率二、压测全流程三、其他注意点1、并发和吞吐量的关系2、并发和线程的关系四、调优及分布式集群压测待仔细学习1.线程数量超过单机承载能力时的解决方案2. 如何搭建分布式集群3. 实施集群压测及监控4. 处理集群中单台施压机报错的情况5. 长时间压测10小时的注意事项6. 处理混合场景用户思考时间及多个服务同时压测7. 开发压测监控大屏8. 汇总多个测试报告9. 监控服务器的 CPU、内存、磁盘10. 监控 Java 程序、Nginx、MySQL 数据库及 JVM 指标11. 性能分析及测试结论12. 区分压测问题与程序问题13. 内存溢出与性能问题标注14. 与 BI 项目的关联四、调优待仔细学习1. 缓存调优2. 集群调优3. MQ消息队列中间件调优4. 分布式微服务全链路压测五、连接数据库进行数据库压测待仔细学习1、步骤2、性能测试指标3.性能瓶颈发现方法* *#### 一、性能测试的指标##### 1、并发量定义描述一个系统所面临的压力服务器收到多少请求多少/秒 * 用的人多服务器收到请求多并发量就高。 * 用来描述场景 ##### 2、响应时间* 定义请求开始到获取结果的时长毫秒 1000ms1s * 直观反映了用户体验 * 统计方式平均响应时间 按响应时间分布 90% 95% 99% * 平均响应时间是对所有请求的响应时间取平均值代表整体性能的一个平均水平。 百分位数90%、95%、99% * 90%百分位数表示90%的请求响应时间都小于这个值也就是说有10%的请求响应时间是比这个值更长的。 * 95%百分位数表示95%的请求响应时间都小于这个值也就是说有5%的请求响应时间比这个值更长。 * 99%百分位数表示99%的请求响应时间都小于这个值也就是说有1%的请求响应时间比这个值更长。 ##### 3、错误率* 定义高并发海量请求场景系统出错误的比例。 错误率出错请求数量/整体请求数量 ##### 4、吞吐量* 定义服务器1秒内处理了多少请求 * 吞吐量和并发量的区别并发量是服务器收到请求吞吐量是服务器处理请求 * 细分概念 * QPS (Queries Per Second)QPS 指的是每秒能够处理的查询数量通常用于描述Web服务**或数据库在一定时间内处理请求的能力。 * TPS (Transactions Per Second)TPS 指的是每秒能够处理的事务数量这里的事务通常指的是一系列逻辑上的操作这些操作可能包含多个查询、插入、更新等。一个事务需要满足ACID属性原子性、一致性、隔离性、持久性。 ##### 5、资源使用率* 定义程序在测压中服务器资源的占用情况 * 程序运行代码需要占用服务器资源CPU/内存、磁盘、网络…这个是网络的指标 不是性能测试的指标1、带宽定义网络吞吐量系统或网络在单位时间内能够传输的数据量 * 单位比特每秒bps_为单位常见的单位有_10mb/s兆比特每秒2、时延#### 二、压测全流程(压力测试 及 压力测试前的接口测试 详细请看另一个文章)1. 压测场景分析 2. 在做性能测试之前先做接口测试 3. 收集性能指标 4. 分析性能数据 5. 梳理性能报告 #### 三、其他注意点##### 1、并发和吞吐量的关系并发请求发送给服务器的请求数量 * 吞吐量服务器每秒能处理的请求数量 (1) 先有并发再有吞吐量现有请求再有处理。(2) 并发量吞吐量##### 2、并发和线程的关系1并发量 不等于 线程数有时候 一个线程 一秒钟 能产生多次请求 * 有时候 一个线程 一秒钟 不能完成一次请求 2线程数量并发量*最大响应时间秒#### 四、调优及分布式集群压测待仔细学习性能测试需要剥夺业务层的干扰有时候也需要对中间件直接压测查看其性能##### 1.线程数量超过单机承载能力时的解决方案当单台运行 JMeter 的机器无法再增加线程数量时可以采用分布式集群的方式通过多台施压机JMeter Server共同承担压测任务。##### 2. 如何搭建分布式集群1分布式集群搭建步骤如下1.准备多台施压机确保所有施压机和控制机JMeter Controller在同一网络中能够相互通信。 2.配置 JMeter* 在所有施压机上安装与控制机相同版本的 JMeter。 * 修改 jmeter.properties 文件确保 remote_hosts 配置项包含所有施压机的 IP 地址。例如 remote_hosts192.168.1.2,192.168.1.3,192.168.1.4 3.启动 JMeter Server* 在每台施压机上通过命令行启动 JMeter Server jmeter-server 4.启动测试* 在控制机上打开测试计划选择Run Remote Start All或选择特定的施压机启动测试。 ##### 3. 实施集群压测及监控集群实施步骤**测试计划设计确保测试计划是分布式友好的例如避免使用非线程安全的元素。 *同步资源所有施压机应使用相同的测试脚本和资源文件。 *启动测试通过控制机统一启动所有施压机的测试。监控压测情况*实时监控工具使用 JMeter 自带的监听器或更高级的工具如 Grafana 与 InfluxDB进行实时监控。 *集中监控平台可以开发一个监控大屏将各施压机的性能指标汇总展示。 ##### 4. 处理集群中单台施压机报错的情况应对策略1.自动化监控与报警实时监控每台施压机的状态若发现某台施压机报错或宕机立即触发报警。 2.自动恢复机制配置自动重启脚本确保施压机故障后能自动重启 JMeter Server。 3.测试任务再分配如果施压机长时间故障可以手动或自动将其负载转移到其他施压机。 ##### 5. 长时间压测10小时的注意事项关键点*资源稳定性确保施压机和被测系统在长时间压测下资源不泄漏如内存、文件句柄。 *断点续测设计测试计划时考虑断点续测机制以防测试中断后能够恢复。 *日志管理合理配置日志级别避免长时间压测产生过多日志影响系统性能。 *定期检查在压测过程中定期检查施压机和被测系统的性能指标及时发现潜在问题。 ##### 6. 处理混合场景用户思考时间及多个服务同时压测实现方法*用户思考时间在 JMeter 中使用Timers定时器元素如Gaussian Random Timer或Constant Timer模拟用户思考时间。 *多个服务压测在测试计划中设计多线程组每个线程组针对不同的服务进行压测或在同一线程组中配置不同的请求确保多个服务同时承受压力。 *逻辑控制使用Controllers控制器元素如Transaction Controller或Module Controller管理复杂的测试逻辑。 ##### 7. 开发压测监控大屏监控大屏开发步骤1. 数据收集 * 使用JMeter Backend Listener将性能数据发送到时序数据库如InfluxDB。 * 配置监控工具如Grafana连接 InfluxDB 以实时获取数据。 2. 展示内容 *施压机性能指标CPU、内存、磁盘使用率。 *被测服务指标响应时间、吞吐量、错误率。 *应用层指标JVM 内存使用、垃圾回收情况、数据库性能指标如 MySQL 的连接数、查询性能。 3. 可视化设计 * 使用 Grafana 创建仪表板将各类指标以图表、仪表盘等形式展示。 * 设置阈值和警报规则实时标注异常情况。 ##### 8. 汇总多个测试报告实现方法* 集中化报告生成 * 使用JMeter Plugins中的Aggregate Report或Summary Report进行数据汇总。 * 将各施压机的测试结果通过脚本或工具如JMeter Dashboard汇总到统一的报告中。 * 自动化脚本 * 编写脚本在测试结束后自动收集各施压机的结果文件如 JTL 文件并进行汇总处理。 ##### 9. 监控服务器的 CPU、内存、磁盘监控工具选择*Prometheus Grafana通过Node Exporter采集服务器的 CPU、内存、磁盘等指标并在 Grafana 中展示。 *其他监控工具如Zabbix、Nagios等也可以实现类似的监控功能。实施步骤1. 在每台服务器上安装监控代理如 Node Exporter。 2. 配置 Prometheus 抓取各服务器的指标。 3. 在 Grafana 中创建仪表板实时展示各项资源使用情况。 ##### 10. 监控 Java 程序、Nginx、MySQL 数据库及 JVM 指标Java 程序JVM监控* JMXJava Management Extensions * 启用 JVM 的 JMX 功能允许远程监控。 * 监控工具 * 使用Prometheus JMX Exporter将 JVM 指标导出到 Prometheus。 * 关键指标 *垃圾回收GCGC 次数、GC 时间。 *内存使用新生代Young Generation、老年代Old Generation、堆外内存。 *线程数活动线程数。Nginx 监控* 状态模块 * 启用 Nginx 的Stub Status Module获取当前连接数、请求数等信息。 * 监控工具 * 使用Prometheus Nginx Exporter获取并导出 Nginx 指标。 * 关键指标 * 活动连接数、总请求数、每秒请求数、响应时间。MySQL 数据库监控* 性能指标 *连接数当前活动连接数、最大连接数。 *查询性能每秒查询数、慢查询数。 *资源使用CPU、内存、磁盘 I/O。 * 监控工具 * 使用Prometheus MySQL Exporter或Percona Monitoring and Management (PMM)进行监控。实施步骤1. 在 Java 应用、Nginx、MySQL 服务器上安装相应的监控 Exporter。 2. 配置 Prometheus 抓取这些 Exporter 的指标。 3. 在 Grafana 中创建综合仪表板展示所有关键指标。 ##### 11. 性能分析及测试结论性能分析步骤1.数据汇总收集所有施压机和被测系统的性能数据。 2.指标对比将实际指标与预设的性能指标如响应时间、吞吐量进行对比。 3.瓶颈识别通过分析 CPU、内存、磁盘、网络等资源的使用情况识别性能瓶颈所在。 4.异常检测标注在压测过程中出现的任何异常情况如响应时间飙升、错误率增加、资源耗尽等。 5.结论判定*测试通过所有关键指标在预期范围内系统稳定。 *测试不通过某些关键指标超出预期范围存在性能问题。 6.问题定位进一步分析是测试本身的问题如施压机资源不足还是被测系统的问题如内存泄漏、数据库瓶颈。 ##### 12. 区分压测问题与程序问题诊断步骤1. 施压机健康检查 * 确认所有施压机的 CPU、内存、磁盘等资源未达到极限。 * 确保网络带宽充足无网络瓶颈。 2. 被测系统监控 * 检查被测系统的资源使用情况如 CPU 是否达到 100%、内存是否溢出。 * 通过 JVM 指标分析是否存在内存泄漏或频繁的垃圾回收。 3. 日志分析 * 查看被测系统的日志检查是否有异常错误如 OutOfMemoryError。 * 查看 JMeter 的测试日志确认是否有请求超时或连接失败等错误。 4. 错误分类 *压测问题施压机资源不足、网络不稳定、JMeter 配置错误等。 *程序问题被测系统存在性能瓶颈、内存泄漏、数据库慢查询等。 5. 验证与复现 * 如果怀疑施压机问题可以在另一台施压机上复现相同的测试看问题是否依旧存在。 * 如果问题在多台施压机上均存在倾向于被测系统的问题。 ##### 13. 内存溢出与性能问题标注实施方法*自动标注在监控大屏上设置阈值当某项指标如 CPU 使用率、内存使用量超过设定值时自动高亮或标注异常。 *日志关联将性能指标异常与应用日志中的错误关联起来帮助快速定位问题原因。 *报告生成在测试报告中详细记录所有异常情况并说明其可能的原因及影响。 ##### 14. 与 BI 项目的关联整合 BI 项目的建议*数据汇总与分析将压测数据汇总到 BI 平台如 Tableau、Power BI进行更深入的数据分析与可视化。 *自动化报告利用 BI 工具自动生成定期的性能测试报告方便团队查看和决策。 *交互式大屏在 BI 平台上创建交互式仪表板实时展示压测与系统性能指标支持多维度数据分析。 #### 四、调优待仔细学习在性能测试和系统优化过程中调优是确保系统在高负载下依然稳定、高效运行的关键步骤。以下是关于缓存、集群、MQ 中间件调优以及分布式微服务全链路压测的详细解释和优化建议。* *##### 1. 缓存调优1.1 什么是缓存缓存是一种存储机制用于临时存储经常访问的数据以减少数据获取的延迟和降低数据库或后端服务的负载。缓存可以存在于客户端如浏览器缓存、服务器端如内存缓存或分布式缓存系统中。1.2 缓存的类型本地缓存存储在应用程序所在的同一台机器上如使用 Java 的ConcurrentHashMap、Caffeine、Guava 等。 *分布式缓存存储在独立的缓存服务器上支持多节点访问和高可用性如Redis、Memcached。 *浏览器缓存存储在客户端浏览器中通过设置 HTTP 头如Cache-Control进行管理。1.3 缓存调优策略*缓存淘汰策略*LRULeast Recently Used移除最近最少使用的项。 *LFULeast Frequently Used移除使用频率最低的项。 *FIFOFirst In First Out按照进入缓存的顺序移除项。 *缓存一致性*数据失效设置合理的 TTLTime-To-Live确保缓存数据不过期。 *缓存更新使用发布/订阅机制或消息队列通知缓存更新。 *缓存预热在系统启动或部署后提前将常用数据加载到缓存中减少首次访问的延迟。 *分片与分区对于大规模缓存进行分片或分区管理提高缓存的扩展性和访问效率。1.4 缓存监控与优化*命中率监控通过监控缓存命中率评估缓存的有效性命中率低可能需要调整缓存策略或增加缓存容量。 *内存使用监控确保缓存服务器有足够的内存避免频繁的垃圾回收或内存溢出。 *延迟监控监控缓存访问的响应时间确保缓存系统本身不会成为性能瓶颈。 * *##### 2. 集群调优2.1 什么是集群集群是由多台计算机节点通过网络连接组成的一个统一系统旨在通过分布式计算和资源共享提高系统的可靠性、可扩展性和性能。常见的集群类型包括负载均衡集群、高可用集群和计算集群。2.2 集群的组成控制节点Master负责管理和协调集群中的其他节点分发任务和监控集群状态。 *工作节点Worker执行具体的计算任务或服务请求。 *负载均衡器分发客户端请求到不同的工作节点确保负载均衡和高可用性。2.3 集群调优策略* 负载均衡优化 *均衡算法选择使用合适的负载均衡算法如轮询Round Robin、最少连接Least Connections、哈希Hash-based。 *会话保持对于需要会话保持的应用配置负载均衡器支持粘性会话或使用分布式会话管理。 * 资源分配与管理 *自动扩展根据负载情况自动增加或减少工作节点使用 Kubernetes、Docker Swarm 等容器编排工具实现弹性伸缩。 *资源限制设置每个节点的 CPU、内存、存储等资源限制防止单个节点资源被过度占用。 * 高可用性配置 *冗余设计部署多个控制节点和负载均衡器避免单点故障。 *故障转移配置自动故障转移机制确保节点故障时请求能自动转移到其他正常节点。 * 网络优化 *网络带宽确保集群内部网络带宽充足避免网络瓶颈。 *延迟优化使用低延迟的网络设备和协议减少节点间通信的延迟。2.4 集群监控与优化*性能监控监控各节点的 CPU、内存、磁盘和网络使用情况确保资源均衡。 *健康检查定期检查节点的健康状态及时发现并处理故障节点。 *日志管理集中收集和分析集群日志排查性能问题和故障原因。 * *##### 3. MQ消息队列中间件调优3.1 什么是消息队列MQ中间件消息队列是一种异步通信机制允许不同系统或服务之间通过发送和接收消息进行通信。常见的 MQ 中间件有RabbitMQ、Apache Kafka、ActiveMQ、RocketMQ等。3.2 消息队列的作用解耦系统使生产者和消费者独立运行降低系统耦合度。 *提高可靠性消息队列可以持久化消息确保消息不丢失。 *缓冲流量在高峰期消息队列可以缓冲大量请求平滑系统负载。 *异步处理提高系统响应速度适合处理耗时任务。3.3 MQ 中间件调优策略* 队列设计优化 *合理划分队列根据业务功能划分不同的队列避免单个队列过于繁忙。 *消息分区对于分布式 MQ如 Kafka合理设计分区数平衡负载和并行度。 * 生产者与消费者优化 *批量发送与接收使用批量操作减少网络开销提高吞吐量。 *并发处理增加消费者的并发数提升消息处理能力。 * 持久化与可靠性 *消息持久化配置合理的持久化策略确保消息不丢失但也要注意持久化带来的性能影响。 *确认机制配置合理的消息确认机制确保消息被成功消费。 * 性能参数调优 *内存与缓存调整 MQ 中间件的内存缓存大小提高消息处理速度。 *网络配置优化网络参数减少消息传输延迟。 * 监控与限流 *监控指标监控队列长度、消息吞吐量、延迟等指标及时发现和处理性能瓶颈。 *限流机制在高负载情况下使用限流策略防止 MQ 过载保护下游系统。3.4 MQ 中间件监控与优化*实时监控使用监控工具如 Prometheus Grafana监控 MQ 的运行状态和性能指标。 *日志分析分析 MQ 日志排查消息积压、消费失败等问题。 *故障恢复配置高可用架构如 MQ 集群和镜像队列确保消息服务的连续性。 * *##### 4. 分布式微服务全链路压测4.1 什么是分布式微服务分布式微服务架构将应用程序拆分为多个独立的服务每个服务负责特定的业务功能通过网络进行通信和协作。这样的架构具有高可扩展性、灵活性和容错性。4.2 全链路压测的概念全链路压测End-to-End Performance Testing是指对整个分布式微服务系统进行全面的性能测试模拟真实用户行为评估系统在高负载下的响应能力、稳定性和整体性能。全链路压测涵盖了从前端到后端所有服务的性能测试。4.3 全链路压测的关键要素用户行为模拟模拟真实用户的操作流程和使用习惯包括访问频率、并发数和思考时间。 *服务依赖分析识别和分析各微服务之间的依赖关系确保压测覆盖所有关键路径。 *性能指标监控监控各微服务的响应时间、吞吐量、错误率及系统资源使用情况。 *数据一致性确保在压测过程中数据的一致性和完整性不受影响。4.4 全链路压测的实施步骤1.测试计划设计*业务流程定义确定需要压测的业务流程编写详细的测试用例。 *并发用户数设定根据业务需求和预期负载确定并发用户数和测试持续时间。 *数据准备准备测试所需的输入数据和测试环境。 2.测试环境搭建*环境一致性确保测试环境与生产环境尽可能一致包括硬件配置、网络拓扑和服务版本。 *隔离测试环境使用独立的测试环境避免对生产环境造成影响。 3.测试工具配置*选择合适的测试工具使用 JMeter、Gatling、Locust 等性能测试工具进行压测。 *分布式测试配置配置分布式测试架构确保能够模拟大规模的并发用户。 4.执行压测*逐步加载采用逐步增加负载的方法观察系统在不同负载下的表现。 *全链路覆盖确保测试覆盖所有关键微服务和依赖组件避免遗漏关键路径。 5.监控与分析*实时监控使用监控工具如 Prometheus Grafana实时监控系统性能指标。 *日志分析收集并分析各微服务的日志识别性能瓶颈和错误。 *链路追踪使用分布式追踪工具如 Jaeger、Zipkin追踪请求在各微服务间的传播分析响应时间和瓶颈点。 6.结果评估与优化*性能报告生成汇总测试结果生成详细的性能报告。 *瓶颈定位与优化根据测试结果定位性能瓶颈进行针对性的优化。 *复测验证在优化后进行再次压测验证优化效果。4.5 分布式微服务全链路压测的优化建议*服务解耦与独立部署确保每个微服务独立部署减少服务间的耦合提高系统的可维护性和扩展性。 *容错与降级机制实现服务的容错和降级机制确保部分服务故障时系统整体仍能保持稳定运行。 *自动化测试与持续集成将全链路压测集成到 CI/CD 流程中确保每次代码变更后都进行性能验证。 *资源弹性管理使用容器化和编排工具如 Kubernetes实现资源的弹性管理动态调整服务实例数应对负载变化。 *安全性考虑在压测过程中确保数据的安全性和隐私保护避免敏感数据泄露。 #### 五、连接数据库进行数据库压测待仔细学习##### 1、步骤1. 下载JDBC驱动 * 获取所需的JDBC驱动JAR包并将其放入JMeter的指定目录下。 2. 配置JDBC原件 * 在JMeter中添加配置元件Config Element中的JDBC配置。 3. 连接数据库 * 配置并测试与目标数据库的连接确保连接正常。 4. 编写SQL操作 * 编写需要执行的SQL语句用于压测过程中模拟实际的数据库操作。 5. 设置线程属性 * 配置压测的线程属性包括线程数、持续时间和循环次数以模拟并发用户行为。 6. 执行数据库压测 * 启动压测监控测试过程中的各项性能指标。 ##### 2、性能测试指标1. 执行效率 * 定义评估数据库操作的整体性能和响应时间。 * 关注点查询执行时间、事务处理时间等。 2. 慢查询 * 定义执行时间超过预设阈值的SQL语句。 * 分析内容 * 哪些语句存在慢查询。 * 慢查询的原因如缺乏索引、复杂查询等。 3. 组件问题 * 定义数据库系统中各组件如缓冲池、查询优化器等可能存在的性能瓶颈。 * 分析内容 * 缓冲池使用情况。 * 查询优化器的效率。 4. 锁问题 * 定义多个事务同时访问同一数据时因锁机制导致的等待、阻塞或死锁。 * 分析内容 * 哪行代码出现锁的问题。 * 哪条语句导致锁。 * 哪张表存在锁的问题。 5. 缓冲区Buffer * 定义用于缓存数据和索引的内存区域如InnoDB缓冲池。 * 关注点缓冲池大小、命中率、读写次数等。 6. 表结构问题 * 定义数据库表设计不合理导致查询性能低下或存储空间浪费。 * 分析内容 * 表的大小和增长速度。 * 索引设计是否合理。 * 数据分布和访问模式。 7. 分库分表 * 水平分表Sharding * 定义将一张大表按照某个规则如ID范围、哈希值拆分为多个表每个表存储部分数据。 * 优点减少单表数据量提高查询性能便于水平扩展。 * 缺点增加查询复杂性需修改应用逻辑。 * 垂直分表 * 定义将表的不同列拆分为多个表每个表存储部分字段。 * 优点减少单表宽度提高查询效率分离热数据和冷数据。 * 缺点增加表之间的关联查询需维护多个表的完整性。 ##### 3.性能瓶颈发现方法在进行数据库压测后发现性能瓶颈并确定哪些SQL语句存在慢查询或锁问题是优化数据库性能的关键步骤一、启用并配置慢查询日志****1. 启用慢查询日志慢查询日志记录了执行时间超过指定阈值的SQL语句。通过分析这些日志可以识别出性能较差的查询。-- 启用慢查询日志SET GLOBAL slow_query_log ‘ON’;-- 设置慢查询时间阈值例如记录执行时间超过2秒的查询SET GLOBAL long_query_time 2;-- 可选记录未使用索引的查询SET GLOBAL log_queries_not_using_indexes ‘ON’;2. 配置慢查询日志文件路径在MySQL配置文件my.cnf或my.ini中设置慢查询日志文件路径和其他相关参数[mysqld]slow_query_log ONslow_query_log_file /var/log/mysql/slow-query.loglong_query_time 2log_queries_not_using_indexes ON3. 分析慢查询日志使用工具如 mysqldumpslow 或 pt-query-digest 来分析慢查询日志找出最频繁和耗时最长的查询。使用 mysqldumpslowmysqldumpslow -s t /var/log/mysql/slow-query.log# 使用 pt-query-digestpt-query-digest /var/log/mysql/slow-query.log二、使用 Performance Schema 进行深入分析****1. 启用 Performance Schema确保performance_schema已启用。在MySQL配置文件中[mysqld]performance_schema ON2. 查询慢查询和锁信息利用performance_schema提供的表格可以查询到详细的执行情况包括等待锁的信息。-- 查看慢查询SELECT EVENT_ID, SQL_TEXT, TIMER_WAIT, LOCK_TIME, ROWS_SENT, ROWS_EXAMINEDFROM performance_schema.events_statements_historyWHERE TIMER_WAIT 2000000000; – 时间单位为皮秒这里表示超过2秒-- 查看锁等待SELECT thd.PROCESSLIST_ID, thd.PROCESSLIST_USER, thd.PROCESSLIST_HOST, thd.PROCESSLIST_DB, thd.EVENT_NAME, thd.STATE, thd.SQL_TEXTFROM performance_schema.threads thdJOIN performance_schema.events_waits_current ewc ON thd.THREAD_ID ewc.THREAD_IDWHERE ewc.EVENT_NAME LIKE ‘wait/lock/%’;三、使用 EXPLAIN 分析查询计划对发现的慢查询使用EXPLAIN分析其执行计划找出查询的瓶颈如全表扫描、缺失索引等。EXPLAIN ANALYZESELECT * FROM your_table WHERE some_column ‘value’;关键指标*type访问类型尽量使用const、eq_ref或ref避免ALL全表扫描。 *key使用的索引确保查询使用了合适的索引。 *rows扫描的行数行数越少越好。 *Extra查看是否有Using temporary或Using filesort这可能影响性能。四、监控和分析锁问题****1. 查看当前锁情况SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_queryFROM information_schema.innodb_lock_waits wJOIN information_schema.innodb_trx b ON b.trx_id w.blocking_trx_idJOIN information_schema.innodb_trx r ON r.trx_id w.requesting_trx_id;**2. 使用SHOW ENGINE INNODB STATUS该命令提供了当前InnoDB引擎的详细状态包括锁等待信息。SHOW ENGINE INNODB STATUSG在输出中查找LATEST DETECTED DEADLOCK和TRANSACTIONS部分分析死锁和锁等待的详细信息包括涉及的SQL语句和表。五、结合压测工具的监控功能如果你使用的是JMeter等压测工具可以结合其监控插件或第三方监控工具如Prometheus、Grafana来实时监控数据库的性能指标。1. 设置JMeter监控使用JMeter的监听器Listener如JDBC Request、View Results Tree实时查看查询的响应时间和错误。 * 使用JMeter Plugins中的监控插件如PerfMon监控服务器的CPU、内存、磁盘I/O等指标关联到数据库性能问题。2. 使用第三方监控工具Percona Monitoring and Management (PMM)一个开源的监控解决方案专为MySQL设计提供实时查询分析和性能指标。 *Grafana Prometheus通过配置MySQL Exporter收集数据库的性能指标并在Grafana中可视化展示帮助识别性能瓶颈。 *六、优化发现的问题1. 优化慢查询添加或优化索引确保查询中使用的列有合适的索引。 *重写查询简化复杂的查询避免不必要的子查询和JOIN操作。 *分区表对于大表使用分区技术减少查询的扫描范围。2. 解决锁问题优化事务缩短事务的执行时间避免长时间持有锁。 *隔离级别调整在保证数据一致性的前提下适当降低事务隔离级别如从REPEATABLE READ调整为READ COMMITTED。 *索引优化确保查询使用索引减少锁的范围和数量。3. 缓冲池和表结构优化调整innodb_buffer_pool_size确保缓冲池足够大以容纳大部分活跃数据减少磁盘I/O。 * 分库分表 *水平分表将表的数据按某个键值分散到多个表中减小单表的数据量提升查询性能。 *垂直分表将表的不同列分散到多个表中减少每个表的宽度提升查询效率。七、持续监控和迭代优化性能优化是一个持续的过程应定期进行压测和监控及时发现和解决新的性能瓶颈。同时结合业务发展和数据增长动态调整数据库配置和架构确保系统始终保持高效稳定。 使用 pt-query-digest
目录一、性能测试的指标1、并发量2、响应时间3、错误率4、吞吐量5、资源使用率二、压测全流程三、其他注意点1、并发和吞吐量的关系2、并发和线程的关系四、调优及分布式集群压测待仔细学习1.线程数量超过单机承载能力时的解决方案2. 如何搭建分布式集群3. 实施集群压测及监控4. 处理集群中单台施压机报错的情况5. 长时间压测10小时的注意事项6. 处理混合场景用户思考时间及多个服务同时压测7. 开发压测监控大屏8. 汇总多个测试报告9. 监控服务器的 CPU、内存、磁盘10. 监控 Java 程序、Nginx、MySQL 数据库及 JVM 指标11. 性能分析及测试结论12. 区分压测问题与程序问题13. 内存溢出与性能问题标注14. 与 BI 项目的关联四、调优待仔细学习1. 缓存调优2. 集群调优3. MQ消息队列中间件调优4. 分布式微服务全链路压测五、连接数据库进行数据库压测待仔细学习1、步骤2、性能测试指标3.性能瓶颈发现方法* *#### 一、性能测试的指标##### 1、并发量定义描述一个系统所面临的压力服务器收到多少请求多少/秒 * 用的人多服务器收到请求多并发量就高。 * 用来描述场景 ##### 2、响应时间* 定义请求开始到获取结果的时长毫秒 1000ms1s * 直观反映了用户体验 * 统计方式平均响应时间 按响应时间分布 90% 95% 99% * 平均响应时间是对所有请求的响应时间取平均值代表整体性能的一个平均水平。 百分位数90%、95%、99% * 90%百分位数表示90%的请求响应时间都小于这个值也就是说有10%的请求响应时间是比这个值更长的。 * 95%百分位数表示95%的请求响应时间都小于这个值也就是说有5%的请求响应时间比这个值更长。 * 99%百分位数表示99%的请求响应时间都小于这个值也就是说有1%的请求响应时间比这个值更长。 ##### 3、错误率* 定义高并发海量请求场景系统出错误的比例。 错误率出错请求数量/整体请求数量 ##### 4、吞吐量* 定义服务器1秒内处理了多少请求 * 吞吐量和并发量的区别并发量是服务器收到请求吞吐量是服务器处理请求 * 细分概念 * QPS (Queries Per Second)QPS 指的是每秒能够处理的查询数量通常用于描述Web服务**或数据库在一定时间内处理请求的能力。 * TPS (Transactions Per Second)TPS 指的是每秒能够处理的事务数量这里的事务通常指的是一系列逻辑上的操作这些操作可能包含多个查询、插入、更新等。一个事务需要满足ACID属性原子性、一致性、隔离性、持久性。 ##### 5、资源使用率* 定义程序在测压中服务器资源的占用情况 * 程序运行代码需要占用服务器资源CPU/内存、磁盘、网络…这个是网络的指标 不是性能测试的指标1、带宽定义网络吞吐量系统或网络在单位时间内能够传输的数据量 * 单位比特每秒bps_为单位常见的单位有_10mb/s兆比特每秒2、时延#### 二、压测全流程(压力测试 及 压力测试前的接口测试 详细请看另一个文章)1. 压测场景分析 2. 在做性能测试之前先做接口测试 3. 收集性能指标 4. 分析性能数据 5. 梳理性能报告 #### 三、其他注意点##### 1、并发和吞吐量的关系并发请求发送给服务器的请求数量 * 吞吐量服务器每秒能处理的请求数量 (1) 先有并发再有吞吐量现有请求再有处理。(2) 并发量吞吐量##### 2、并发和线程的关系1并发量 不等于 线程数有时候 一个线程 一秒钟 能产生多次请求 * 有时候 一个线程 一秒钟 不能完成一次请求 2线程数量并发量*最大响应时间秒#### 四、调优及分布式集群压测待仔细学习性能测试需要剥夺业务层的干扰有时候也需要对中间件直接压测查看其性能##### 1.线程数量超过单机承载能力时的解决方案当单台运行 JMeter 的机器无法再增加线程数量时可以采用分布式集群的方式通过多台施压机JMeter Server共同承担压测任务。##### 2. 如何搭建分布式集群1分布式集群搭建步骤如下1.准备多台施压机确保所有施压机和控制机JMeter Controller在同一网络中能够相互通信。 2.配置 JMeter* 在所有施压机上安装与控制机相同版本的 JMeter。 * 修改 jmeter.properties 文件确保 remote_hosts 配置项包含所有施压机的 IP 地址。例如 remote_hosts192.168.1.2,192.168.1.3,192.168.1.4 3.启动 JMeter Server* 在每台施压机上通过命令行启动 JMeter Server jmeter-server 4.启动测试* 在控制机上打开测试计划选择Run Remote Start All或选择特定的施压机启动测试。 ##### 3. 实施集群压测及监控集群实施步骤**测试计划设计确保测试计划是分布式友好的例如避免使用非线程安全的元素。 *同步资源所有施压机应使用相同的测试脚本和资源文件。 *启动测试通过控制机统一启动所有施压机的测试。监控压测情况*实时监控工具使用 JMeter 自带的监听器或更高级的工具如 Grafana 与 InfluxDB进行实时监控。 *集中监控平台可以开发一个监控大屏将各施压机的性能指标汇总展示。 ##### 4. 处理集群中单台施压机报错的情况应对策略1.自动化监控与报警实时监控每台施压机的状态若发现某台施压机报错或宕机立即触发报警。 2.自动恢复机制配置自动重启脚本确保施压机故障后能自动重启 JMeter Server。 3.测试任务再分配如果施压机长时间故障可以手动或自动将其负载转移到其他施压机。 ##### 5. 长时间压测10小时的注意事项关键点*资源稳定性确保施压机和被测系统在长时间压测下资源不泄漏如内存、文件句柄。 *断点续测设计测试计划时考虑断点续测机制以防测试中断后能够恢复。 *日志管理合理配置日志级别避免长时间压测产生过多日志影响系统性能。 *定期检查在压测过程中定期检查施压机和被测系统的性能指标及时发现潜在问题。 ##### 6. 处理混合场景用户思考时间及多个服务同时压测实现方法*用户思考时间在 JMeter 中使用Timers定时器元素如Gaussian Random Timer或Constant Timer模拟用户思考时间。 *多个服务压测在测试计划中设计多线程组每个线程组针对不同的服务进行压测或在同一线程组中配置不同的请求确保多个服务同时承受压力。 *逻辑控制使用Controllers控制器元素如Transaction Controller或Module Controller管理复杂的测试逻辑。 ##### 7. 开发压测监控大屏监控大屏开发步骤1. 数据收集 * 使用JMeter Backend Listener将性能数据发送到时序数据库如InfluxDB。 * 配置监控工具如Grafana连接 InfluxDB 以实时获取数据。 2. 展示内容 *施压机性能指标CPU、内存、磁盘使用率。 *被测服务指标响应时间、吞吐量、错误率。 *应用层指标JVM 内存使用、垃圾回收情况、数据库性能指标如 MySQL 的连接数、查询性能。 3. 可视化设计 * 使用 Grafana 创建仪表板将各类指标以图表、仪表盘等形式展示。 * 设置阈值和警报规则实时标注异常情况。 ##### 8. 汇总多个测试报告实现方法* 集中化报告生成 * 使用JMeter Plugins中的Aggregate Report或Summary Report进行数据汇总。 * 将各施压机的测试结果通过脚本或工具如JMeter Dashboard汇总到统一的报告中。 * 自动化脚本 * 编写脚本在测试结束后自动收集各施压机的结果文件如 JTL 文件并进行汇总处理。 ##### 9. 监控服务器的 CPU、内存、磁盘监控工具选择*Prometheus Grafana通过Node Exporter采集服务器的 CPU、内存、磁盘等指标并在 Grafana 中展示。 *其他监控工具如Zabbix、Nagios等也可以实现类似的监控功能。实施步骤1. 在每台服务器上安装监控代理如 Node Exporter。 2. 配置 Prometheus 抓取各服务器的指标。 3. 在 Grafana 中创建仪表板实时展示各项资源使用情况。 ##### 10. 监控 Java 程序、Nginx、MySQL 数据库及 JVM 指标Java 程序JVM监控* JMXJava Management Extensions * 启用 JVM 的 JMX 功能允许远程监控。 * 监控工具 * 使用Prometheus JMX Exporter将 JVM 指标导出到 Prometheus。 * 关键指标 *垃圾回收GCGC 次数、GC 时间。 *内存使用新生代Young Generation、老年代Old Generation、堆外内存。 *线程数活动线程数。Nginx 监控* 状态模块 * 启用 Nginx 的Stub Status Module获取当前连接数、请求数等信息。 * 监控工具 * 使用Prometheus Nginx Exporter获取并导出 Nginx 指标。 * 关键指标 * 活动连接数、总请求数、每秒请求数、响应时间。MySQL 数据库监控* 性能指标 *连接数当前活动连接数、最大连接数。 *查询性能每秒查询数、慢查询数。 *资源使用CPU、内存、磁盘 I/O。 * 监控工具 * 使用Prometheus MySQL Exporter或Percona Monitoring and Management (PMM)进行监控。实施步骤1. 在 Java 应用、Nginx、MySQL 服务器上安装相应的监控 Exporter。 2. 配置 Prometheus 抓取这些 Exporter 的指标。 3. 在 Grafana 中创建综合仪表板展示所有关键指标。 ##### 11. 性能分析及测试结论性能分析步骤1.数据汇总收集所有施压机和被测系统的性能数据。 2.指标对比将实际指标与预设的性能指标如响应时间、吞吐量进行对比。 3.瓶颈识别通过分析 CPU、内存、磁盘、网络等资源的使用情况识别性能瓶颈所在。 4.异常检测标注在压测过程中出现的任何异常情况如响应时间飙升、错误率增加、资源耗尽等。 5.结论判定*测试通过所有关键指标在预期范围内系统稳定。 *测试不通过某些关键指标超出预期范围存在性能问题。 6.问题定位进一步分析是测试本身的问题如施压机资源不足还是被测系统的问题如内存泄漏、数据库瓶颈。 ##### 12. 区分压测问题与程序问题诊断步骤1. 施压机健康检查 * 确认所有施压机的 CPU、内存、磁盘等资源未达到极限。 * 确保网络带宽充足无网络瓶颈。 2. 被测系统监控 * 检查被测系统的资源使用情况如 CPU 是否达到 100%、内存是否溢出。 * 通过 JVM 指标分析是否存在内存泄漏或频繁的垃圾回收。 3. 日志分析 * 查看被测系统的日志检查是否有异常错误如 OutOfMemoryError。 * 查看 JMeter 的测试日志确认是否有请求超时或连接失败等错误。 4. 错误分类 *压测问题施压机资源不足、网络不稳定、JMeter 配置错误等。 *程序问题被测系统存在性能瓶颈、内存泄漏、数据库慢查询等。 5. 验证与复现 * 如果怀疑施压机问题可以在另一台施压机上复现相同的测试看问题是否依旧存在。 * 如果问题在多台施压机上均存在倾向于被测系统的问题。 ##### 13. 内存溢出与性能问题标注实施方法*自动标注在监控大屏上设置阈值当某项指标如 CPU 使用率、内存使用量超过设定值时自动高亮或标注异常。 *日志关联将性能指标异常与应用日志中的错误关联起来帮助快速定位问题原因。 *报告生成在测试报告中详细记录所有异常情况并说明其可能的原因及影响。 ##### 14. 与 BI 项目的关联整合 BI 项目的建议*数据汇总与分析将压测数据汇总到 BI 平台如 Tableau、Power BI进行更深入的数据分析与可视化。 *自动化报告利用 BI 工具自动生成定期的性能测试报告方便团队查看和决策。 *交互式大屏在 BI 平台上创建交互式仪表板实时展示压测与系统性能指标支持多维度数据分析。 #### 四、调优待仔细学习在性能测试和系统优化过程中调优是确保系统在高负载下依然稳定、高效运行的关键步骤。以下是关于缓存、集群、MQ 中间件调优以及分布式微服务全链路压测的详细解释和优化建议。* *##### 1. 缓存调优1.1 什么是缓存缓存是一种存储机制用于临时存储经常访问的数据以减少数据获取的延迟和降低数据库或后端服务的负载。缓存可以存在于客户端如浏览器缓存、服务器端如内存缓存或分布式缓存系统中。1.2 缓存的类型本地缓存存储在应用程序所在的同一台机器上如使用 Java 的ConcurrentHashMap、Caffeine、Guava 等。 *分布式缓存存储在独立的缓存服务器上支持多节点访问和高可用性如Redis、Memcached。 *浏览器缓存存储在客户端浏览器中通过设置 HTTP 头如Cache-Control进行管理。1.3 缓存调优策略*缓存淘汰策略*LRULeast Recently Used移除最近最少使用的项。 *LFULeast Frequently Used移除使用频率最低的项。 *FIFOFirst In First Out按照进入缓存的顺序移除项。 *缓存一致性*数据失效设置合理的 TTLTime-To-Live确保缓存数据不过期。 *缓存更新使用发布/订阅机制或消息队列通知缓存更新。 *缓存预热在系统启动或部署后提前将常用数据加载到缓存中减少首次访问的延迟。 *分片与分区对于大规模缓存进行分片或分区管理提高缓存的扩展性和访问效率。1.4 缓存监控与优化*命中率监控通过监控缓存命中率评估缓存的有效性命中率低可能需要调整缓存策略或增加缓存容量。 *内存使用监控确保缓存服务器有足够的内存避免频繁的垃圾回收或内存溢出。 *延迟监控监控缓存访问的响应时间确保缓存系统本身不会成为性能瓶颈。 * *##### 2. 集群调优2.1 什么是集群集群是由多台计算机节点通过网络连接组成的一个统一系统旨在通过分布式计算和资源共享提高系统的可靠性、可扩展性和性能。常见的集群类型包括负载均衡集群、高可用集群和计算集群。2.2 集群的组成控制节点Master负责管理和协调集群中的其他节点分发任务和监控集群状态。 *工作节点Worker执行具体的计算任务或服务请求。 *负载均衡器分发客户端请求到不同的工作节点确保负载均衡和高可用性。2.3 集群调优策略* 负载均衡优化 *均衡算法选择使用合适的负载均衡算法如轮询Round Robin、最少连接Least Connections、哈希Hash-based。 *会话保持对于需要会话保持的应用配置负载均衡器支持粘性会话或使用分布式会话管理。 * 资源分配与管理 *自动扩展根据负载情况自动增加或减少工作节点使用 Kubernetes、Docker Swarm 等容器编排工具实现弹性伸缩。 *资源限制设置每个节点的 CPU、内存、存储等资源限制防止单个节点资源被过度占用。 * 高可用性配置 *冗余设计部署多个控制节点和负载均衡器避免单点故障。 *故障转移配置自动故障转移机制确保节点故障时请求能自动转移到其他正常节点。 * 网络优化 *网络带宽确保集群内部网络带宽充足避免网络瓶颈。 *延迟优化使用低延迟的网络设备和协议减少节点间通信的延迟。2.4 集群监控与优化*性能监控监控各节点的 CPU、内存、磁盘和网络使用情况确保资源均衡。 *健康检查定期检查节点的健康状态及时发现并处理故障节点。 *日志管理集中收集和分析集群日志排查性能问题和故障原因。 * *##### 3. MQ消息队列中间件调优3.1 什么是消息队列MQ中间件消息队列是一种异步通信机制允许不同系统或服务之间通过发送和接收消息进行通信。常见的 MQ 中间件有RabbitMQ、Apache Kafka、ActiveMQ、RocketMQ等。3.2 消息队列的作用解耦系统使生产者和消费者独立运行降低系统耦合度。 *提高可靠性消息队列可以持久化消息确保消息不丢失。 *缓冲流量在高峰期消息队列可以缓冲大量请求平滑系统负载。 *异步处理提高系统响应速度适合处理耗时任务。3.3 MQ 中间件调优策略* 队列设计优化 *合理划分队列根据业务功能划分不同的队列避免单个队列过于繁忙。 *消息分区对于分布式 MQ如 Kafka合理设计分区数平衡负载和并行度。 * 生产者与消费者优化 *批量发送与接收使用批量操作减少网络开销提高吞吐量。 *并发处理增加消费者的并发数提升消息处理能力。 * 持久化与可靠性 *消息持久化配置合理的持久化策略确保消息不丢失但也要注意持久化带来的性能影响。 *确认机制配置合理的消息确认机制确保消息被成功消费。 * 性能参数调优 *内存与缓存调整 MQ 中间件的内存缓存大小提高消息处理速度。 *网络配置优化网络参数减少消息传输延迟。 * 监控与限流 *监控指标监控队列长度、消息吞吐量、延迟等指标及时发现和处理性能瓶颈。 *限流机制在高负载情况下使用限流策略防止 MQ 过载保护下游系统。3.4 MQ 中间件监控与优化*实时监控使用监控工具如 Prometheus Grafana监控 MQ 的运行状态和性能指标。 *日志分析分析 MQ 日志排查消息积压、消费失败等问题。 *故障恢复配置高可用架构如 MQ 集群和镜像队列确保消息服务的连续性。 * *##### 4. 分布式微服务全链路压测4.1 什么是分布式微服务分布式微服务架构将应用程序拆分为多个独立的服务每个服务负责特定的业务功能通过网络进行通信和协作。这样的架构具有高可扩展性、灵活性和容错性。4.2 全链路压测的概念全链路压测End-to-End Performance Testing是指对整个分布式微服务系统进行全面的性能测试模拟真实用户行为评估系统在高负载下的响应能力、稳定性和整体性能。全链路压测涵盖了从前端到后端所有服务的性能测试。4.3 全链路压测的关键要素用户行为模拟模拟真实用户的操作流程和使用习惯包括访问频率、并发数和思考时间。 *服务依赖分析识别和分析各微服务之间的依赖关系确保压测覆盖所有关键路径。 *性能指标监控监控各微服务的响应时间、吞吐量、错误率及系统资源使用情况。 *数据一致性确保在压测过程中数据的一致性和完整性不受影响。4.4 全链路压测的实施步骤1.测试计划设计*业务流程定义确定需要压测的业务流程编写详细的测试用例。 *并发用户数设定根据业务需求和预期负载确定并发用户数和测试持续时间。 *数据准备准备测试所需的输入数据和测试环境。 2.测试环境搭建*环境一致性确保测试环境与生产环境尽可能一致包括硬件配置、网络拓扑和服务版本。 *隔离测试环境使用独立的测试环境避免对生产环境造成影响。 3.测试工具配置*选择合适的测试工具使用 JMeter、Gatling、Locust 等性能测试工具进行压测。 *分布式测试配置配置分布式测试架构确保能够模拟大规模的并发用户。 4.执行压测*逐步加载采用逐步增加负载的方法观察系统在不同负载下的表现。 *全链路覆盖确保测试覆盖所有关键微服务和依赖组件避免遗漏关键路径。 5.监控与分析*实时监控使用监控工具如 Prometheus Grafana实时监控系统性能指标。 *日志分析收集并分析各微服务的日志识别性能瓶颈和错误。 *链路追踪使用分布式追踪工具如 Jaeger、Zipkin追踪请求在各微服务间的传播分析响应时间和瓶颈点。 6.结果评估与优化*性能报告生成汇总测试结果生成详细的性能报告。 *瓶颈定位与优化根据测试结果定位性能瓶颈进行针对性的优化。 *复测验证在优化后进行再次压测验证优化效果。4.5 分布式微服务全链路压测的优化建议*服务解耦与独立部署确保每个微服务独立部署减少服务间的耦合提高系统的可维护性和扩展性。 *容错与降级机制实现服务的容错和降级机制确保部分服务故障时系统整体仍能保持稳定运行。 *自动化测试与持续集成将全链路压测集成到 CI/CD 流程中确保每次代码变更后都进行性能验证。 *资源弹性管理使用容器化和编排工具如 Kubernetes实现资源的弹性管理动态调整服务实例数应对负载变化。 *安全性考虑在压测过程中确保数据的安全性和隐私保护避免敏感数据泄露。 #### 五、连接数据库进行数据库压测待仔细学习##### 1、步骤1. 下载JDBC驱动 * 获取所需的JDBC驱动JAR包并将其放入JMeter的指定目录下。 2. 配置JDBC原件 * 在JMeter中添加配置元件Config Element中的JDBC配置。 3. 连接数据库 * 配置并测试与目标数据库的连接确保连接正常。 4. 编写SQL操作 * 编写需要执行的SQL语句用于压测过程中模拟实际的数据库操作。 5. 设置线程属性 * 配置压测的线程属性包括线程数、持续时间和循环次数以模拟并发用户行为。 6. 执行数据库压测 * 启动压测监控测试过程中的各项性能指标。 ##### 2、性能测试指标1. 执行效率 * 定义评估数据库操作的整体性能和响应时间。 * 关注点查询执行时间、事务处理时间等。 2. 慢查询 * 定义执行时间超过预设阈值的SQL语句。 * 分析内容 * 哪些语句存在慢查询。 * 慢查询的原因如缺乏索引、复杂查询等。 3. 组件问题 * 定义数据库系统中各组件如缓冲池、查询优化器等可能存在的性能瓶颈。 * 分析内容 * 缓冲池使用情况。 * 查询优化器的效率。 4. 锁问题 * 定义多个事务同时访问同一数据时因锁机制导致的等待、阻塞或死锁。 * 分析内容 * 哪行代码出现锁的问题。 * 哪条语句导致锁。 * 哪张表存在锁的问题。 5. 缓冲区Buffer * 定义用于缓存数据和索引的内存区域如InnoDB缓冲池。 * 关注点缓冲池大小、命中率、读写次数等。 6. 表结构问题 * 定义数据库表设计不合理导致查询性能低下或存储空间浪费。 * 分析内容 * 表的大小和增长速度。 * 索引设计是否合理。 * 数据分布和访问模式。 7. 分库分表 * 水平分表Sharding * 定义将一张大表按照某个规则如ID范围、哈希值拆分为多个表每个表存储部分数据。 * 优点减少单表数据量提高查询性能便于水平扩展。 * 缺点增加查询复杂性需修改应用逻辑。 * 垂直分表 * 定义将表的不同列拆分为多个表每个表存储部分字段。 * 优点减少单表宽度提高查询效率分离热数据和冷数据。 * 缺点增加表之间的关联查询需维护多个表的完整性。 ##### 3.性能瓶颈发现方法在进行数据库压测后发现性能瓶颈并确定哪些SQL语句存在慢查询或锁问题是优化数据库性能的关键步骤一、启用并配置慢查询日志****1. 启用慢查询日志慢查询日志记录了执行时间超过指定阈值的SQL语句。通过分析这些日志可以识别出性能较差的查询。-- 启用慢查询日志SET GLOBAL slow_query_log ‘ON’;-- 设置慢查询时间阈值例如记录执行时间超过2秒的查询SET GLOBAL long_query_time 2;-- 可选记录未使用索引的查询SET GLOBAL log_queries_not_using_indexes ‘ON’;2. 配置慢查询日志文件路径在MySQL配置文件my.cnf或my.ini中设置慢查询日志文件路径和其他相关参数[mysqld]slow_query_log ONslow_query_log_file /var/log/mysql/slow-query.loglong_query_time 2log_queries_not_using_indexes ON3. 分析慢查询日志使用工具如 mysqldumpslow 或 pt-query-digest 来分析慢查询日志找出最频繁和耗时最长的查询。使用 mysqldumpslowmysqldumpslow -s t /var/log/mysql/slow-query.log# 使用 pt-query-digestpt-query-digest /var/log/mysql/slow-query.log二、使用 Performance Schema 进行深入分析****1. 启用 Performance Schema确保performance_schema已启用。在MySQL配置文件中[mysqld]performance_schema ON2. 查询慢查询和锁信息利用performance_schema提供的表格可以查询到详细的执行情况包括等待锁的信息。-- 查看慢查询SELECT EVENT_ID, SQL_TEXT, TIMER_WAIT, LOCK_TIME, ROWS_SENT, ROWS_EXAMINEDFROM performance_schema.events_statements_historyWHERE TIMER_WAIT 2000000000; – 时间单位为皮秒这里表示超过2秒-- 查看锁等待SELECT thd.PROCESSLIST_ID, thd.PROCESSLIST_USER, thd.PROCESSLIST_HOST, thd.PROCESSLIST_DB, thd.EVENT_NAME, thd.STATE, thd.SQL_TEXTFROM performance_schema.threads thdJOIN performance_schema.events_waits_current ewc ON thd.THREAD_ID ewc.THREAD_IDWHERE ewc.EVENT_NAME LIKE ‘wait/lock/%’;三、使用 EXPLAIN 分析查询计划对发现的慢查询使用EXPLAIN分析其执行计划找出查询的瓶颈如全表扫描、缺失索引等。EXPLAIN ANALYZESELECT * FROM your_table WHERE some_column ‘value’;关键指标*type访问类型尽量使用const、eq_ref或ref避免ALL全表扫描。 *key使用的索引确保查询使用了合适的索引。 *rows扫描的行数行数越少越好。 *Extra查看是否有Using temporary或Using filesort这可能影响性能。四、监控和分析锁问题****1. 查看当前锁情况SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_queryFROM information_schema.innodb_lock_waits wJOIN information_schema.innodb_trx b ON b.trx_id w.blocking_trx_idJOIN information_schema.innodb_trx r ON r.trx_id w.requesting_trx_id;**2. 使用SHOW ENGINE INNODB STATUS该命令提供了当前InnoDB引擎的详细状态包括锁等待信息。SHOW ENGINE INNODB STATUSG在输出中查找LATEST DETECTED DEADLOCK和TRANSACTIONS部分分析死锁和锁等待的详细信息包括涉及的SQL语句和表。五、结合压测工具的监控功能如果你使用的是JMeter等压测工具可以结合其监控插件或第三方监控工具如Prometheus、Grafana来实时监控数据库的性能指标。1. 设置JMeter监控使用JMeter的监听器Listener如JDBC Request、View Results Tree实时查看查询的响应时间和错误。 * 使用JMeter Plugins中的监控插件如PerfMon监控服务器的CPU、内存、磁盘I/O等指标关联到数据库性能问题。2. 使用第三方监控工具Percona Monitoring and Management (PMM)一个开源的监控解决方案专为MySQL设计提供实时查询分析和性能指标。 *Grafana Prometheus通过配置MySQL Exporter收集数据库的性能指标并在Grafana中可视化展示帮助识别性能瓶颈。 *六、优化发现的问题1. 优化慢查询添加或优化索引确保查询中使用的列有合适的索引。 *重写查询简化复杂的查询避免不必要的子查询和JOIN操作。 *分区表对于大表使用分区技术减少查询的扫描范围。2. 解决锁问题优化事务缩短事务的执行时间避免长时间持有锁。 *隔离级别调整在保证数据一致性的前提下适当降低事务隔离级别如从REPEATABLE READ调整为READ COMMITTED。 *索引优化确保查询使用索引减少锁的范围和数量。3. 缓冲池和表结构优化调整innodb_buffer_pool_size确保缓冲池足够大以容纳大部分活跃数据减少磁盘I/O。 * 分库分表 *水平分表将表的数据按某个键值分散到多个表中减小单表的数据量提升查询性能。 *垂直分表将表的不同列分散到多个表中减少每个表的宽度提升查询效率。七、持续监控和迭代优化性能优化是一个持续的过程应定期进行压测和监控及时发现和解决新的性能瓶颈。同时结合业务发展和数据增长动态调整数据库配置和架构确保系统始终保持高效稳定。