ITPub博客

随着XC工作的深入，一些较为关键的系统已经开始使用国产数据库了。上周和一个客户进行交流的时候，他们就提了一些关于迁移到国产数据库后的性能问题。比如他们的一个业务系统迁移到某国产数据库后变得忽快忽慢，快的时候与以前Oracle差不多，而慢的时候要慢上数倍，导致业务超时。

每个数据中都希望自己的SQL 的执行计划是最好的，最快的，最妙的，但是在你使用EXPLAIN 的命令的情况下，你看的懂里面的那些东西吗？如果你看不懂，你怎么知道你的执行计划是最好的，最棒的，最妙的。

以 tenant_id = 1001 租户为例，查询 __all_virtual_tenant_memstore_info 表：

写完这篇文章 我感觉自己之前知道的真的是 “目录” 没有明白其中的内容 如果你能跟着节奏看完文章 一定会有收获 至少我写完感觉思维通透很多 以后百分之九十的 SQl索引问题 和 面试这方面问题都能拿

Sets 无序集合，他的功能就好像你熟悉的 Java 中的 HashSet 一样。集合是通过散列表实现的，所以添加、删除、查找元素的时间复杂度是 O(1)。

数据库中的优化器的工作就是选择更好的执行的方式来将SQL语句给出最好的方案来执行，那么评估一个SQL的好坏的方式就是代价cost 最小或者尽可能的小， cost 小了，则我们可以认为是 IOPS， CPU 的消耗都会减少，这就是我们希望看到的。 那么怎么能这样，回答可能是扫描的行数要少，那么用这个思路我们串一下。

由于MySQL 源码编译单机耗费的时间过于长，最近MySQL 变成8.0.27 以后编译时间明显更耗时了，并且办公室内有多余的空闲机器。 使用分布式编译，可以在不改变现有环境的情况下，提高编译效率。 目前比较常用的编译工具有2个 distcc 与 icecream , 本文使用distcc 进行部署。

Redis现在已经成了互联网的基石了，之前分享了Redis的高并发以及高可用，本篇接着谈Redis比较重要的内存回收机制原理

我们来聊聊 MySQL 是怎么判断一条记录是否匹配 where 条件的。

基于解决死锁问题存在的难点，本文以 MySQL 数据库一则并发 Insert 导致的死锁为例，从发现问题、重现问题、根因分析、解决问题4个步骤，期望能提供一套关于死锁的科学有效方案，供读者朋友参考。

​最近有人问，从ORACLE 迁移项目到POSTGRESQL 在之前的项目中有将表insert into select 的操作，对比之前的ORACLE 的操作到 PG 上，对于这个操作相对的操作的时间较长。另外询问不是有并行的方式来进行数据的导入导出的操作。

本文结合一个实际故障案例出发，从小白的视角分析慢SQL是如何打垮数据库并引发故障的。

但事实上，存在即合理。在绝大多数情况下，Seconds_Behind_Master 还是能很好的反映主从延迟情况。这里会重点介绍两种方案：pt-heartbeat 和 MySQL 8.0 原生的解决方案。

源码分析系列的第 3 篇文章，我们来聊聊 MySQL 是怎么判断一条记录是否匹配 where 条件的。

由于安装数据库时将MySQL的数据目录放在了根目录下，现在存储空间不足，想通过mv将数据目录移动到其他目录下，但将数据目录移动到其他数据目录后，启动数据库失败。

前段时间，客户反馈 Zabbix 实例的 history_str 表数据量很大，导致磁盘空间使用率较高，想要清理该表，咨询是否有好的建议。想着正好最近学习了相关的知识点，正好可以检验一下学习成果，经过实践的检验，最终考试合格，客户也比较满意，于是便有了此文。

在MySQL数据库中，为了解决并发问题，引入了很多的锁机制，很多时候，数据库的锁是在有数据库操作的过程中自动添加的。

在上篇文章中，松哥和小伙伴们分享了 MySQL 的聚簇索引，也顺便和小伙伴们分析了为什么在 MySQL 中主键不应该使用随机字符串。但是主键不用随机字符串用什么？主键自增？主键自增就是最佳方案吗？有没有其他坑？今天我们就来讨论下这个话题。

本文是线上问题处理案例分析，旨在通过真实案例向读者介绍发现问题、定位问题、解决问题的方法。本文讲述了从垃圾回收耗时过长的表象，逐步定位到数据库连接池保活问题的全过程，并对其中用到的一些知识点进行了总结。

某客户的业务中有一张约4亿行的表，因为业务扩展，表中open_id varchar(50) 需要扩容到 varchar(500)。变更期间尽量减少对主库的影响(最好是不要有任何影响->最终争取了4个小时的窗口期)。