gt15207

TiddlyWiki ，本地的 html ，很方便写，也很方便 search

做了一个肛周脓肿手术，期间肠镜 /手术前喝泻药，再加手术后不敢多吃，2 个星期减了 15 斤...

我大学刚毕业的时候曾在校友会上碰到一个退休的老爷子。
他问我了一个问题：你还在学英语吗？
他解释了一下为什么问这个问题，他说人需要终身学习的。
他举例说他在退休后开始学日语；虽然他学习了日语也不靠它来挣钱。

对于学习这件事来说，我现在有了一个认识：
我 24 岁的时候是一条咸鱼
因为没有持续学习 /提升自己
20 年过去了，我现在还是一条咸鱼。

如果从 24 岁开始我每天背一个英语单词，
那么现在理论上我的英语词汇量应该到 7200 了。

抱歉，审题审错了，原来要用序列号做主键呀。Oracle 的主键默认会建成一个索引，所以它和 MySQL innodb 应该是类似的情况。但根据我个人的经验，在 Oracle 里用 sequence 做主键比用 uuid 做主键更容易造成热块争用；这和那个 MySQL 帖子里讲的恰恰相反 - 囧。

纯维护 DBA ，所以不知道 Oracle 里应用使用 uuid 是否存在什么问题；可能之前碰到过问题，但不知道应用使用的是 uuid 。不过有一个万金油的方案，就是搭建一个 POC 测试，尽量模拟应用行为，并做压力测试，看看 Oracle 能不能 hold 住。

至于使用序列：
1. 在 Real Application Cluster 下使用序列会出现多个实例里拿的序列号不是严格递增的情况。因为序列一般在每个 RAC 节点上有 cache ，比如节点一 cache 了序列号 1 到 20, 然后节点二 cache 了 21 到 40 。节点二上的应用初始拿到的序列号就会是 21 ；而此时序列号 20 大概率还没分给应用使用呢（也就是序列号 21 先于 20 被分配了）
2. 在序列号被默认 cache 的情况下，如果 DB crash ，则内存中 cache 住的序列号会丢失。也就是丢掉的序列号不会被分配给应用了。
3. 如果关闭序列号的 cache 功能，则分配序列号的动作会变慢（ Real Application Cluster/RAC 下此时需要节点间同步，所以分配序列号动作会变得更慢)

一般如果应用需要严格递增，而且不能缺号的序列号，是不应该使用 Oracle 自带的 sequence 技术的。

买个大金戒指，以后不管到哪里，还能用上（比如战乱啊，也许可以当船票）。