ITPub博客

在分布式系统中，缓存和数据库同时存在时，如果有写操作的时候，先操作数据库还是先操作缓存呢？先思考一下，可能会存在哪些问题，再往下看。下面我分几种方案阐述。

讨论了一些MySQL相关的问题，这里就来总结一下，大家也可以一起在留言区讨论。

​在PG数据库中shared_buffers会影响DROP TABLE的性能吗，群里也就这个问题讨论了许久。简而言之，就是 shared_buffers 参数的大小会直接影响到 DROP/TRUNCATE 的性能，这个以前还没有注意过，自己下来也验证了一下，发现的确如此，这立马引起了我的兴趣。

昨天晚上某群友问我一个SQL优化问题，我当时在处理公司问题，就让他丢到群里大家看。经过大家“我来找茬”，最终问题得以解决。废话到这里，上菜。

1.导读 2.背景介绍 2.1 为什么要做自助分析 2.2 核心解决的问题 2.3 建设初期的卡点 3.技术实现 3.1 技术架构 3.2 基于Quick BI+StarRocks的自助分析功能实现 3.3 为什么选择StarRocks作为OLAP引擎 3.4 上线效果 4.优化案例 4.1 内存超限问题优化 4.2 慢查询问题优化 4.3 维值加载慢问题优化 4.4 高峰期查询慢问题优化 4.5 数据写入参数优化 5.写在最后

内核中有很多晦涩的术语，什么"ring buffer"、"buffer ring"、"tuple"、"row"等等，不说刚入门的小白，老油条看到这些术语也会云里雾里。本文简单聊聊 PostgreSQL 中常见的术语。

随着IoT、手机应用、人工智能等发展带来数据爆炸式增长，越来越多的场景需要通过高效的数据管理和处理获得即时见解，HTAP因而成为全球数据技术的热门趋势。HTAP（即混合事务/分析处理）数据库能够同时支撑在线事务处理（OLTP）和在线分析处理（OLAP）场景，避免了传统架构中在线与离线数据库之间大量的数据交互。具体而言，OLTP实现在线交易处理，典型场景如银行转账业务；OLAP用于数据分析和报告。两种数据库本是相互独立的系统，而HTAP数据库将传统的OLTP和OLAP模式合二为一，基于一站式架构同时处理事务请求和查询分析请求，不仅消除了从关系型数据库到数据库仓库的数据抽取、转换和加载过程，还支持实时地分析最新事务数据，以灵活、高效、易用方式助力企业应对数字化时代挑战。

准备了SQL调优的13连问，内容非常干！相信大家看完一定会有帮助的。

本文主要分享了作者在蚂蚁集团高管数据链路改造升级过程中，针对去重Cube的优化实践。

通过本文，我们了解并掌握了索引的概念、作用、原理及优缺点。这部分内容既是精进 MySQL 的基石，也是 MySQL 面试的高频知识点，非常重要。

Redis 全文搜索是依赖于 Redis 官方提供的 RediSearch 来实现的。RediSearch 提供了一种简单快速的方法对 hash 或者 json 类型数据的任何字段建立二级索引，然后就可以对被索引的 hash 或者 json 类型数据字段进行搜索和聚合操作。 这里我们把被索引的 hash 或者 json 类型数据叫做源数据。

数据库表是一组行/记录。然而，这些行并不是以表的形式物理存储的，它们存储在块上的数据页中。要在这些数据页中找到特定记录需要扫描多个文件。为了改进这一点，我们创建索引。索引是小型的引用表，用于根据索引值存储对行的引用。

一个典型场景就是 OGG 同步到 PG，那么会在 PG 这一侧开启大量子事务，对于性能冲击很大，每次碰到这类问题，除了观测可能的等待事件 SubtransSLRU 、SubtransControlLock 之外，别无他法。所以，当我看到这两个插件时，立马眼前一亮。让我们小试牛刀一下！

现今时序数据的应用场景十分广泛，许多类型的数据都是时序数据，像传感器测量、工厂设备健康、交通物流等等。现代业务对数据价值挖掘的需求已不仅仅停留在简单计算和绘制图表的层面上，而是需要更多精细、复杂的计算分析，高压缩比，高写入吞吐量，以及高速的时间序列查询，是时序数据库相比于关系数据库在处理海量时序数据方面的最基本的能力和优势。随着近几年IoT、IIoT、AIoT和智慧城市快速发展，时序数据库也成为数据架构技术栈的标配。

随着SaaS软件日益流行，如何为企业用户提供即统一又相互独立的服务，成为很多基础软件商的课题，因而租户能力正受到更多关注。另一方面，随着分布式数据库的流行，如何充分利用分布式环境的算力及存储资源为不同业务服务，也同样对租户能力提出的要求。本文针对常用的租户实现方法、技术路线进行说明，重点说明场景数据库的租户能力并加以对比。

分布式 SQL 数据库会将应用程序数据存储在多个节点上，从存储和计算的角度提高了可扩展性。这种分布意味着某些应用程序请求，包括 JOIN 操作和聚合，可能跨多个数据库节点，可能导致数据在网络中的传输。

在实际的工作中，pgbackrest本身是可以进行集中化管理的，通过集中化的管理方式来进行批量的大范围的数据库管理如何进行相关的操作和配置。实际上pgbackrest 在单机备份的简便性还是不如pgrman的的便利性，但是在下图的备份方案中，则pgbackrest 是好的备份的方案选择。

这个问题相对简单，但是第一次遇到这种问题，仅此记录。问题主要是一个mysqldump导出也就100来M的文件，导入居然要几个小时，更换多个实例后都很慢，文件大小如下： 当然这种可以重现的问题就再次导入看看为什么就可以了。

pgbackrest是只支持8k的block size吗？还是编译的时候需要指定参数才可以支持其他大小的block size。我用block size 32k pg16.1 的库做测试，报下面的错误

最近有好几个朋友问，如何将 performance_schema.events_statements_xxx 中的 TIMER 字段（主要是TIMER_START和TIMER_END）转换为日期时间。