ITPub博客

通过今天演讲我们来说说mongodb altas 在行业中的使用经验，希望今天的演讲对你的工作有用。

本文将从源码角度分析 Redis 惰性删除的实现逻辑，主要包括以下几部分： Redis 访问 key 的实现逻辑。 主动访问过期 key，什么场景下不会删除？ 删除操作的实现逻辑，包括 key 的内存及 value 的内存是如何释放的？ 同步删除和异步删除的区别。

线上使用MySQL8.0.25的数据库，通过监控发现数据库在查询一个视图(80张表的union all)时内存和cpu均明显上升。 在8.0.25 MySQL Community Server官方版本测试发现：只能在视图上进行数据过滤，不能将视图上的过滤条件下推到视图内的表上进行数据过滤。8.0.29以后的版本已解决该问题。

PG数据库目前已经成为最热门的开源数据库之一，特别是因为其开源协议十分适合商业化，因此大量的商用数据库，包括大量的国产数据库也都基于PG的开源代码进行研发。

MySQL HeatWave 是 Oracle 在2020年推出的一个新服务，为 MySQL 数据库提供高性能的分析和机器学习功能。它是一个基于云的服务，使用内存技术和分布式存储来提供更快的查询处理和数据分析。

于是 Redis 管道（pipeline）便产生了，一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应。这样就可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复。这就是管道（pipelining），减少了 RTT，提升了效率

随着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 条件的。