数据库执行引擎不仅要统计单条 SQL 用了多少内存，还要协调多个 SQL、后台任务和运行时系统之间的内存竞争。当资源不足时，谁应该继续执行，谁应该等待，谁应该退出？内存过载可能从单条 SQL 变慢扩大为实例级故障，影响同一实例上的其他业务。
控制内存竞争、优先保护关键负载，是数据库保障可用性和支撑业务 SLA 的一部分。本文围绕 TiDB 执行引擎的全局内存仲裁机制，介绍它如何协调 SQL 的内存申请，以及如何兼顾实例稳定性、内存利用率和业务优先级。
记录一次纯黑盒的 fd 泄漏问题排查过程。该问题发生在云上 GCP 环境，无法在本地或可控测试环境稳定复现，只能通过系统观测、tcpdump、对照实验等方式逐步收敛问题范围，最终定位到高置信触发链路并通过参数绕过止血。
What good can using exceptions do for me? The basic answer is: Using exceptions for error handling makes your code simpler, cleaner, and less likely to miss errors. But what’s wrong with “good old errno and if-statements”? The basic answer is: Using those, your error handling and your normal code are closely intertwined. That way, your code gets messy and it becomes hard to ensure that you have dealt with all errors.
由于 C++ 异常机制复杂的特性，编写异常安全的代码不是件轻松的事情。异常增强了语言的表达能力，但也带来了不可避免的开销。本文简单分析了 C++ 异常机制的实现原理，并总结相关注意事项。
本文主要讨论 Linux/ELF、System V AMD64 ABI、Itanium C++ ABI 下的实现，实验环境为 Clang 15。编译器、标准库、C++ ABI 运行时和 unwind 库是相互独立的组件；复现实验时还需要确认发行版、链接器及各运行库的具体实现和版本。其他平台和编译器的实现可能不同。
Ref What is a materialized view?: A materialized view is a pre-computed data set derived from a query specification (the SELECT in the view definition) and stored for later use. Because the data is pre-computed, querying a materialized view is faster than executing a query against the base table of the view. This performance difference can be significant when a query is run frequently or is sufficiently complex. As a result, materialized views can speed up expensive aggregation, projection, and selection operations, especially those that run frequently and that run on large data sets.
本文记录一项基于 Flink / Hudi / Kafka / TiCDC 以及 TiDB 构建 Materialized View（物化视图，aka MV）的简易 demo。
In database systems, Collation specifies how data is sorted and compared in a database. Collation provides the sorting rules, case, and accent sensitivity properties for the data in the database.
在数据库系统中，CHARACTER SET(aka 字符集) 为一组字符和编码的集合，COLLATION 则表示字符排序|比较规则、大小写敏感等属性。参考 Character Sets and Collations in MySQL，MySQL 支持多种字符集，每种字符集包含多种 collation（默认使用一种）。TiDB 体系中默认采用字符集 utf8mb4，collation utf8mb4_bin。对于 TiFlash 这样的 OLAP 引擎而言，字符集相关规则引入的额外抽象必然会对性能产生较大影响，本文主要阐述优化 collation 的过程并在 Benchmark TPCH 和 ClickBench 上验证效果。
C++ 提供了很大的工程自由度；如果缺少明确的依赖边界和持续度量，模板、头文件与编译单元的成本很容易随项目规模一起放大。
随着工程规模增大，TiFlash 项目也逐渐开始暴露出这类问题：
本文旨在提供量化指标和参考方法用以优化 C++ 工程项目的编译流程。希望动员社区的力量，一起来优化 TiFlash 的工程质量。
全文包含两条主线：
TiFlash 于 2022-04-01 GMT+8 10:35 愚人节 正式官宣开源。
这是加入 PingCAP（aka 贵司）后首次尝试从提出规划到推进落地项目开源，算是值得纪念的事件 Celebrate open-source (#4551)，在此存档相关历程。
PingCAP（aka 贵司）自研了套部署工具 TiUP 来取代早前使用的重型部署工具 Ansible。然而实际使用时，TiFlash 节点在打 patch 过程中出现过不符合预期的报错。后来发现，TiUP 打 patch 的操作并没有停进程，而是直接 tar 命令解压覆盖部署目录，原子性保障也是无从谈起。v6.0 版本前 TiFlash 部分模块包含动态加载 共享库（aka 动态库）的行为，这类行为会被搜索路径下的库文件影响。如果存在某个时刻引入的模块相互不兼容，则直接影响程序的行为。
因为当时使用的 tar 实现会先移除旧目录项再创建新文件，已经映射旧 Inode 的进程没有遇到 cp 原地截断共享库常见的 Segmentation fault 问题。但这并不意味着整个 patch 过程具备原子性：更新期间启动的新进程或再次执行 dlopen() 的线程，仍可能看到缺失、未写完或彼此不兼容的一组文件。
正好借此整理下相关的几个问题：
结论先行：
cp 原地覆盖正在被映射的共享库。rename() 原子替换目标；如需保证掉电后的持久性，还要同步文件和目录元数据。本文原链接 The architecture of TiFlash’s distributed storage engine and transaction layer 主要站在开发者的视角阐释 TiFlash 分布式存储 & 事务体系的基本架构和设计思想。
这套体系最初是 2018 年底本人加入 PingCAP 后开始从 0 到 1 设计构建的，于 2020-04-16 随 TiDB v3.1.0 版本正式 GA。
Release Notes 作为开源软件工程实践的重要一环，会很大程度上影响用户体验和交付流程。此篇文档是本人在历次发版任务中总结出来的模板规范，用以帮助产研提升 Release Notes 质量。该规范已由组内推广至 PingCAP 全公司。