dp[i] = dp[i-1] + dp[i-5+1] - dp[i-10+1]

TCPB 向 TCPA 发送 Last ACK，抵达需要 1 个 MSL，抵达后 TCPA 从 FIN_WAIT_2 变成 TIME_WAIT 状态，并且返回 ACK 对 TCPB 进行响应，如果一切正常，那么再过 1 个 MSL 之后就会抵达 B

假如 TCP A 的这个 ACK 没有抵达 B，那么对于 B 来说，B 发送了一个 Last ACK 出去，处于 CLOSE_WAIT 状态，等待 A 的 ACK 回来，如果 B 在发了 ACK 后过了 2 个 MSL 后没有收到 A 的 ACK，那么就会重新发这个 FIN 报文

A 等待两个 ACK 的目的是在于防止 ACK 在传输过程中丢失，那么对于 B 来说会在 A 等待 1 个 MSL （这时 B 已经等待了两个 MSL ）后重发报文，这个报文过 1MSL 之后内会抵达 A，所以 A 可以在 2 个 MSL 内确认到 B 是否没有接到自己的 ACK

@cst4you 老哥多少钱出啊～

@kokutou 是的 3950x 在发热上甚至还比 3900x 略好，看来你确实没有了解过 Ryzen，既然是小白那就算了吧= =不争了

@kokutou 真是个 ETC...死活不认 算了= =可能你觉得 3950x 和 3900x 差太远吧 你觉得你看法没错就行= =或者你还是自己找找资料和测评吧

https://www.youtube.com/watch?v=J69aiJJEHzQ&t=670s

https://wx2.sinaimg.cn/mw1024/006I4VFqgy1gavtxs3gauj30vy0i144i.jpg

而且我建议你们多了解一下...不是盲目在这里给楼主省
@kokutou
@hjc4869

@kokutou 按你的说法建议 AMD 不要出 5 系主板了，x370 和 b350 不买，花冤枉钱买 4 系？

@kokutou 如果你说的超频不包含 PBO，那其实不行的，供电如果开了 PBO 会非常热（个人实测，已经换掉了）
如果你说的是 PBO 关掉直接按默认频率运行那确实是可以的，但是这样已经没有任何升级空间了

按照用 5 年算，如果楼主现在买个好一点的旗舰 x470 或者正常水准的 x570，可以过 4 年升级 16c32t 的 3950x，非常理想的路线....不要为了主板几百块锁死自己的扩展升级

@hjc4869 建议去 CHH 看看各主板供电规格的分析，还 3950x，如果住北极可能可以吧，供电模块会非常热的（ 120 度这种，不是过家家的七八十度）

上面说得没错，非蠢即坏

@ghostheaven 楼主这些内容和数据结构与算法，有什么联系吗

bytedance-hire.me
路过看看～～

拆分开的后果就是要分别更新，分别读取
放在一起的后果就是 Update 的时候会对这张表频繁操作，静态数据本来不需要经常变但是行数据还是经常有锁在上面阻塞

TL;DR:
看业务和数据量，未来 1 年内如果还是小业务、数据量少（没到上百万千万上亿）实际上就放一起最方便；
预估到未来 1 年内数据量增长比较大的话提前垂直拆分开，动静数据分离比较合适

夯实基础，多陪家人

早知道就把标题改成散列 ID 的影响了...大家反正都不看内容只看标题..

@lolizeppelin 为什么，不是特别了解，但是 InnoDB 应该表达得比较明确了个人认为？据我所知 InnoDB 都是 B+树的索引组织表，如果不是的话请举出具体反例

做了个简单的小测试，乱序 32 位 MD5 ID vs 顺序 32 位字符串整数 ID vs 子增 ID 导致的页分裂次数，50000 条数据 INSERT：

```SQL
mysql> SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME
LIKE '%split%';
+---------------------------------+-------+
| NAME | COUNT |
+---------------------------------+-------+
| index_page_splits | 406 |
+---------------------------------+-------+
1 rows in set (0.00 sec)

mysql> SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME
LIKE '%split%';
+---------------------------------+-------+
| NAME | COUNT |
+---------------------------------+-------+
| index_page_splits | 288 |
+---------------------------------+-------+
1 rows in set (0.00 sec)


mysql> SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE '%split%';
+---------------------------------+-------+
| NAME | COUNT |
+---------------------------------+-------+
| index_page_splits | 193 |
+---------------------------------+-------+
1 rows in set (0.00 sec)
```

@levelworm 这东西怎么会有啥教材，有教材无非也就是抄手册上的内容再复述一遍
https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html

当然偶尔也会有像姜承尧这种大牛出来写书，不过极少极少，至少到目前为止就 1 本

@encro 但是要考虑到就算是 UUID 也可以做成区间有序的，这样同样可以减少页的分裂

@wysnylc 其实这个 topic 的重要问题是在于 UUID 如何影响的，分布式也好，单点也好，都没有关系，需要找到一种方案减少数据页分裂后导致的碎片和散列数据对 Buffer Pool 的影响。。。其实应该关注文章内容，而不是标题。。。