本文主要讨论用户记录存储相关的数据页面（索引页和外部存储页）的物理结构以及组织方式。InnoDB用B+树的方式管理用户记录数据，每个索引对应一个B+树。B+树是通过索引页构建的，用户记录的数据存储在聚簇索引的叶子结点中。如果有变长字段（如text、blob、varchar）的长度过长，则可能会将该字段的全部数据或部分数据存储到外部存储页（blob页面）。
最近我们发现在Read Committed隔离级别下出现了S类型的Gap锁参与的死锁告警。 本身RC隔离级别上出现Gap锁就很诡异了，更诡异的是两条看起来完全不相干的SQL发生了死锁。让我们一起来分析一下吧。
在之前的公众号文章《GTID实践和分析》中介绍了GTID的基本原理，MySQL主要通过Server引擎的binlog文件和Innodb的mysql.gtid_executed表来持久化GTID集合信息。在提交时会将分配给事务的GTID刷到binlog文件中，在事务成功提交后会将GTID加入内存的executed_gtids集合中，并周期性持久化到mysql.gtid_executed表中。在实例恢复时可以从mysql.gtid_executed表+最后一个binlog文件中的GTID信息来恢复executed_gtids集合，从而保证GTID的完整性。
弹性伸缩是云计算时代给我们带来的一项核心技术红利，但是 IT 的世界中，没有一个系统功能可以不假思索的应用到所有的场景中。这篇文章，我们将应用企业级分布式应用服务-EDAS 的客户在进行系统架构设计时，在弹性场景下遇到的点滴做了一个系统的梳理，总结为五个条件和六个教训分享给大家。
钉钉工程开始支持Swift，在适配clang module的过程中，遇到了各种各样的编译问题，为了弄清楚这些编译失败的真正原因，以及clang module的最佳实践，决定通过深入阅读clang module的实现代码，来解开这些谜团。
随着自动化任务在端上逐渐普及，我们可以在每天的任务中获取大量的截图。在UI自动化任务中，对于颜色的人工断言非常的耗费时间和精力，而真正存在颜色问题的占比又很少，导致人力成本过高但收益却很小。并且人力在大量的过滤这些图片的时候对于图片颜色的准确度并不能很好的把控。长时间的人工断言会产生颜色视觉上的审美疲劳，需要极强的专注力。在一些文字背景颜色相关的UI自动化任务当中，为了解决上述这些问题，我们通过一系列的图像处理和计算机视觉算法，将文字区域的背景色和字体颜色提取出来，为后续的自动化断言提供精确的输入，降低人工检查的成本。
