ITPub博客

MySQL官方提供了InnoDB Cluster，该集群由MySQL MGR和MySQL Router组成。MySQL MGR在数据库层面实现自主高可用性，而MySQL Router则负责代理访问。在部署完成后，MySQL Router将形成单点，如果出现故障，将会影响数据库集群的可用性。因此，为了提高数据库系统的可用性，需要搭建MySQL Router的高可用性方案。

很多小伙伴也有类似的困惑，自己的公司并不大。并发量、访问量要求不高，使用单机 Redis 就能很好的解决数据请求的问题。为啥要使用集群呢？

很多问题会在 PostgreSQL 安装过程中发生，并且不少问题潜伏在不易察觉的地方，在一段时间内逐渐积累，最终引起POSTGRESQL的故障。无论是明显的性能下降，还是资源消耗和使用成本的急剧增加，尽早识别这些问题非常重要——更好的做法是，通过知道更多于POSTGRESQL的知识，避免出现此类问题。

今天我在翻看分区表文章的时候，重新审视了一下分区表的几个参数，又多了一些思考🤔，温故而知新。

安装简介 高可用搭建 高可用及负载均衡测试 问题处理

本文主要讨论的还是5.7，8.0没有实际测试，这里简单记录。

关系型数据库的表连接最常用的有三种方式，NESTED LOOP，HASH JOIN和MERGE JOIN(SORT MERGE JOIN,SMJ)。在Oracle数据库中，DBA也经常被这三种JOIN给折腾的够呛，一旦优化器因为统计信息的不准确出现了JOIN类型选择错误，那么对系统性能来说，就没法看了。前阵子有朋友问我这三种JOIN在什么场合使用。实际上PG数据库对这三种JOIN的支持都还不错，今天早上事情比较多，我就写个简单点的文章，利用一个INNER JOIN的SQL来给大家解释一下这三种JOIN模式，并且大致分析一下其应用场景吧。

之前碰到客户咨询定位 DDL 阻塞的相关问题，整理了一下方法，如何解决 DDL 被阻塞的问题。下面，就这个问题，整理了一下思路： 怎么判断一个 DDL 是不是被阻塞了？ 当 DDL 被阻塞时，怎么找出阻塞它的会话？

最近遇到一个难题，关于POSTGRESQL 的Tigger问题，实际上我是十分不愿意在数据库中使用tigger， 管理的问题，性能的问题，以及可能在你不清晰你部署了tigger 的情况下，触发到底会发生什么的问题。但实际的问题中，还是会被逼无奈的使用TIGGER ，所以本期的说说TIGGER 我们怎么用。

首先需要知道MySQL中触发器特点，以及表table相关触发器加载方式

测试在做 OceanBase 纯读性能压测的时候，发现对数据做过更新操作后，读性能会有较为明显的下降。具体复现步骤如下。

同步到的版本为5.7.35，按理说在5.7中还是一个比较新的版本了，报错大概如下：

MySQL8.0在优化器上做了很多努力和优化，仍然不足以保证每条sql，都能拥有合理的执行计划，有些情况需要通过hint来干预。MySQL8.0在hint的种类上进行了新增。本篇主要讲我们可以有哪些方法影响优化器。

MySQL 8.0.28开始，新增一个特性，支持监控统计并限制各个连接（会话）的内存消耗，避免大量用户连接因为执行垃圾SQL消耗过多内存，造成可能被OOM kill的风险。

有一个比较奇怪的现象是：问题持续的过程中，服务器的系统负载、CPU 使用率、磁盘 IO、网络都处于低峰时期的水平，也就是说，问题很可能不是因为硬件资源不够用导致的。 那么，根本原因到底是什么？让我们一起来揭晓答案~

去O的声音越来越大，让我不经由此联想。Oracle很早就进入中国，在国内的使用的范围非常之广，可以比作一个庞然大物。那么去掉Oracle以后的市场由谁填充，如此庞大的市场导致众多公司都想前来分一杯羹。当前在中国做数据库产品的有200多家，位于头部一直有热度的公司也得有20~30家，在众多公司中，真正做产品的可能也是少数几家。不知道现在做国产数据库的是不是有政府补贴，出现这么多产品，目不暇接。

同事提了个需求，如下测试表，有code、cdate和ctotal三列，

MySQL服务器安装MHA,sed命令修改安装脚本时卡死：

OceanBase中的写入限速机制旨在控制系统中写入操作（一般写入操作包括插入、更新和删除等）的速率，目的是为了提高数据库系统的稳定性。本文主要通过以下2个参数来解释写入限速的实现机制。

如果你的查询中用到了索引，这是一个进步，如果能够更进一步，用到了覆盖索引，那么就更牛了！当我们设计一个索引的时候，如果能够从一个更加全面的角度去设计这个索引，不仅考虑到 where 中的条件，还能够考虑到整个 SQL，那么无疑这个索引的设计将是非常成功的。