在我们的生产环境中有一张表：courier_consume_fail_message，是存放消息消费失败的数据的，设计之初，这张表的数据量评估在万级别以下，因此没有建立索引。

但目前发现，该表的数据量已经达到百万级别，原因产生了大量的重试消费，这导致了该表的慢查询。

因此需要清理该表数据。而实际上，使用 DELETE 命令删除数据后，我们发现查询速度并没有显著提高，甚至可能会降低。为什么？

因为 DELETE 命令只是标记该行数据为“已删除”状态，并不会立即释放该行数据在磁盘中所占用的存储空间，这样就会导致数据文件中存在大量的碎片，从而影响查询性能。所以，除了删除表记录外，还需要清理磁盘碎片。

在表碎片清理前，我们关注以下四个指标。

• 指标一：表的状态：SHOW TABLE STATUS LIKE 'courier_consume_fail_message';
• 指标二：表的实际行数：SELECT count(*) FROM courier_consume_fail_message;
• 指标三：要清理的行数：SELECT count(*) FROM courier_consume_fail_message where created_at < '2023-04-19 00:00:00';
• 指标四：表查询的执行计划：EXPLAIN SELECT * FROM courier_consume_fail_message WHERE service='courier-transfer-mq';

1
2

-- 清理磁盘碎片
OPTIMIZE TABLE courier_consume_fail_message;

以下是清理前后的指标对比。

本文来自我最近正在学习的课程，极客时间胡峰的专栏文章《程序员进阶攻略》。文中观点颇为认同，分享给你，部分内容我作了精简，内容如下。

几年前，我给团队负责的整个系统写过一些公共库，有一次同事发现这个库里存在一个 Bug，并告诉了我出错的现象。然后我便去修复这个 Bug，最终只修改了一行代码，但发现一上午就这么过去了。

一上午只修复了一个 Bug，而且只改了一行代码，到底发生了什么？时间都去哪里了？以前觉得自己写代码很快，怎么后来越来越慢了？我认真地思考了这个问题，开始认识到我的编程方式和习惯在那几年已经慢慢发生了变化，形成了明显的两个阶段的转变。这两个阶段是：

• 写得粗放，写得多
• 写得精益，写得好

最近由于一行单元测试代码没有写 Assert 断言，导致了项目在 CI 过程中没有通过，于是遭到了某位同事的吐槽，在修改我的代码后写上了一句提交信息。

我想，做为技术人，修改这条 Commit 信息还是不难的，于是我通过本文介绍的技巧完成了修改，效果如下：

其实修改历史提交信息很简单。

熟悉 HTTP 协议的同学都知道，ORS 是 HTTP 协议中的一种安全策略，全称是 Cross-origin resource sharing，中文名称是跨域资源共享，是一种让受限资源能够被其他域名的页面访问的一种机制。

下图描述了 CORS 机制。

本文来自我最近正在学习的课程，极客时间郭东白的专栏文章。这篇文章让我在架构悟道上有所觉悟，分享给你，希望对你有所启发，部分内容我作了精简，内容如下。

人类的各种活动都要遵循事物的客观生命周期。不论是农业社会种田打渔，还是资本社会投资创业，行动太早或太晚，都会颗粒无收。技术也一样，也有自己的生命周期。而我们作为架构师，如果看不清技术的生命周期，那么所设计的架构就没法儿向更有生命力的新技术借力，自己的职业生涯也会受限。

在架构设计的过程中，架构师会有一个相对确定的商业和技术选择空间。在这个选择的空间内，架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期。这个时候，我们就需要看准技术趋势，选择已经有规模优势或者是即将有规模优势的技术，而不是选择接近衰老期的技术。

但是啊，有的人能够看准一个技术的生命周期， 而有些人却做不到。为什么？

这里总结了23种设计模式的结构图及定义，样例代码在 Github：studeyang/design-pattern。

一、创建型模式

1.1 简单工厂模式

这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。

优化查询语句的性能是 MySQL 数据库管理中的一个重要方面。在优化查询性能时，选择正确的索引对于减少查询的响应时间和提高系统性能至关重要。但是，如何确定 MySQL 的索引选择策略？MySQL 的优化器是如何选择索引的？

在这篇《索引失效了？看看这几个常见的情况！》文章中，我们介绍了索引区分度不高可能会导致索引失效，而这里的“不高”并没有具体量化，实际上 MySQL 会对执行计划进行成本估算，选择成本最低的方案来执行。具体我们还是通过一个案例来说明。

案例

还是以人物表为例，我们来看一下优化器是怎么选择索引的。

建表语句如下：

1
2
3
4
5
6
7
8
9
10
11

CREATE TABLE `person` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(64) NOT NULL,
  `score` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_name_score` (`name`,`score`) USING BTREE,
  KEY `idx_age` (`age`) USING BTREE,
  KEY `idx_create_time` (`create_time`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;

然后插入 10 万条数据：

1
2
3
4
5
6
7
8
9
10

create PROCEDURE `insert_person`()
begin
    declare c_id integer default 3;
    while c_id <= 100000 do
	    insert into person values(c_id, concat('name',c_id), c_id + 100, c_id + 10, date_sub(NOW(), interval c_id second));
	    -- 需要注意，因为使用的是now()，所以对于后续的例子，使用文中的SQL你需要自己调整条件，否则可能看不到文中的效果
	    set c_id = c_id + 1;
    end while;
end;
CALL insert_person();

索引是 MySQL 数据库中优化查询性能的重要工具，通过对查询条件和表数据的索引，MySQL可以快速定位数据，提高查询效率。但是，在实际的数据库开发和维护中，我们经常会遇到一些情况，导致索引失效，从而使得查询变得非常缓慢，甚至无法使用索引来优化查询，这会严重影响系统的性能。那么，是什么原因导致了索引失效呢？

常见的情况有：

• 索引中断
• 数据类型不匹配
• 查询条件使用函数操作
• 前模糊查询
• OR 查询
• 建立索引时使用函数
• 索引区分度不高

下面我通过实际的例子来具体说说。假设现在我们有一张人物表，建表语句如下：

1
2
3
4
5
6
7
8

CREATE TABLE `person` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(64) NOT NULL,
  `score` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;

简介：传统的消息队列对业务方提出了更高的要求，我们期望提供的是一种以业务为重心的，面向服务的解决方案。

这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。

我们在上次分享中聊到了领域驱动设计和微服务，在 DDD 中有一个术语叫做领域事件，例如订单模型中的订单已创建、商品已发货。领域事件会触发下一步的业务操作，如果领域事件发生在微服务内，可以通过观察者模式很容易实现消息监听并处理。

如果发生在微服务之间，则需引入事件总线或者消息中间件。

这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。

如何理解领域驱动设计？

随着微服务的兴起，你一定听说过领域驱动设计 DDD（domain-driven design），但是如果把它当成一个术语来看，似乎有点抽象。这到底是个什么玩意？

别急，你肯定还听说过测试驱动开发（TDD, Test-driven development）吧？

这是个什么概念呢？就是说开发的过程中要测试先行，倡导先写测试程序，然后编码实现。开发是目的，测试是辅助，所以叫做测试-驱动-开发，我们应该把它拆成 3 个术语来理解。

所以，对于领域驱动设计，设计是目的，领域才是辅助。想要设计一个软件，但是由于业务太过复杂，设计过程难以进行。这时，使用领域的思想来辅助设计。