Filesort过程
这篇文章深入MySQL源码，剖析了Filesort这一经典排序过程的具体实现。作者从源码阅读出发，清晰地展示了当查询需要排序而索引无法直接满足时，MySQL如何通过Filesort机制完成操作。 其核心在于一套高效的双buffer（sort_buffer）排序算法。文章指出，当数据量较小时，排序在内存中完成；而一旦数据量超出内存限制，系统会分批次将数据写入临时文件，再进行多轮归并排序，最终产出有序结果集。这个过程中，对内存的合理利用和磁盘IO的优化，是实现高效排序的关键。作者对其中“利用堆排序进行多路归并”等实现细节的解读，让我们看到了设计上的巧妙与务实。 通过源码级的拆解，这篇文章将原本抽象的排序过程变得具体可感，不仅解释了Filesort“是什么”，更说清了它“如何高效工作”。对于想理解MySQL查询执行内部机制、优化排序性能的开发者而言，这是一次扎实的源码追踪之旅。
Chaos网络库（三）- 主循环及异步消息的实现
这篇讲的是Chaos网络库第三部分，聚焦于其主循环及异步消息机制的实现细节。作者从构建高性能网络库需要解决的核心问题——如何高效处理海量并发连接与消息——出发，深入到了事件驱动模型的具体落地。 文章清晰阐述了主循环作为网络库“心脏”的工作原理：它通常基于epoll（或类似的I/O多路复用机制）不断轮询就绪事件，然后分发给对应的处理器。而更有趣的部分在于异步消息的设计。作者展示了如何通过消息队列与工作线程池配合，将耗时操作（如数据解析、业务逻辑）与I/O事件处理解耦，避免了主循环被阻塞。其中巧妙利用无锁队列或精心设计的锁策略来保证线程安全并提升吞吐量，是一个关键的实现亮点。 这种设计确保了网络库在高负载下仍能保持稳定的响应能力和资源利用率。对于想要了解现代网络框架底层运作，或计划自己设计高并发服务的开发者来说，文章对这两部分协同工作的剖析提供了非常扎实的参考。
Chaos网络库（二）- Buffer的设计
这篇技术分析聚焦于Chaos网络库中的Buffer模块设计，特别是它如何不同于主流网络库libevent的处理方式。作者直接切入技术细节，指出libevent（以1.4.13版本为例）采用了能自动扩张的传统buffer策略。 而Chaos则另辟蹊径，其buffer设计旨在解决特定场景下的性能与内存管理问题。文章通过对比揭示了两者在内存分配、数据拷贝与扩容机制上的关键差异：libevent偏向灵活通用，Chaos则更注重在已知负载或特定协议下的高效与可控，减少了不必要的内存波动。 这种设计差异直接影响了各自适用的应用场景。对于需要极致性能或资源受限的环境，Chaos的方案可能更具优势；而对于需求多变的一般应用，libevent的经典方式则提供了更大的灵活性。文章通过具体实现思路的剖析，展现了网络库底层设计中权衡与取舍的艺术，为开发者提供了有价值的实现参考。
Chaos网络事件库开篇介绍(一)
这篇讲的是一个名为 Chaos 的新生代网络事件库。作者从自身在异步编程方面的积累出发，介绍 Chaos 是一个基于 Linux 平台、使用 C++ 按 reactor 模式开发的网络库，目前专注于 TCP 协议，并仅在 x86_64 架构下提供编译支持，遵循 3-clause BSD 开源协议。 在设计上，作者坦言 Chaos 的接口风格深受 boost asio 的影响，后者在异步编程模型上的清晰思路给了他很大启发。不过，这也引出了一个有趣的开发哲学：作者并没有深入研读 asio 的源码。他解释说，一方面是 boost 重度模板化的代码可读性颇具挑战，更重要的是，他希望避免在“先入为主”的设计中丧失独立思考的机会。 因此，Chaos 的诞生更像是一次主动的实践与重构。作者希望通过亲身探索，在吸收优秀设计思想的同时，构建出属于自己的网络编程解决方案。文章作为系列的开篇，为我们揭示了这个新项目背后的技术选型与思考起点。
环境切换 – 残酷的性能杀手（上）
这篇讲的是服务器性能优化中两个常被忽视却至关重要的“隐形杀手”：上下文切换和Cache Line同步。 作者从实践经验出发，指出许多人在优化服务器时，习惯性地将火力集中在减少内存拷贝、降低IO次数这些经典方向上。这当然没错，但就像盖房子，人们往往专注于主体结构是否坚固，却忽略了地基的微小沉降和材料的热胀冷缩——这些“不明显”的因素，在极端负载下反而可能成为压垮性能的最后一根稻草。 文章将这个深度话题分成了上下两篇。作为上篇，它着重揭示了问题本身：为什么我们总是盯着内存和IO，却对CPU在不同任务间频繁跳转（上下文切换）以及多个核心争抢同一内存块（Cache Line同步）带来的巨大开销视而不见？作者认为，一个追求极致的高性能服务器，必须具备更细腻的洞察力，将优化视野扩展到这些芯片层面的资源争夺战中。这为后续探讨具体优化策略做好了铺垫。
MySQL 中 QueryCache 的锁模型
这篇直接回应了一个在技术社区中常见的疑问：MySQL 的 Query Cache（QC）使用的是“全局锁”还是“表锁”？作者没有停留在简单的二选一，而是深入到实现层面，厘清了 QC 的锁模型。 关键点在于，QC 的锁并非传统意义上的、针对整个查询或某张表的锁。它实际上是一个更细粒度的“锁段”（lock segment）机制。当一个查询被解析并需要访问 QC 时，它会根据查询语句的哈希值定位到特定的内存段，然后尝试获取该段上的锁。这意味着，只要两个查询的哈希值不同（即查询不同），它们就可以并发地读写 QC 中不同的内存段，互不干扰。 这解释了为什么在某些高并发场景下，QC 不会像全局锁那样成为瓶颈。但同时，哈希冲突（不同查询映射到同一段）或对同一内存段的竞争，依然会导致串行化等待。作者的剖析，帮助读者超越了“是或不是”的简单判断，去理解锁竞争的实质粒度，这对于分析具体业务下的 QC 性能瓶颈非常有指导意义。
C++ 多进程并发框架FFLIB之Tutorial
这篇讲的是一个名为FFLIB的C++框架，旨在简化分布式或多进程并发场景下的开发工作。 作者从实际工作中的高频痛点出发，比如繁琐的消息定义、异步逻辑处理、多线程管理以及后续的单元测试和性能优化等，这些是每个涉及并发的开发者都可能遇到的挑战。FFLIB的核心思路是提供一套统一的解决方案来应对这些复杂性。文章作为一篇教程，应该会介绍该框架的基本概念和用法，其核心机制可能建立在进程隔离与高效共享内存通信之上，从而在保证稳定性的同时提升性能。 通过封装这些底层细节，FFLIB的目标是让开发者能够更专注于业务逻辑本身，而不是被并发带来的各种技术杂务所困扰。文章最后可能引导读者如何开始搭建和应用这个框架。
C++多进程并发框架
这篇讲的是作者基于三年一线服务器开发经验，整理优化并开源的C++并发框架——FFLIB。他没有空谈理论，而是直面服务器开发中最常见的硬骨头：多线程并发模型如何选型、高效的消息转发与异步机制、性能瓶颈如何优化，以及如何用单元测试保证质量。作者从零搭建这个框架的过程，就像在梳理一个服务器开发者从新手到熟手可能遇到的所有关键问题。 FFLIB的核心思路，是围绕上述问题给出一个完整的工程化解答。它并非一个简单的库，而是一套架构实践。对于并发，作者倾向于探讨多进程模型下的特定考量；对于消息流转，框架提供了清晰的路径；而性能优化与测试覆盖，则被直接嵌入到代码库的基因里。这篇文章像一次坦诚的技术分享，把踩过的坑、总结出的方法论，都凝结在了这份代码和文字里。 最终呈现的，是一个经过实际项目打磨、针对高并发场景的C++框架。它为我们展示了如何将零散的服务器开发知识点，系统性地整合到一个可维护、可扩展的工程方案中。如果你正在设计或重构自己的服务端应用，FFLIB的实现思路，或许能提供一份具体的参考蓝图。
Nginx+KV db进行AB灰度测试
这篇讲的是如何在运维实践中，将Nginx与KV存储结合，低成本地实现AB灰度测试。 作者从华东运维大会的见闻出发，提到淘宝在Nginx场景下的应用给了他启发。其中，AB灰度测试被认为适用场景非常普遍，但大会并未深入探讨具体实现。于是，他着手探索了一条自己的路径：利用Nginx的模块能力与一个轻量级的KV数据库协同工作。 具体方案上，这个KV存储里预先配置好了不同灰度规则对应的流量分配比例和后端标识。当请求到达Nginx时，它会根据用户ID、地域等维度作为键，去KV数据库中查询应该命中的版本（A或B），然后动态地将请求转发到对应的上游服务组。这种设计让流量切换和规则调整变得非常灵活，无需频繁改动Nginx配置并重载。 通过这套自建方案，作者实现了平滑、可动态调整的灰度发布流程。这个案例的价值在于，它提供了一个具体可行的思路：对于缺乏昂贵专业灰度发布系统的团队，完全可以利用开源组件，组合出功能完备的灰度能力，关键在于理清模块间的协作逻辑。
MySQL多线程同步MySQL-Transfer介绍
这篇讲的是如何解决MySQL主从同步中的单线程瓶颈问题。作者介绍了一个基于MySQL 5.1打补丁而来的中间层工具MySQL-Transfer。 原生的MySQL主从复制中，从库单线程应用主库的binlog，在高并发写入场景下容易成为性能瓶颈。Transfer的核心方案就是引入多线程并行执行机制。它作为一个“虚拟从库”接收主库binlog，然后通过内部多线程并发地将更新应用到真正的从库上。其巧妙之处在于按照表名进行哈希，将不同表的更新分配到不同线程，从而在多表环境下显著提升同步吞吐量。此外，该方案还支持多主架构，可同时作为多个主库的从库进行同步。 从性能测试数据看，效果非常明显。在16个表并发各插入10万行数据的场景下，原生MySQL主从同步耗时363秒，而使用Transfer同步仅需66秒，平均TPS从约4400飙升至约24200，性能提升了数倍。文章还提供了具体的配置参数和应用补丁的方法，具有很强的实践指导性。
关于 innodb_stats_on_metadata 的设置问题
这篇讲的是 MySQL InnoDB 存储引擎中一个容易被忽略却影响重大的参数——`innodb_stats_on_metadata`。作者从实际运维场景出发，详细说明了开启该参数后，每次执行 `SHOW TABLE STATUS` 或访问 `INFORMATION_SCHEMA` 中的统计表时，InnoDB 都会重新计算索引统计信息。 这一行为在频繁查询元数据的监控或管理场景下，可能导致大量的额外 I/O 和 CPU 开销，进而影响数据库性能。文章对比了该参数在 ON（默认）和 OFF 两种状态下的行为差异，并给出了明确的调优建议：对于绝大多数 OLTP 应用，建议将其设置为 OFF，以避免不必要的性能损耗。 文中还结合了具体的测试数据，展示了关闭该参数后，在特定负载下系统响应时间的显著改善。最后，文章指出，即便关闭了自动更新，我们仍可通过手动执行 `ANALYZE TABLE` 来按需更新统计信息，从而在性能与统计准确性之间取得平衡。
MySQL表名映射方案及扩展应用
这篇讲的是如何用一个简单方案，优雅地解决MySQL主从架构下需求不一致带来的麻烦。问题很典型：主库为了扛住高并发，做了分库分表；但从库要支持各种复杂的多维查询，不分表又更方便。让同一套代码维护两套完全不同的表结构，显然不现实。 作者给出的核心思路是“表名映射”。简单说，就是在代码层面维护一个映射规则，让访问分库分表的主库时，自动转换到正确的物理表名（比如 `order_2023`），而访问从库时，则统一使用一个聚合的逻辑表名（比如 `order_all`）。这样，业务查询代码可以保持统一，不用关心底层存储差异。 方案的巧妙之处在于它的轻量和可扩展性。它不依赖复杂的中间件，实现成本低，并且这个映射思想可以推广到其他场景，比如多活架构中的库表路由、或者灰度发布时的数据隔离。核心是解耦了业务逻辑与底层数据分布，让架构更灵活。
MySQL数据库InnoDB存储引擎 Buffer Pool Flush List详解
这篇详解的是MySQL InnoDB存储引擎中Buffer Pool的Flush List机制。作者深入剖析了当数据页在Buffer Pool中被修改成脏页后，InnoDB如何通过Flush List来跟踪并最终将它们异步刷回磁盘的过程。 文章的核心在于阐明Flush List的设计与工作原理。它不是一个简单的队列，而是按照页的修改时间（最早修改时间）进行组织的链表。这个设计巧妙之处在于，它能确保最“老”的脏页被优先刷新，从而有效控制数据库恢复时间（Redo Log覆盖循环的约束），并配合Adaptive Flushing等策略，平衡刷盘对性能的影响。 通过讲解Flush List与LRU List的协同工作、刷盘时机的判断逻辑，以及它对数据库整体性能和稳定性的关键作用，文章为读者理清了InnoDB如何高效、可靠地管理内存与磁盘的数据同步。理解这部分机制，是进行MySQL深度性能优化和故障分析的重要基础。
MySQL数据库InnoDB存储引擎 Buffer pool LRU List Flush策略详解
这篇文章深入到了MySQL InnoDB存储引擎的内存管理核心，讲的是它如何通过精心设计的LRU List和Flush List协作，来高效管理Buffer Pool这一宝贵的内存资源。作者没有停留在表面概念，而是从LRU链表的“冷热数据分离”机制讲起，剖析了young区和old区如何协作来避免全表扫描等操作对热点数据的污染。 文章的巧妙之处在于揭示了LRU与Flush两个链表的分工与协同。LRU链表负责维护数据的访问热度，决定数据页的“生杀大权”；而Flush链表则专门追踪那些被修改过但还未写入磁盘的脏页，是内存与磁盘同步的关键。通过解析这种双重链表结构与后台刷新线程的配合，文章清晰地展示了一套动态的内存管理策略：既能保证热数据的快速访问，又能异步、平滑地将脏数据刷盘，从而在性能与数据持久性之间找到最佳平衡点。 读完这篇文章，你不仅能理解Buffer Pool配置参数背后的原理，更能对InnoDB如何在高并发压力下既保持响应速度又确保数据不丢失，建立起一个扎实的认知框架。
数据库数字参考表的妙用
这篇文章讲的是数据库中一个简单却容易被忽略的优化技巧：建立并使用“数字参考表”。作者开篇直接定义了这种表的核心——一个存放连续递增整数序列的表，并附上了具体的建表SQL示例。 数字参考表在实际应用中能发挥多种妙用。例如，当需要生成连续的数字序列（如日期、订单号片段）时，可以用它与其它表进行JOIN来快速构建数据集，避免复杂的循环或临时表操作。它也是实现“行转列”或进行数据补全（如填充缺失的月份记录）的常用辅助工具，在报表统计场景中尤为实用。 作者通过这篇短文，分享了一个构建高效查询和数据预处理的基础组件。这种利用静态序列表来简化逻辑的思路，展示了数据库开发中“以空间换时间”或“化繁为简”的典型实践。
MySQL 中group by的实现
这篇讲的是 MySQL 中 `GROUP BY` 到底是如何实现的。作者从一个常见的误解出发——很多人根据执行计划中的 `Using filesort` 认为，`GROUP BY` 是“先排序，后分组”。但真的是这样吗？ 作者通过一个对比实验来验证：在查询中显式添加 `ORDER BY NULL` 后，`filesort` 消失了，结果行的出现顺序也发生了改变。这说明排序并非分组的必要步骤，而是后续的一个可选操作。 文章深入到了算法层面。MySQL 实际采用的是一种更高效的哈希分组算法：它会创建一个临时表，遍历原表数据时，根据分组键（key）进行哈希查找。若 key 存在则更新计数，不存在则插入新行。整个过程无需预先排序，时间复杂度是 O(n)。 最后，文章解释了默认情况下我们看到的结果是“有序”的，那仅仅是因为 MySQL 默认在分组后追加了一次排序操作。这与“先排序后分组”的直觉正好相反。
PostgreSQL从菜鸟到专家 数据库的数据存取设计
这篇讲的是，当你使用PostgreSQL时感觉“明明建了索引，查询还是慢”，问题可能出在数据存取的底层设计上。作者从一个常见的性能瓶颈场景出发，系统性地拆解了数据如何在磁盘与内存之间流转。文章深入到了PostgreSQL的行存与列存布局、MVCC机制下数据的多版本存储方式，以及TOAST大字段处理等具体实现层面。它没有停留在“建立合适索引”的通用建议上，而是解释了为什么选择B-tree或Hash索引、何时该用GIN索引处理JSONB，这些选择背后与表的填充因子、死元组清理（VACUUM）策略是如何紧密关联的。通过梳理从插入、更新到查询的全链路，文章阐明了存取设计是一个环环相扣的系统工程，一处不当就可能形成性能短板。对于希望从“会用”PostgreSQL走向“用好”的开发者，这篇文章提供了一张清晰的内部运作地图。
MySQL数据库InnoDB存储引擎的Group Commit（二）
这篇讲的是MySQL InnoDB存储引擎如何通过Group Commit技术来优化事务提交性能，特别是二进制日志（binlog）刷新与事务提交之间的串行化瓶颈问题。 作者兴奋地指出，Percona Server在其5.5.18-23.0版本中，已经优雅地实现了这一关键优化。其核心方案并非采用常见的“曲线救国”式workaround，而是直接移植了MariaDB数据库中被验证为高效的Group Commit实现。这意味着，多个并发事务在提交时可以被分组，一次性将日志刷盘，从而大幅减少磁盘I/O次数，显著提升高并发场景下的写入吞吐量。 这个实现的巧妙之处在于它以最“正统”的方式解决了历史难题。对于依赖Percona Server进行高性能数据库运维或开发的团队来说，这个版本的发布意味着一个长期以来的性能瓶颈被正式移除，为系统带来了切实的性能收益。
MySQL数据库InnoDB存储引擎的Group Commit（一）
这篇讲的是MySQL InnoDB存储引擎中一个经典的性能优化问题——Group Commit。文章没有提出新观点，而是基于Kristian Nielsen的四篇深度分析文章，对这个“由来已久”的问题做了一次清晰的梳理。 作者从Group Commit的定义出发，解释了它为什么在InnoDB中如此关键。简单来说，Group Commit是一项旨在提高事务提交性能的技术，通过将多个并发事务的提交操作合并为一次磁盘刷新（fsync），从而显著减少I/O开销。文章点出了它曾引发广泛关注的原因：在早期版本中，这个机制存在缺陷，可能导致严重的性能瓶颈。 目前，这个问题已经得到妥善解决。文章概述了修复方案的核心思路，帮助读者理解InnoDB如何通过改进的Group Commit机制，保障了高并发事务提交时的效率与可靠性。如果你对MySQL内部机制和性能优化的演进感兴趣，这篇文章提供了一个不错的入门总结。
C++ 后台程序实时性能监控
这篇文章从 C++ 后台开发中一个常见但棘手的痛点出发——如何在几乎不影响生产环境性能的前提下，实现程序运行状态的实时透视。作者没有停留在理论探讨，而是深入介绍了一套自研的轻量级监控方案，巧妙利用了性能计数器、无锁环形缓冲区与异步采样技术，将监控开销控制在了一个极低的水位。 方案的核心在于将数据收集与处理解耦：前台业务线程仅通过极简的指令记录关键事件，而后台分析线程则负责聚合与可视化。文章详细拆解了针对 CPU 使用率、内存分配热点以及锁竞争频率的监控实现，并给出了实测数据——在高并发服务中，这套机制带来的延迟增加不到 1%。 对于需要构建可观测性系统的后台开发者而言，这篇文章的价值不仅在于提供了一套可落地的代码思路，更在于它展示了如何在“监控”与“被监控对象”之间取得精妙的平衡。
