diff --git a/ch6-cloud/ch6-07-dist-id.md b/ch6-cloud/ch6-07-dist-id.md
index d1d581b..7039fb5 100644
--- a/ch6-cloud/ch6-07-dist-id.md
+++ b/ch6-cloud/ch6-07-dist-id.md
@@ -43,10 +43,22 @@ Twitter 的 snowflake 算法是这种场景下的一个典型解法。先来看
 
 timestamp，datacenter_id，worker_id 和 sequence_id 这四个字段中，timestamp 和 sequence_id 是由程序在运行期生成的。但 datacenter_id 和 worker_id 需要我们在部署阶段就能够获取得到，并且一旦程序启动之后，就是不可更改的了(想想，如果可以随意更改，可能被不慎修改，造成最终生成的 id 有冲突)。
 
-一般不同数据中心的机器，会提供对应的获取数据中心 id 的 api，所以 datacenter_id 我们是可以在部署阶段简单地获取到的。而 worker_id 是我们逻辑上给机器分配的一个 id，这个要怎么办呢？比较简单的想法是由能够提供这种自增 id 功能的工具来支持，比如 MySQL:
+一般不同数据中心的机器，会提供对应的获取数据中心 id 的 api，所以 datacenter_id 我们可以在部署阶段轻松地获取到。而 worker_id 是我们逻辑上给机器分配的一个 id，这个要怎么办呢？比较简单的想法是由能够提供这种自增 id 功能的工具来支持，比如 MySQL:
 
+```shell
+mysql> insert into a (ip) values("10.1.2.101");
+Query OK, 1 row affected (0.00 sec)
+
+mysql> select last_insert_id();
++------------------+
+| last_insert_id() |
++------------------+
+|                2 |
++------------------+
+1 row in set (0.00 sec)
 ```
-```
+
+从 MySQL 中获取到 worker_id 之后，就把这个 worker_id 直接持久化到本地，以避免每次上线时都需要获取新的 worker_id。让单实例的 worker_id 可以始终保持不变。
 
 当然，使用 MySQL 相当于给我们简单的 id 生成服务增加了一个外部依赖。依赖越多，我们的服务的可运维性就越差。