1. Algorithm 一道算法题

本周算法题为添加与搜索单词 - 数据结构设计

本题的思想一是使用 trie 树进行前缀匹配，而是在碰到.时使用深度遍历进行匹配

2. Review 阅读一篇英文文章

First things first: When do we write our tests? Writing tests before we write our software has several benefits. In particular, it gives us an agreed-upon definition of what success looks like.1

首先要明确：我们何时编写测试？在编写软件之前编写测试具有多个好处。特别是，它为我们提供了关于成功看起来像什么的共识定义。

When doing new software development, we strive to do storytest-driven development by first automating a suite of customer tests that verify the func- tionality provided by the application. To ensure that all of our software is tested, we augment these tests with a suite of unit tests that verify all code paths or, at a minimum, all the code paths that are not covered by the customer tests. We can use code coverage tools to discover which code is not being exercised and then retrofit unit tests to accommodate the untested code.2

在进行新软件开发时，我们努力进行故事测试驱动的开发，首先自动化一套客户测试，用于验证应用程序提供的功能。为了确保所有软件都经过测试，我们使用一套单元测试来验证所有代码路径，或者至少验证所有客户测试未覆盖的代码路径。我们可以使用代码覆盖工具来发现未被执行的代码，然后追加单元测试以适应未测试的代码。

By organizing the unit tests and customer tests into separate test suites, we ensure that we can run just the unit tests or just the customer tests if neces- sary. The unit tests should always pass before we check them in; this is what we mean by the phrase “keep the bar green.” To ensure that the unit tests are run frequently, we can include them in the Smoke Tests [SCM] that are run as part of the Integration Build [SCM]. Although many of the customer tests will fail until the corresponding functionality is built, it is nevertheless useful to run all the passing customer tests as part of the integration build phase—but only if this step does not slow the build down too much. In that case, we can leave them out of the check-in build and simply run them every night. We can ensure that our software is testable by doing test-driven development (TDD).

通过将单元测试和客户测试组织成单独的测试套件，我们确保可以根据需要运行仅单元测试或仅客户测试。在将其提交之前，单元测试应始终通过；这就是我们所说的“保持绿条”的含义。为了确保频繁运行单元测试，我们可以将它们包括在集成构建的一部分运行的“冒烟测试”中。尽管在构建相应功能之前，许多客户测试将失败，但仍然有必要在集成构建阶段运行所有通过的客户测试，但前提是此步骤不会使构建过程变慢太多。在那种情况下，我们可以将它们从提交构建中排除，只需每晚运行它们。

That is, we write the unit tests before we write the code, and we use the tests to help us define the software’s design. This strategy helps concentrate all the business logic that needs verification in well-defined objects that can be tested independently of the database.

我们可以通过进行测试驱动的开发（TDD）来确保我们的软件是可测试的。也就是说，我们在编写代码之前编写单元测试，并使用这些测试来帮助我们定义软件的设计。这种策略有助于集中所有需要验证的业务逻辑，将其放在可以独立于数据库进行测试的明确定义的对象中。

3. Techniques/Tips 分享一个小技巧

MySQL 在通过 order by 排序时，如果不是索引字段，那么性能损耗还蛮大的，首先看 sort_buffer_size 是否足够大，如果足够大，那么直接选择全序列排序，将结果放入 sort_buffer 排序后返回，如果 sort_buffer_size 大小不够，那么会选择 rowid 排序，在没有使用临时表的情况下，将带排序字段和 rowid 放入临时文件中通过归并排序得到结果，然后根据 rowid 回表查询得到最终结果。如果有使用临时表，如果 sort_buffer_size 大小足够容纳临时表，那么会选用 memory 存储引擎，否则会选用 innodb 存储引擎，如果选用的是 memory 存储引擎，那么会直接选用 rowid 排序，因为数据都在内存的临时表中，回表操作对性能影响不大，如果是使用 innodb 存储引擎，那么会判断结果集大小是否大于 sort_buffer_size，如果大于，使用归并排序，否则使用优先队列（堆排序）

4. Share 分享一个观点

在学习 MySQL 时，要有一个中心，即 MySQL 的设计思想是如何减少磁盘操作，有了这个中心思想，MySQL 很多设计就能想得通了，比如上面的排序思想，内存狗就在内存排，不够就使用磁盘排序，内存排序如果有使用临时表，还可以通过优先队列（堆排序）进行优化