每日内容推荐
【巡检问题分析与最佳实践】RDS MySQL 实例IO高问题
RDS MySQL的IO性能受到硬件层存储介质类型、软件层的DB内核架构、具体SQL语句扫描或修改数据量的影响。>>点击了解详情
实例的空间使用率是RDS MySQL用户日常需要重点关注的监控项之一。如果实例的存储空间完全打满，将会导致严重的影响，包括：数据库无法写入、数据库备份无法正常完成、存储空间扩容任务的执行耗时可能更长等。 一般来说，当一个RDS MySQL实例的存储空间使用比例达到80-85%以上时，就应及时进行处理，要么降低数据库实际占用空间的大小，要么对存储空间进行扩容，以避免空间打满的风险。>>点击了解详情
实例内存使用率和buffer pool命中率是RDS MySQL的关键指标之一，如果内存使用率过高会有OOM风险，如果buffer pool命中率低，大量的数据页无法命中buffer pool中缓存的数据页，需要从存储读取数据，造成IO吞吐增加和延迟增加。>>点击了解详情
【巡检问题分析与最佳实践】RDS MySQL 活跃线程数高问题
活跃线程数或活跃连接数是衡量MySQL负载状态的关键指标，通常来说一个比较健康的实例活跃连接数应该低于10，对于一个高规格和高QPS的实例，一般活跃连接数可能也就20、30，如果出现几百、上千的活跃连接数，那说明肯定有SQL堆积和MySQL 响应变慢，严重时会引起实例雪崩，实例hang死，无法继续处理SQL请求。>>点击了解详情
判断查询的性能就是看查询执行的时间，这个时间针对不同的业务要求上也有差异。在同一时间内SQL执行的越快，执行的SQL就越多，完成的业务逻辑就越多。同样一个业务场景不同的架构设计、数据库表索引设计，由不同的人来做效果是不同的，有的人可以用很低的成本，RDS规格，ECS规格跑出很高的性能。最好的情况是自顶向下了解业务，以及每个业务涉及的SQL，这样就能厘清业务和数据库负载的关系；也能找到短板，并对短板做有针对性的优化；全链路压测就是做的这个事情。>>点击了解详情
【巡检问题分析与最佳实践】RDS MySQL小版本升级最佳实践
任何软件满足客户的需求都不是一蹴而就的，都是通过版本迭代完善功能和优化性能。无论是开源社区、还是电脑、手机类的应用，都是需要经常升级的，只不过越往底层如操作系统、CPU型号等升级，依托于操作系统之上的上层应用影响越大，版本迭代越慢。对于跑在云上的客户来说，底层数据库的升级影响也比较大，所以要做好充足的验证。为了减少广大客户在升级版本过程中少踩坑，保障业务稳定，特推出此文章仅供参考。>>点击了解详情
