关于本博

find me on twitter: @plantegg

Github: 欢迎star

关注基础知识，一次把问题搞清楚，从案例出发深挖相关知识。

以前觉得自己一看就懂，实际是一问就打鼓，一用就糊涂。所以现在开始记录并总结再联系案例，一般是先把零散知识记录下来（看到过），慢慢地相关知识积累更多，直到碰到实践案例或是有点领悟到于是发现这块知识可以整理成一篇系统些的文章（基本快懂了）。

“技术变化太快，容易过时”，我的看法是网络知识、操作系统、计算机原理等核心概念知识的寿命会比你的职业生涯还长。这些都是40岁之后还会还会很有用

如何在工作中学习 所有方法我都记录在这篇文章中了，希望对你能有所帮助。

所有新文章从这里可以看到，即使再简单的一篇总结我可以持续总结三五年，有新的发现、感悟都是直接在原文上增减，不会发表新的文章。

为什么写博客而不是公众号，我见过20年前的互联网，深度依赖搜索引擎，所以还是喜欢博客。另外技术类文章更适合电脑阅读（随时摘录、实验）

精华文章推荐（2021年前）

在2010年前后MySQL、PG、Oracle数据库在使用NUMA的时候碰到了性能问题，流传最广的这篇 MySQL – The MySQL “swap insanity” problem and the effects of the NUMA architecture http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/ 文章描述了性能问题的原因(文章中把原因找错了)以及解决方案：关闭NUMA。 实际这个原因是kernel实现的一个低级bug，这个Bug在2014年修复了https://github.com/torvalds/linux/commit/4f9b16a64753d0bb607454347036dc997fd03b82，但是修复这么多年后仍然以讹传讹，这篇文章希望正本清源、扭转错误的认识。

CPU的制造和概念 从最底层的沙子开始用8篇文章来回答关于CPU的各种疑问以及大量的实验对比案例和测试数据来展示了CPU的各种原理，比如多核、超线程、NUMA、睿频、功耗、GPU、大小核再到分支预测、cache_line失效、加锁代价、IPC等各种指标（都有对应的代码和测试数据）。

《Intel PAUSE指令变化是如何影响自旋锁以及MySQL的性能的》 从一个参数引起的rt抖动定位到OS锁等待再到CPU Pause指令，以及不同CPU型号对Pause使用cycles不同的影响，最终反馈到应用层面的rt全过程。在MySQL内核开发的时候考虑了Pause，但是没有考虑不同的CPU型号，所以换了CPU型号后性能差异比较大

10倍性能提升全过程 在双11的紧张流程下，将系统tps从500优化到5500，从网络到snat、再到Spring和StackTrace，一次全栈性能优化过程的详细记录和分析。

就是要你懂TCP–半连接队列和全连接队列：偶发性的连接reset异常、重启服务后短时间的连接异常，通过一篇文章阐明TCP连接的半连接队列和全连接队大小是怎么影响连接创建的，以及用什么工具来观察队列有没有溢出、连接为什么会RESET

就是要你懂TCP–性能和发送接收Buffer的关系：发送窗口大小(Buffer)、接收窗口大小(Buffer)对TCP传输速度的影响，以及怎么观察窗口对传输速度的影响。BDP、RT、带宽对传输速度又是怎么影响的

就是要你懂网络–一个网络包的旅程：教科书式地阐述书本中的路由、网关、子网、Mac地址、IP地址是如何一起协作让网络包最终传输到目标机器上。 同时可以跟讲这块的RFC1180比较一下，RFC1180 写的确实很好，清晰简洁，图文并茂，结构逻辑合理，但是对于90%的程序员没有什么卵用，看完几周后就忘得差不多，因为他不是从实践的角度来阐述问题，中间没有很多为什么，所以一般资质的程序员看完当时感觉很好，实际还是不会灵活运用

国产CPU和Intel、AMD性能PK 从Intel、AMD、海光、鲲鹏920、飞腾2500 等CPU在TPCC、sysbench下的性能对比来分析他们的性能差距，同时分析内存延迟对性能的影响

从网络路由连通性的原理上来看负载均衡lvs的DR、NAT、FullNAT到底搞了些什么鬼，以及为什么要这么搞，和带来的优缺点：《就是要你懂负载均衡–lvs和转发模式》

LVS 20倍的负载不均衡，原来是内核的这个Bug，这个内核bug现在还在，可以稳定重现，有兴趣的话去重现一下，然后对照源代码以及抓包分析一下就清楚了。

就是要你懂TCP–握手和挥手，不是你想象中三次握手、四次挥手就理解了TCP，本文从握手的本质–握手都做了什么事情、连接的本质是什么等来阐述握手、挥手的原理

nslookup OK but ping fail–看看老司机是如何解决问题的，解决问题的方法肯定比知识点重要多了，同时透过一个问题怎么样通篇来理解一大块知识，让这块原理真正在你的只是提示中扎根下来

如何在工作中学习 一篇很土但是很务实可以复制的方法论文章。不要讲举一反三、触类旁通，谁都知道要举一反三、触类旁通，但是为什么我总是不能够举一反三、触类旁通？

举三反一–从理论知识到实际问题的推导 坚决不让思路跑偏，如何从一个理论知识点推断可能的问题

性能相关（2015-2018年）

就是要你懂TCP–半连接队列和全连接队列 偶发性的连接reset异常、重启服务后短时间的连接异常

就是要你懂TCP–性能和发送接收Buffer的关系：发送窗口大小(Buffer)、接收窗口大小(Buffer)对TCP传输速度的影响，以及怎么观察窗口对传输速度的影响。BDP、RT、带宽对传输速度又是怎么影响的 发送窗口大小(Buffer)、接收窗口大小(Buffer)对TCP传输速度的影响，以及怎么观察窗口对传输速度的影响

就是要你懂TCP–性能优化大全

就是要你懂TCP–TCP性能问题 Nagle算法和delay ack

10倍性能提升全过程 在双11的紧张流程下，将系统tps从500优化到5500，从网络到snat、再到Spring和StackTrace，看看一个性能全栈工程师如何在各种工具加持下发现各种问题的。

CPU系列文章（2021年完成）

CPU的制造和概念

十年后数据库还是不敢拥抱NUMA？

[Intel PAUSE指令变化是如何影响自旋锁以及MySQL的性能的](/2019/12/16/Intel PAUSE指令变化是如何影响自旋锁以及MySQL的性能的/)

[Perf IPC以及CPU性能](/2021/05/16/Perf IPC以及CPU利用率/)

CPU性能和CACHE

[CPU 性能和Cache Line](/2021/05/16/CPU Cache Line 和性能/)

AMD Zen CPU 架构 以及 AMD、海光、Intel、鲲鹏的性能对比

Intel、海光、鲲鹏920、飞腾2500 CPU性能对比

网络相关基础知识（2017年完成）

就是要你懂网络–一个网络包的旅程

通过案例来理解MSS、MTU等相关TCP概念

就是要你懂TCP–握手和挥手

wireshark-dup-ack-issue and keepalive

一个没有遵守tcp规则导致的问题

[kubernetes service 和 kube-proxy详解](/2020/09/22/kubernetes service 和 kube-proxy详解/)

DNS相关

就是要你懂DNS–一文搞懂域名解析相关问题

nslookup OK but ping fail

Docker中的DNS解析过程

windows7的wifi总是报DNS域名异常无法上网

LVS 负载均衡

就是要你懂负载均衡–lvs和转发模式

就是要你懂负载均衡–负载均衡调度算法和为什么不均衡

网络工具

就是要你懂Unix Socket 进行抓包解析

就是要你懂网络监控–ss用法大全

就是要你懂抓包–WireShark之命令行版tshark

netstat timer keepalive explain

Git HTTP Proxy and SSH Proxy

釜底抽薪——中国真正的危机

来源：YouTube 视频（老梁评论节目）
链接：https://www.youtube.com/watch?v=cqY3hyxDu9o
核心主题：中国面临的不是金融危机，而是财政危机；年轻人的”不接盘”正在釜底抽薪

一、核心论点：中国怕的不是金融危机，而是财政危机

视频开篇即提出一个判断：中国真正的风险不在金融领域，而在财政领域。理由有三：

1. 庞大的官僚体系高度依赖财政——党政机关、维稳系统、国计民生系统全部需要财政资源维系，一天没钱就运转不了。
2. 中央集权的资源分配模式——权力自上而下分配资源，权力越集中，维系权力的财政成本越高。上面集权，就必须为下面兜底。
3. 吃财政饭的人数量庞大——不仅是公务员和事业单位，大量民企、个体户的收入也间接依赖政府投资和财政安排（给政府送菜、承包工程、服务外包等）。

二、财政危机的七大征兆

视频列举了判断财政危机是否来临的明显标志：

视频特别指出一个”尚未发生的标志”：维稳系统（公安、网信、监控）人员的工资尚未被削减——如果这一天到来，意味着财政危机已全面爆发。

现阶段的判断：政府未必有钱继续”治理”社会，但依然有钱”控制”社会。

三、从土地财政到债务财政

视频梳理了财政模式的演变：

• 过去 20-30 年：土地财政 —— 政府卖地 → 房价预期上涨 → 下一块地更值钱 → 财政充裕。本质是”卖未来的土地”。
• 当下：债务财政 —— 土地卖不出去 → 靠借债维系运转 → 借新还旧。本质是”卖未来政府的信用”。

关键数据（视频引用）：

• 中央国债：约 41 万亿
• 地方债务：约 55 万亿
• 合计公开债务：约 96 万亿
• 加上隐性债务、银行坏账等：估算可能接近 200 万亿

视频强调：高负债本身不可怕，可怕的是丧失信心。引用温家宝的话”信心比真金白银更重要”。

四、年轻人的”六不”——釜底抽薪

视频的核心论述是：年轻人正在以理性选择的方式，系统性地退出国家财政体系的运转链条。这不是政治反对，而是基于生活现实的冷静判断。

1. 不买房

• 房价不可能回到 2019-2021 高点，社会共识已形成
• 421 家庭结构下，长辈留下的房产够用
• 消费降级下，二手房完全可以接受
• 土地财政的恶性循环：卖不出地 → 政府没钱 → 老百姓也没钱 → 更不消费 → 更买不了房

2. 不结婚

• 计划生育后遗症：适龄男性比女性多约 3600 万
• 彩礼回潮不是道德退步，而是供需失衡的市场化结果
• 经济下行叠加高结婚成本，很多年轻男性选择单身

3. 不生孩子

• 人口红利消失，劳动力持续减少
• 养老和医疗体系难以为继

4. 不创业

• “大众创业、万众创新”的口号已被现实击碎
• 2026 年上半年：倒闭 205 万家企业，新开 165 万家，净减少 40 万家
• 经济下行期创业 ≈ 败家，家长宁愿孩子啃老也不愿孩子创业

5. 不炒股

• A 股出现结构性分化：国家战略清单上的企业涨，其他大面积下跌
• 视频以宇树科技为例：8 月 19 日上市，发行价 150 元，最高冲到 1100 元，三天内跌 40%
• A 股从诞生起就是为国企/战略企业输血的工具，散户是韭菜
• 越来越多人发誓不再碰 A 股

6. 不交社保（最致命）

• 灵活就业人群中数千万人断缴或不缴社保
• 年轻人算得很清楚：替代率低 + 通胀贬值 + 未来供养人口减少 = 不划算
• 缴费年限延长（15→20 年）、基数提高、比例提升，进一步劝退

视频的核心比喻：这”六不”就是年轻人从政府这口大锅底下把柴火抽走——釜底抽薪。

五、从增量分配到存量争夺

视频还指出一个并行的结构性变化：

• 过去：经济增长期，蛋糕不断做大，增量分配→各方都能获利→制度矛盾被掩盖
• 现在：蛋糕做不大了，增量分配完毕→各方争夺存量
  • 中央 vs 地方
  • 银行 vs 财政
  • 国企 vs 民企
  • 权贵集团之间
  • “公共利益部门化，部门利益法治化”现象加剧

在存量争夺中，老百姓始终是弱势群体，没有资格和能力参与争夺。即使改革到来，离权力最近的人也最先获益（类比苏联解体后的寡头）。

六、结论

视频最终的呼吁：

扎扎实实做好民生，少谈宏大叙事，多讲民生福祉。
民生是最扎实的意识形态。

引用结尾：“四面湖山归眼底，万家忧乐到心头。”

核心观点可信度校验

以下为独立核查结果，对视频中涉及的具体数据和事实逐一验证。

1. 政府债务规模 —— 部分可信（数字偏高 10-20%）

来源：IMF、Trading Economics、Wikipedia “National debt of China”

2. 公务员降薪 —— 可信度较高

• 土地出让收入 2023→2025（4.87→4.15 万亿）两年降幅约 15%，属于缓降
• 2026 年加速恶化：上半年仅 9,778 亿（同比 -31.5%，对比 2025H1 的 14,271 亿）。考虑到土地出让的强季节性（2025 年 H2 是 H1 的 1.9 倍），若下半年维持同比 -31.5% 则全年约 2.84 万亿，降幅约 -37%；从 2021 年峰值 8.7 万亿算起，五年缩水约 67%
• 土地出让金曾占地方综合财力 30-40%，收入断崖直接冲击支付能力
• 2022 年起 Bloomberg、SCMP、Reuters 报道了浙江、广东、江苏、上海等地降薪现象
• Bloomberg 2024 年 7 月专题报道退回绩效奖金
• 2026 年 8 月 SCMP 报道副总理丁薛祥提出财政重置方案，侧面印证

判断：大方向有充分财政数据支撑。退回年终奖是部分地区个案，非普遍政策。

3. 追缴历史税款 / 非税收入增长 —— 可信度高（硬证据）

中国财政部官方数据：

• 2024 年非税收入暴增 25.4%，一年多出约 9000 亿元，几乎完全对冲了税收的下降（同期税收 -3.4%、土地出让 -16%）
• 国务院 2024 年专门发文禁止”逐利性执法”和违规异地执法
• 最高法 2025 年 2 月要求规范”趋利性执法”

判断：政府自己发文禁止，说明现象确实严重。非税收入增长不全来自”追缴”，也包括罚没收入、国有资产处置等渠道，但视频大方向完全成立。

4. 适龄男女比例失衡 3600 万 —— 部分可信

• 2020 年第七次人口普查：男性 7.233 亿 vs 女性 6.884 亿，全年龄段男性多出约 3490 万（与 3600 万偏差约 3%）
• 15-64 岁年龄段：男性多出约 2850 万
• 15-39 岁核心适婚年龄段：男性多出约 985 万
• 堪萨斯大学 2016 年研究指出，”3000 万缺失女性”中有 1000-1500 万可能是延迟户籍登记的统计假象

判断：全年龄段数字基本准确，但视频将此标注为”适龄”有误导性——适婚年龄段的实际差异远小于全年龄段总差异。

5. 2026 年上半年企业倒闭 205 万家 —— 无法验证

• 官方数据（国家市场监管总局，2025 年 1 月）：截至 2024 年底有 1.89 亿个注册市场主体，同比增长 3.1% — 总量仍正增长
• 仅餐饮行业一个行业，2025 年上半年就有 161 万家店关闭
• 中国官方通常不公布注销/倒闭明细数据

判断：找不到权威来源确认这组具体数字。可能来自企查查等商业数据库，但”关门”不等于”注销”，口径不同。

6. 年轻人断缴社保几千万 —— 基本可信（甚至偏保守）

NBS 2025 年统计公报：

• 全国就业人员 7.25 亿
• 工伤保险仅覆盖 3.05 亿（与城镇就业 4.75 亿相差约 1.7 亿）
• 失业保险仅 2.49 亿，不到城镇就业的一半
• 灵活就业总量约 2 亿人（人社部多次公布的数字）

判断：从工伤保险覆盖缺口（~1.7 亿）来看，”几千万”不交或断交社保在数量级上合理，甚至偏保守。

7. 2030 年社保体系崩溃 —— 部分可信，时间点有误

• 最知名预测来自中国社科院 2019 年《中国养老金精算报告 2019-2050》
• 预测城镇职工基本养老保险基金累计结余将在 2027 年前后达峰值，到 2035 年前后结余归零
• 视频说 2030 年，实际应为 2035 年（偏差 5 年）
• “崩溃”用词夸大——结余耗尽不等于体系崩溃，政府仍可通过财政转移支付继续发放
• 2024 年 9 月中国已通过延迟退休法案（男性逐步提至 63 岁），对冲措施在推进

8. 宇树科技上市数据 —— 可信度高

来源：StockAnalysis (688836)、CNN 2026-08-18、BBC 中文 2026-08-19

9. 土地财政→债务财政 —— 可信度高（完整证据链）

2025→2026 上半年同比从 -6.5% 骤降至 -31.5%，加速恶化明显。考虑土地出让的强季节性（2025 年 H2 是 H1 的 1.9 倍），若下半年维持同比 -31.5%，则 2026 全年约 2.84 万亿，较峰值缩水约 67%。同期：

• 财政综合赤字率从 GDP 的 1-2% 飙升至 2024 年 7.7%，2025 年预计 8.5-9%（Rhodium Group）
• 政府债券占银行资产从 2014 年 4.1% 升至 2025 年 14.7%
• Rhodium Group 明确将此描述为 “regime shift”

来源：中国财政部、Reuters、Rhodium Group、Caixin Global、PIIE

总评

整体评价：视频的大方向判断多数有据可查，尤其是财政转型、非税收入暴增、公务员降薪等核心论点有扎实的官方数据支撑。但在具体数字上有向”更严重”方向取整和夸大的倾向（债务规模偏高、社保预测提前 5 年），个别数据无法验证（企业倒闭数据）。作为时事评论节目，整体信息质量中等偏上，核心论证逻辑成立，但观众需注意具体数字的精确性。

“消失”的万亿债务：AI 数据中心影子借贷、GPU 金融化与次贷风险

一、核心摘要

2026 年前 7 个月，美国五大 Hyperscaler（亚马逊、微软、谷歌、Meta、甲骨文）累计发行约 2081 亿美元公司债，是 2020-2024 年均值（280 亿/年）的约 12 倍。但翻开财报，大量债务”凭空消失”了——它们通过 SPV 壳公司、融资租赁、信用担保、未起租合同等至少五种手法，将债务移出资产负债表。

与此同时，五家巨头的股票回购从 2021 Q4 峰值 480 亿美元/季骤降至 2026 Q1 的 46 亿美元（降幅超 90%），所有现金都被导向数据中心建设。按 Epoch AI 模型推算，资本开支年增约 70%、经营现金流年增仅约 23%，两条线在 2026 Q3 交叉——意味着巨头们将”集体返贫”，进入自由现金流为负的时代。

二、五大巨头的”藏债术”详解

2.1 Meta：SPV 壳公司 + 残值担保

Hyperion 项目（路易斯安那州）：

• 通过 7 家名为 “Beignet” 的特拉华州壳公司发行 272.9 亿美元债券
• 票息 6.581%，2049 年到期，完全摊销（相当于 24 年按揭）
• Blue Owl 持股 80%，Meta 持股 20%（仅 23.7 亿美元记入 Meta 负债表）
• Meta 通过子公司 Pelican Leap 签署租约，租金流向壳公司链条用于偿债
• 残值担保上限约 280 亿美元——真正的抵押品是 Meta 本身
• 标普评级 A+（Meta 自身 AA-，降一档）

Sopaipilla 项目（得克萨斯州）：

• 2026 年 7 月定价，发行 125 亿美元，票息 7.534%，2048 年到期
• 贝莱德持股 80%，Meta 持股 20%

不到一年，Meta 表外债务新增近 400 亿美元。

2.2 微软：融资租赁”隐身术”

• 过去两年总债务从 449 亿降至 403 亿（看似减债）
• 但融资租赁负债从 271 亿暴增至 629 亿美元（翻倍）
• 融资租赁 = 名义租、实际买，会计上记入”其他流动/长期负债”，不在”债务”行显示
• 2027 财年起数据中心折旧年限从 15 年延至 25 年

2.3 谷歌：信用衍生品担保

• 不搭壳、不持股，只给第三方数据中心提供付款担保
• 担保规模半年内从 169 亿激增至 438 亿美元
• 会计上记为”信用衍生品”，仅 8.15 亿（不足 2%）进入负债表

2.4 亚马逊：最老实的一家

• 自己借钱自己盖，2026 年 3 月一次性发债 500 多亿
• 但另有 1063 亿租约未进负债表

2.5 甲骨文 Oracle：只签合同

• 签下 2600 亿美元数据中心租约，租期 15-19 年
• 全部尚未起租，一分钱未记入负债表
• 标普 2026 年 7 月降级至 BBB-（距垃圾级一档）
• CDS 利差突破 203 个基点，创 2008 年以来新高

汇总：三层债务全景

三、华尔街的”金融刀法”

3.1 GPU 金融化

• GPU 正成为可抵押、可投资的新资产类别
• CoreWeave GPU 抵押贷款利率从 2023 年的 15% 降至 2026 年 3 月的 5.9%
• 2026 年 8 月黄仁勋宣布联合阿波罗、贝莱德、黑石等 6 家成立 AI 算力融资平台，目标撬动 5000 亿美元第三方资本
• 英伟达承诺为部分项目提供最高 25% 的”残值支持”

3.2 资产证券化（ABS）

• 数据中心租约打包为证券，从 AAA 到 BB 分档出售
• 市场存量约 340 亿，2026 年全年新发行量预计冲至 500 亿

3.3 风险转移（SRT）

• 银行将贷款留在账上，但向私募基金购买”首损保险”
• SRT 已是万亿级市场，越来越多用于 AI 贷款

3.4 私募资本的主导地位

• Blue Owl、Brookfield、PIMCO、黑石、KKR、贝莱德反复出现在各笔大交易中
• 2022 年数据中心并购资金 91% 来自私募资本
• 私募信贷中 AI 相关交易占比从十年前 5% 涨至 20%（按笔数 34%）
• 最终资金来源：养老金和主权基金 → 即纳税人的退休账户

四、核心观点可信度校验

总评：视频整体研究质量很高，9 项核心数据中 6 项完全准确，3 项方向正确但细节有轻微偏差（Blue Owl 的 40% 赎回率仅限科技子基金而非全部基金，这是最大的不精确处）。

五、对纳斯达克大公司的投资风险分析

5.1 五家公司风险画像（2026 年中）

5.2 各公司具体风险

Oracle（风险：极高）

• 资本开支一年内从 212 亿暴增至 557 亿，债务/股本比高达 500%
• 2600 亿未起租合同悬在表外，一旦起租将全部涌入负债表
• 收入规模远小于其他四家，却承担类似量级债务
• 商业模式从”现金牛”转向”大基建”，债权投资人正在重新定价
• 标普降级至 BBB-，保险和养老金等最大买家群体面临内部评级约束
• 投资者关注点：若再降一档至 BB+（垃圾级），将触发大量机构被迫抛售

Meta（风险：中高）

• 表面负债仅约 290 亿，但加上 Hyperion + Sopaipilla 的 400 亿表外 SPV 债务，实际义务远超表面
• 残值担保意味着 Meta 实际上是全额兜底——债务”消失”只是会计处理
• AI 变现路径不清晰，市场对其 capex 态度取决于叙事环境
• 投资者关注点：Meta 不像微软有 Azure 这样清晰的变现引擎；如果 AI 叙事转向，”花钱就是错的”

Amazon（风险：中高）

• 最老实的发债方式（自己借自己盖），但 1063 亿表外租约也不容忽视
• 超额认购倍数从 5.3x 跌至 1.6x，市场胃口在收窄
• 每笔新债都在推高下一笔的地板价
• 投资者关注点：AWS 增速是否能持续覆盖债务成本；发债成本的”阶梯效应”

Alphabet（风险：中）

• 债务/股本比仅 7%（五家最低），AA+ 评级最强
• 但 2026 Q2 自由现金流自 2004 年以来首次转负
• 进行了 2005 年以来首次 840 亿美元股权融资（被市场解读为无法自我融资的信号）
• 信用担保规模半年翻 2.5 倍（169→438 亿），增速惊人
• 投资者关注点：Pichai 本人承认当前支出存在”非理性成分”——CEO 自曝风险是罕见信号

Microsoft（风险：中低，五家中最佳）

• AAA 评级（全球仅两家公司持有此评级），FCF 转负时点最晚（~2028 Q3）
• Azure 增速 43%，backlog 6780 亿（YoY +84%），变现路径最清晰
• 投入资本回报率约 30%，约 3 年可回本
• 但需警惕：629 亿融资租赁藏在”其他负债”里；折旧年限从 15 年延至 25 年是会计美化
• 投资者关注点：若 AI 算力需求放缓，微软庞大的 capex（FY2026 约 1900 亿）将成为沉重包袱

5.3 系统性风险评估

“AI 版次贷”是否成立？

视频中的嘉宾认为目前尚不构成系统性风险，理由：

1. 体量仍小：数据中心债务在万亿级企业债市场中仍是零头
2. 银行参与度低：2008 危机的传导机制是银行杠杆；如今银行监管更紧、杠杆更低，风险主要留在私募信贷体系
3. 终端需求真实存在：Azure 43% 增速、token 消费量持续上涨

但以下风险信号值得警惕：

1. 期限错配：二三十年的债务押在五六年可能过时的 GPU 上。H100 第三年残值仅 45%，但折旧年限被拉长到 6-7 年甚至更长，做空机构估计未来三年行业利润可能被高估 1760 亿美元
2. 圈内循环：Blue Owl 和 PIMCO 一年内在四笔交易中互换了四种角色（股东、债主、竞争者、买家），风险始终在同一个圈子内流转
3. 养老金敞口：最终接盘方是养老金和主权基金——普通人的退休账户
4. AI 收入缺口巨大：Apollo Academy 估算 2025 年 AI 应用收入仅 400-600 亿美元，但到 2030 年需要 1.5-2 万亿/年才能支撑已承诺的 5 万亿+ 资本开支

5.4 投资者行动建议

六、结语

过去 20 年，市场习惯把硅谷科技公司视为轻资产生意——写代码、卖软件、产生现金流、回购股票。但 AI 正在把这套逻辑倒过来：抢芯片、拿电、买地、盖数据中心，再用未来 10-20 年的现金流为今天的建设买单。

科技公司正在变成”算力房地产商”。

资产负债表可以变干净，但风险不会凭空消失——它只是被切开、打包、担保，沿着金融链条分给了不同的人。而这条链条的终点，是普通人的退休账户。

硅谷和华尔街都在押注 AGI 的未来。如果赌对了，这些万亿债务将被 AI 的巨额收入覆盖；如果赌错了，”AI 版次贷”可能不再只是一个比喻。

关键时间窗口：2027-2028 年。 届时约 31% 的 SaaS 贷款到期需要展期，五家巨头的 capex 将全面超过 OCF，而第一批 GPU 抵押贷款也将面临残值检验。这是这场豪赌的第一个真正考验。

七、中国版 Hyperscaler：阿里巴巴与字节跳动的 AI 豪赌

美国五大巨头的”影子借贷”游戏正在太平洋彼岸上演中国版本。阿里巴巴和字节跳动——中国算力竞赛中投入最激进的两家——虽然没有照搬 Meta 式的 SPV 壳公司架构，但各自有一套同样值得关注的”骚操作”。

7.1 阿里巴巴：上市公司的”明牌豪赌”

投入规模

• 2025 年 2 月宣布三年投入 3800 亿元人民币（约 530 亿美元） 用于 AI/云基础设施
• 据 LatePost 报道，2026 年中已考虑将目标上调至 4800 亿元（约 690 亿美元）
• 2026 年 6 月季度单季 capex 约 100 亿美元，年化 ~400 亿美元，较上一财年的 183 亿翻倍

阿里巴巴的”骚操作”

操作一：港股增发”输血”——中国版股权融资

2026 年 8 月，阿里巴巴在港股进行了 102 亿美元的配股融资（CICC/HSBC/Morgan Stanley/UBS 承销），这是阿里自上市以来规模最大的股权融资。与美国巨头们靠发债维持”干净报表”不同，阿里直接稀释股东——更激进，但也更透明。

对比：Alphabet 2026 年进行了 840 亿美元股权融资（2005 年以来首次增发），两家的逻辑一模一样——现金流已经养不起 AI capex 了。

操作二：消费级 GPU 补位——RTX 4090 采购

受美国芯片出口管制限制，阿里巴巴无法大量采购 Nvidia 高端训练芯片。据报道，阿里云曾大量采购消费级 RTX 4090 显卡用于推理场景——用游戏卡跑 AI 推理，是被逼出来的”土法炼钢”。

操作三：可转债零息融资

2025 年 9 月发行了 32 亿美元零息可转债——不用付利息，到期要么还钱、要么转成股票。这是一种把融资成本从”利息”转嫁为”未来股权稀释”的手法，比 Meta 的 6.58% SPV 债便宜得多，但代价是股东最终被稀释。

操作四：AI 模型 97% 降价——烧钱换市场

阿里云将大模型 API 价格降了 97%，与字节豆包、DeepSeek 展开价格战。这不是金融操作，但效果类似——用利润换市场份额，把竞争对手拖入消耗战。

阿里巴巴 vs 美国 Hyperscaler 对比

关键差异：阿里巴巴目前没有采用美国式的 SPV/表外结构。原因可能是：(1) 中国债券市场深度和金融工程成熟度不如美国；(2) 阿里手上仍有约 5210 亿元（755 亿美元） 现金储备；(3) 港股增发在中国市场的接受度比美国更高。但如果 AI capex 继续翻倍，阿里走上类似 Meta 的表外融资之路只是时间问题。

7.2 字节跳动：非上市巨兽的”隐形扩张”

投入规模

• 2025 年实际 AI capex 约 1500 亿元（210 亿美元）
• 2026 年初步计划 1600 亿元（230 亿美元），5 月上调至少 25%
• Bloomberg 2026 年 5 月报道：字节正在讨论 2026 年全年 capex 高达 700 亿美元（4000-5000 亿元）
• 2027 年甚至讨论提升至约 1000 亿美元——直逼 Amazon/Microsoft 的水平

字节跳动的”骚操作”

操作一：非上市 = 天然”表外”

字节跳动最大的”骚操作”就是——不上市。

作为全球估值最高的私有公司（5500 亿美元），字节不需要向公众披露财报、不需要面对华尔街的季度审视、不需要担心评级机构降级。它可以把 2025 年净利润从约 500 亿美元暴跌 70% 以上，而不引发股价崩盘。

对比：Meta 的 capex 加码导致股价被”penalize”；Oracle 被标普降级。字节跳动完全不用担心这些。非上市身份本身就是最强的”藏债”工具——不是藏在表外，而是根本没有”表”需要给外界看。

操作二：双轨芯片策略

• 向 Nvidia 试探性订购约 2 万颗 H200（约 4 亿美元）
• 同时与华为签订约 100 亿元人民币国产 AI 芯片采购合同
• 将更大比例预算分配给国产芯片以对冲地缘风险

这是在美国出口管制下的”两头押注”——既不完全放弃 Nvidia 的性能优势，又不把命运绑在美国政策上。

操作三：海外算力租赁——Opex 替代 Capex

字节跳动在海外采用租赁算力的方式（计入运营费用而非资本支出），使实际算力能力超出 capex 账面数字。TikTok 美国业务已由 Oracle 托管数据。这与微软的融资租赁逻辑类似——真实算力投入比 capex 数字更大。

操作四：豆包生态的流量碾压

豆包（Doubao）2026 年春节后 DAU 突破 2 亿，月活超 3 亿，是中国最大的 AI 聊天机器人。字节用抖音/TikTok 的巨额流量直接导入 AI 产品——这是阿里和百度都没有的优势。流量就是变现保障，也是支撑巨额 capex 的底气。

字节跳动 vs 阿里巴巴对比

7.3 阿里巴巴股票（BABA/9988.HK）风险清单

风险一：自由现金流深度转负（已发生）

FY2026 自由现金流为 -466 亿元（-68 亿美元），较上年正值 739 亿元急转直下。如果 capex 继续翻倍（年化 400 亿美元），FCF 负数状态可能延续至 FY2028 以后。

风险二：分析师降级潮（正在发生）

2026 年 8 月密集降级：

• 摩根大通：降至 Underweight，目标价砍至 $120
• 麦格理：降至 Neutral
• Freedom Capital：降至 Hold，目标从 $180 砍至 $140
• 经营利润同比暴跌 74%，Non-GAAP 净利润下降 67%

风险三：五角大楼黑名单（地缘政治）

阿里巴巴被列入美国国防部 1260H “中国军事关联企业”名单。这不是制裁，但会触发部分机构投资者的强制清仓规则——类似 Oracle 降至垃圾级触发保险基金被迫抛售。

风险四：AI 价格战侵蚀利润

阿里云大模型 API 降价 97% 是一场消耗战。对手是字节跳动（利润率不透明、不受上市公司约束）和 DeepSeek（开源免费）。阿里云 EBITA 利润率仅约 9-12%，远低于 AWS 的 37% 和 Google Cloud 的 33%。

风险五：芯片供应链卡脖子

美国出口管制限制 Nvidia H200 等高端芯片对华出口。虽然华为昇腾芯片可部分替代，但在训练大模型的效率上仍有明显差距。阿里已有采购消费级 RTX 4090 补位的报道——这本身就是供应链脆弱性的信号。

风险六：核心人才流失

Qwen（通义千问）团队关键研究人员流失的报道引发执行力担忧。AI 人才争夺战在中国同样激烈，字节跳动的薪资竞争力和技术氛围对阿里构成持续吸引力。

风险七：股东回报被 AI capex 吞噬

FY2025 回购 119 亿 + 分红 46 亿美元，但 FY2026 的 102 亿港股增发实质上抵消了回购效果——左手回购、右手增发，股东被”空转”。如果 capex 继续加码，回购可能像美国巨头一样被完全砍掉。

风险八：估值锚定失效

市场过去给阿里估值的锚是”现金牛 + 电商垄断 + 云增长”。现在电商利润被 AI capex 和社区团购拖累、云在打价格战、现金流转负——三个锚同时松动。这与 Oracle 从”cash cow”变成”大基建”后被 CDS 市场重新定价的逻辑完全一致。

7.4 小结：中美 AI 豪赌的异同

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

                美国 Hyperscaler              中国 Hyperscaler
                ─────────────────            ─────────────────
金融工程       SPV/ABS/SRT/信用担保           港股增发/可转债/利润再投资
               极其复杂，多层嵌套             相对简单直接
               
透明度         表外操作让真实负债不透明         阿里：上市但中概股折价
                                              字节：非上市，天然黑箱

芯片供应       不受限制                        受美国出口管制严重限制
               GPU 已成可抵押资产              国产替代 + 消费卡补位

风险终端       养老金/主权基金（退休账户）       阿里：港股散户 + 机构
                                              字节：PE/VC 投资人

监管环境       SEC + 评级机构约束               中国证监会 + 政策不确定性
               巴塞尔III/金融稳定理事会         五角大楼黑名单/实体清单

核心相似点     ① 现金流不够花 → 被迫大规模外部融资
               ② 科技公司正在变成"重资产"基建公司
               ③ 都在用未来 10-20 年的假设支撑今天的投入
               ④ 真正的考验都在 2027-2028 年到来

最大的不同：美国巨头的风险通过华尔街的金融链条最终传导到养老金和主权基金，波及普通人退休账户；而中国版的风险更集中——阿里巴巴的风险由港股投资者直接承担，字节跳动的风险则锁定在 PE/VC 和员工期权持有者身上。

最大的相似：无论中美，所有人都在押同一个赌注——AI 的 token 需求将永不放缓。如果这个假设错了，两边都没有退路。

阿里云 ECS 第九代 AMD vs Intel MySQL 性能与性价比对比报告

测试日期: 2026-08-31
测试目的: 对比阿里云第九代 AMD (g9a) 与 Intel (g9i) ECS 在 MySQL 场景下的性能和性价比

TL;DR —— 给没耐心的工程师

一句话结论：同规格同价位段，AMD g9a 在 MySQL OLTP 场景下全面碾压 Intel g9i，性价比优势 20%~35%。

根因：AMD Zen 5 微架构在三个层面领先 Intel Granite Rapids：

1. 流水线更宽：8 宽解码 + 4 load 单元 vs Intel 6 宽 + 3 load → 纯 IPC 高 1 倍
2. 分支预测更准：miss 率低 5~10 倍 → 流水线冲刷惩罚更少
3. 成本更低：chiplet 设计 + TSMC 先进制程 → 同性能价格低 9%

选型建议：除纯写低并发场景外，一律选 AMD g9a。

零、CPU 代际背景

Intel 服务器 CPU 演进

1
2
3
4
5
6

Ice Lake (3代至强)         Sapphire Rapids (4代至强)     Emerald Rapids (5代至强)      Granite Rapids (Xeon 6)
  2021.04                     2023.01                      2023.12                      2024.09
  10nm / 40核                 Intel 7 / 60核               Intel 7 / 64核               Intel 3 / 128核
  DDR4 / PCIe 4.0             DDR5-4800 / PCIe 5.0         DDR5-5600 / PCIe 5.0         DDR5-6400 / PCIe 5.0
  Golden Cove 架构             Golden Cove 架构              Golden Cove（同架构优化）       Redwood Cove 新架构
                                                                                        ↑ 本次测试

Intel Xeon 6982P-C 属于 Granite Rapids 家族（Xeon 6 P-core 系列），2024 年 9 月发布。旗舰 6980P 为 128 核 / 504MB L3 / 500W TDP。阿里云的 6982P-C 是云定制变体，本次 VM 分配 8 物理核 16 线程。

注意：阿里云 g9i 文档标注为”Emerald Rapids”是错误的，lscpu 实际报告 Family 6 Model 173，对应 Granite Rapids。

AMD 服务器 CPU 演进

1
2
3
4
5
6

Milan (3代EPYC)        Genoa (4代EPYC)            Turin (5代EPYC)
  2021.03                2022.11                    2024.10
  7nm Zen 3 / 64核       5nm Zen 4 / 96核            3/4nm Zen 5 / 192核
  DDR4 / PCIe 4.0        DDR5-4800 / PCIe 5.0        DDR5-6000 / PCIe 5.0
  SP3 插槽                SP5 插槽                     SP5 插槽
                                                     ↑ 本次测试

AMD EPYC 9T25 属于 Turin 家族（EPYC 9005 系列），2024 年 10 月发布。”T” 后缀为云厂商定制 SKU。基于 Zen 5 微架构，TSMC 3/4nm 制程。本次 VM 分配 8 物理核 16 线程，位于单个 CCD 内。

两款 CPU 硬件规格对比

架构设计差异：Intel Granite Rapids 采用单片式（monolithic-like）设计，所有核共享一整块 L3；AMD Turin 采用 chiplet 设计，每个 CCD（Core Complex Die）8 核 + 32MB L3 独立封装。VM 的 8 核被分配在单个 CCD 内，只能看到该 CCD 的 32MB L3。

一、测试环境

MySQL 配置

测试参数

• 工具: sysbench 1.0.20 + tsar
• 数据集: 16 表 x 100 万行
• 每场景 30 秒
• 并发: 1, 8, 16, 32, 64, 128 线程
• 压测机: 独立 ECS (10.12.9.40) ，同 VPC

二、性能对比

2.1 点查询 (oltp_point_select) - QPS

AMD 在点查场景全面领先，高并发优势越来越大。128 线程时 AMD 突破百万 QPS，Intel 72 万。

2.2 只读事务 (oltp_read_only) - QPS

AMD 只读场景领先 8%~18%，32 线程时优势最大。

2.3 读写混合 (oltp_read_write) - QPS

读写混合场景 AMD 同样全面领先，高并发差距拉大。

2.4 只写事务 (oltp_write_only) - QPS

只写是唯一 Intel 在中低并发有优势的场景（1~64 线程平均领先 ~5%），但 128 线程时 AMD 反超 14.7%。

三、延迟对比 (95th Percentile)

点查延迟 (ms)

读写混合延迟 (ms)

只写延迟 (ms)

四、CPU 效率对比

以 128 线程点查为例（CPU 利用率最高的场景）：

AMD 每 1% CPU 产出的 QPS 比 Intel 高 44.5%，说明 Zen 5 的 IPC 效率显著优于 Granite Rapids。

五、实测 CPU 频率说明

两台实测运行频率几乎一致（3800 MHz），因此性能差异主要来自 CPU 微架构（IPC）和缓存层级差异，而非频率差。

值得注意的是 Intel 分配了 504MB L3 缓存（宿主机 Xeon 6982P 物理总量的一部分），而 AMD 只分配了 32MB。即便 L3 缓存相差 15 倍，AMD 仍在多数场景领先。

六、性价比分析

月费对比

每万 QPS 成本（月费 / 128线程峰值QPS * 10000）

AMD 在所有场景下每万 QPS 成本都更低，点查场景性价比优势高达 35%。

性价比总结

七、结论与建议

1. 如果追求最高性价比：选 AMD g9a。在 MySQL OLTP 场景下，AMD EPYC 9T25 (Turin/Zen 5) 性能全面超越 Intel Xeon 6982P-C (Granite Rapids)，价格还便宜 9%，综合性价比优势 20%~35%。

2. Intel 的唯一优势场景：纯写入、中低并发（1~64 线程 write_only），Intel 单线程写入 QPS 高 6.7%，8 线程高 11.8%。如果业务以低并发写入为主，Intel 略有优势。

3. 高并发场景 AMD 压倒性优势：128 线程点查 AMD 比 Intel 快 40%，突破百万 QPS 门槛。如果业务并发高，AMD 优势更明显。

4. 频率并非决定因素：两台实测都跑在 3.8 GHz，性能差异主要来自 Zen 5 vs Granite Rapids 的 IPC 差异和内存子系统效率。

八、大数据集测试（16 表 x 1200 万行，数据集 ~53GB > Buffer Pool 40GB）

目的

100 万行数据集完全被 buffer pool 缓存，无法触发磁盘 IO。1200 万行/表使数据集达到 ~53GB，超出 40GB buffer pool 约 13GB，缓存命中率约 75%，会触发显著的随机磁盘读。此场景下 Intel 的 504MB L3 缓存可能发挥更大作用。

8.1 点查询 (oltp_point_select) - QPS

AMD 依然全面领先，128 线程领先 35.6%。Intel 的 504MB L3 并未扭转局面。

8.2 只读事务 (oltp_read_only) - QPS

8.3 读写混合 (oltp_read_write) - QPS

8.4 只写事务 (oltp_write_only) - QPS

只写场景两台都出现了严重的性能抖动（TPS 掉到 0），这是数据集超出 buffer pool 后脏页刷盘导致的。Intel 在低并发写入仍有优势，但 64 线程时 AMD 反超。128 线程两台都抖动剧烈，Intel 因为 L3 更大，在脏页管理上稍有优势。

8.5 大数据集关键发现

8.6 IO 调度器对比：AMD mq-deadline vs none

测试中发现两台 ECS 的磁盘调度器不一致——Intel 是 none（最优），AMD 是 mq-deadline（有额外调度开销）。为排除这个变量，将 AMD 也改为 none 后重新跑了一轮完整测试。

读场景（点查/只读/读写混合）：none 一致快 1.5%~6%

读场景改善幅度稳定在 2%~4%，符合预期——去掉 mq-deadline 的请求排序开销，NVMe 的随机读性能略有提升。

写场景：高并发显著改善，但波动大

低并发写入 none 反而慢了 5%7%（mq-deadline 的请求合并在顺序写时有微量收益），但高并发写入 none 快了 19%27%。不过 64/128 线程写场景两轮都有 TPS=0 的脏页刷盘 stall，大幅差异可能部分来自 stall 发生时间点的随机性。

结论：调度器差异对读场景影响约 2%4%，不改变 AMD vs Intel 的整体结论（AMD 读场景领先 14%40%，调度器差异只是其中的 2~4 个百分点）。NVMe SSD 上推荐统一使用 none。

九、最终综合结论

两轮测试汇总（128 线程峰值 QPS）

性价比最终结论

• AMD g9a 在 OLTP 读密集场景性价比压倒性胜出：性能领先 14%~36%，价格便宜 9%
• 只写大数据集场景双方都受 IO 限制：性能差异取决于磁盘 IO 抖动，不具参考性
• Intel 的 504MB L3 缓存没有成为 killer feature：在 MySQL InnoDB 的 buffer pool 架构下，L3 缓存对性能的边际贡献有限
• CPU 微架构（IPC）是决定性因素：Zen 5 的 IPC 优势在所有读密集场景持续体现

采购建议

十、CPU 基准测试（脱离 MySQL，纯 CPU 能力对比）

测试前已停止 MySQL，确保无其他负载。两台实测频率均为 3800 MHz，频率变量已控制。

10.1 sysbench cpu（素数计算，纯整数运算）

sysbench cpu 是最简单的整数运算测试（判断素数），代码路径极短。AMD 领先超过 50%，直接反映 Zen 5 vs Redwood Cove 的 IPC 差距。

10.2 stress-ng 微架构测试

单位: bogo ops/s (real time)

数据说明：

• matrix 单核 AMD +76%：单核矩阵乘法是最纯粹的 IPC 测试，没有多线程锁竞争干扰。Zen 5 的每周期指令完成量远超 Redwood Cove。
• matrix 全核 Intel +8%：这是 Intel 唯一反超的计算型测试。可能原因：(1) Intel HT 在矩阵运算中的两个逻辑核能更好地共享执行单元；(2) GCC 对 Intel 微架构的编译优化更成熟（-march=native 生成的代码倾向 Intel）。
• vecmath AMD +17%：两者都支持 AVX-512，但 Zen 5 的 SIMD 执行单元吞吐更高。
• cache AMD +97 倍：这个悬殊差距需要解释。stress-ng cache stressor 故意制造工作集超出缓存的场景。Intel 的 504MB L3 是单片式设计，数据在环形总线上搬运的延迟高；当 cache miss 发生时，miss penalty 更大。AMD 的 32MB L3 虽小，但位于单个 CCD 内部，访问延迟低，miss 时直接走内存控制器，路径更短。L3 大不等于快，小而近的缓存在高 miss 率场景反而更高效。
• context switch AMD +7%：上下文切换涉及内核态寄存器保存/恢复、TLB flush，AMD 平均 2,280ns/次 vs Intel 2,450ns/次。对数据库连接切换有参考意义。

10.3 UnixBench 系统综合评分

数据说明：

• Whetstone 浮点 AMD +97%/+107%：Zen 5 重新设计了浮点执行单元，每周期浮点吞吐大幅提升。对科学计算、数据分析类负载意义重大。
• Process Creation AMD +90%/+107%：fork/exec 性能反映内核态内存管理效率，AMD 在 TLB 和页表操作上优势明显。对 PHP-FPM、CGI 类短连接服务有直接影响。
• Pipe Context Switch AMD +132%：管道读写 + 上下文切换的综合性能，AMD 优势最大的单项。
• File Copy 4K 多核 Intel +46%：Intel 唯一大幅领先的子项。大块连续内存拷贝涉及内存控制器和 LLC 的预取优化，Intel 的 8 通道 DDR5 + 巨大 L3 在此场景发挥了作用。但这不是 MySQL 的典型访问模式（MySQL 是随机访问 buffer pool 页，不是顺序大块拷贝）。
• 单核综合 AMD +49.5%，16 核综合 AMD +30%：多核场景优势缩小是正常的——16 线程争用共享资源（内存带宽、缓存行）会稀释单核 IPC 优势。

10.4 CPU 基准测试 vs MySQL 压测的交叉验证

结论：CPU 基准测试（单核 IPC 领先 50%76%）验证了 MySQL 压测的方向，但 MySQL 场景下的实际差距（14%40%）小于纯 CPU 测试。原因：MySQL 的每条 SQL 除了 CPU 计算外，还包含网络协议解析、事务管理、锁、buffer pool 管理等固定开销，这些开销在两个 CPU 上差异较小，稀释了架构差距。

10.5 分支预测微基准测试

测试原理

来自 StackOverflow 史上投票最高的编程问题。测试代码对一个 32768 元素的随机整数数组（值域 0-255）做条件累加：if (data[c] >= 128) sum += data[c]，循环 10 万轮。

唯一变量：数组是否预先排序。排序不影响指令数（两种情况执行的指令总数完全一样），只影响 if 分支的结果序列——排序后前半全不跳、后半全跳（极度可预测），未排序则 50% 随机跳转（难以预测）。

CPU 流水线不会等 if 算完再取下一条指令，而是提前猜方向继续执行。猜对了流水线不停，猜错了必须冲刷重来（浪费 ~20 个时钟周期）。分支预测器越准，流水线效率越高，IPC 越高。

编译选项 -O0（禁止优化），确保 if 分支保留为真实跳转指令（-O2 会被编译器优化成 cmov 条件移动，消除分支）。

测试结果

排序后（分支可预测）

未排序（分支随机 50%，不可预测）

分支 miss 导致的性能惩罚

解读

这组数据揭示了两个层面的差距：

第一层：纯 IPC 差距。 排序后两家 branch-miss 率都是 0.00%（分支完全可预测），但 AMD 仍快 2.35 倍。执行了一模一样的 328 亿条指令，AMD 只用了 73.6 亿个时钟周期，Intel 用了 149.7 亿——AMD 每个周期完成 4.46 条指令 vs Intel 2.19 条。这是 8 宽解码 + 4 个 load 单元 vs 6 宽解码 + 3 个 load 单元的架构硬差距。

第二层：分支预测器准确率碾压。 面对 50% 随机分支，Intel 猜错 15.05%（每 6-7 次猜错一次），AMD 只猜错 1.59%（每 63 次猜错一次）。虽然数组值是随机的，但每轮循环遍历顺序不变——AMD 的预测器能”记住”32768 个分支位置各自的跳转方向，Intel 的预测器在这个规模上记不住。

对 MySQL 的启示：MySQL 的 B-tree 遍历、WHERE 条件过滤、行级锁判断全是分支密集操作。AMD Zen 5 的分支预测器在”有模式但不完全确定”的分支场景中能比 Intel 少犯 10 倍错误，这是 MySQL 点查 AMD 快 40% 的微架构根因之一。

10.6 MySQL 点查实战 IPC 对比（perf stat 采集 mysqld 进程）

上面的分支预测测试用的是独立微基准程序。这里直接用 perf stat 挂载到 mysqld 进程上，测量真实 MySQL 点查负载下的 IPC 和分支预测数据。

测试方法：sysbench oltp_point_select 120 秒持续压测，同时 perf stat -p <mysqld_pid> 采集 125 秒。数据集 16 表 x 1200 万行（超出 buffer pool，有磁盘 IO）。

32 线程点查

128 线程点查

解读

这是整个报告中最核心的一组数据——不是微基准、不是合成测试，而是真实 MySQL 进程跑真实 SQL 时的硬件计数器。

1. IPC 在真实 MySQL 负载下差距依然巨大：32 线程 AMD IPC 0.59 vs Intel 1.17（差 98%），128 线程 0.67 vs 1.01（差 51%）。这直接解释了为什么 AMD QPS 高——每个时钟周期完成的有效指令更多。

2. AMD 执行了更多指令但用了更少的 cycles：以 128 线程为例，AMD 的 mysqld 执行了 3,615G 指令（比 Intel 多 31%），但只用了 3,596G cycles（比 Intel 少 12%）。更多指令 + 更少 cycles = IPC 高 51%。指令数不同是因为 AMD 跑了更多的查询（QPS 高 32%），每条查询处理的指令路径相似。

3. 分支预测差距在真实负载中得到验证：微基准测试中 AMD branch-miss 率低 10 倍（1.59% vs 15.05%），真实 MySQL 负载中低 5.5 倍（0.44% vs 2.42%）。MySQL 的分支模式比纯随机分支更有规律性，所以两家差距缩小了，但 AMD 仍然显著占优。

4. cache-miss 率 AMD 为零：AMD 的 cache-misses 计数器显示 0，而 Intel 有 16 亿次（5.8%）。这与 stress-ng cache 测试的结论一致——AMD 32MB L3 虽小但访问延迟低，在 MySQL 的访问模式下反而比 Intel 504MB L3 更高效。

测试工具: sysbench 1.0.20 + tsar, stress-ng 0.15.00, UnixBench 6.0.1, perf stat | 报告生成: 2026-08-31

刘志军：中国高铁之父的权力与陨落

来源：YouTube 视频《睡遍”红楼梦”的刘志军：高铁之父的死缓内幕》字幕整理与总结

一、农民之子的崛起之路

刘志军 1953 年出生于湖北黄冈一个贫苦农民家庭，上面两个姐姐，下面一弟一妹。家境极差，父母甚至要卖房子才能供他勉强读到初中。更不利的是，因祖上曾雇过长工，家庭被划为”富农”成分，找正式工作都困难。

1972 年，初中毕业的刘志军赶上铁路系统招工，成为武汉铁路分局的一名养路工——铁路系统最底层、最艰苦的岗位。但他很快因字迹工整、做事细致脱颖而出，被调去做文书，后进入团委系统，一路升至武汉铁路分局团委书记。

关键转折来自武汉铁路分局副局长洪宗全的赏识。洪宗全不仅提拔了刘志军，还将他送到西南交通大学学运输管理，弥补了学历短板。刘志军随后与洪宗全的女儿黄丽萍结婚，借岳父之力从团委转入实权部门。1984 年起几乎一年一个台阶，1987 年即做到武汉分局党委书记。

然而刘志军一达到目的便抛弃妻子——洪宗全退休后他立刻离婚，黄丽萍曾在单位贴小字报控诉其”忘恩负义”。此事在体制内引发巨大反感，刘志军被贬至广州铁路局任政治部副主任。但他很快娶了第二任妻子（据报道其父曾任某军区司令），1988 年便杀回武汉铁路分局当局长，级别已高于前岳父退休时。

此后一路飞升：1993 年任沈阳铁路局局长，1996 年任铁道部副部长，2002 年成为中央委员，2003 年初正式就任铁道部长。

二、独立王国与跨越式发展

铁道部在中国部委体系中极为特殊：200 万职工，数万亿资产，政企合一，军事化管理，拥有自己的公安、检察院、法院、医院、学校和企业，被称为”独立王国”。部内人称部长为”首长”。

然而，当时中国铁路运力严重不足，主干线长期超负荷运转，春运年年告急，铁路已成制约经济发展的瓶颈。

前任部长傅志寰曾推动”网运分离”改革（参照欧洲模式，将铁路基础设施与运输业务拆分），但因铁路系统封闭性太强、利益集团阻力巨大，加上 2001 年后中央倾向于做大国有垄断企业而非拆分，改革未能成功。

刘志军上台后立即叫停”网运分离”，代之以”铁路跨越式发展”——集中权力、资金、资源，以非常规方式跳过传统发展阶段，直接追赶发达国家水平。傅志寰要分权，刘志军要集权。

三、中国高铁从无到有

3.1 顶层规划

2003 年上任不久，刘志军推动启动中国第一个《中长期铁路网规划》，提出”四纵四横”客运专线设想（总长约 1.2 万公里，设计时速 200 公里以上），到 2020 年全国铁路营业里程达 10 万公里，预计总投入 2 万亿——自美国州际公路系统以来全球投资金额最高的公共工程之一。

为何选高铁而非磁悬浮？上海浦东机场到市区的磁悬浮实验线证明：磁悬浮对载重有严格限制，无法满足中国的大运量需求。

3.2 技术引进与博弈

中国从上世纪 90 年代就尝试自研高速列车（”南建”、”先锋”、”中华之星”、”长白山”等），但整体技术不成熟，核心部件依赖进口，国产方案最高时速仅约 160 公里。

2004 年，国务院确定”引进先进技术、联合设计生产、打造中国品牌”的思路。铁道部采取”战略买家”打法：

• 国内仅允许南车四方和北车长客两家与外方谈判
• 其余企业不准私下接触外国厂商
• 以中国市场的巨大体量为筹码

在压力与诱惑下，川崎重工、阿尔斯通、庞巴迪、西门子等国际巨头不仅接受技术转让条件，还在价格上被一再压低。

• 2004 年 6 月：时速 200 公里动车组招标
• 2005 年 10 月：时速 300 公里项目招标
• 2007 年 4 月 18 日：第六次大提速，时速 200-250 公里动车组正式运行
• 2008 年 8 月：京津城际铁路通车（中国第一条设计时速 350 公里的高铁）

3.3 自主研发的突破

2008 年铁道部与科技部签署行动计划，目标直接研制时速 350 公里以上的国产高速列车。集结了中科院、清华、北大等近 30 家科研院所和近 50 家骨干企业。

2010 年 5 月，CRH380A 电力动车组在长春下线。同年 12 月 3 日，在京沪高铁试验段跑出 486.1 公里时速，刷新世界纪录。

3.4 “部省合作”的资金机制

刘志军创设”部省合作”机制——铁道部与全国 31 个省市自治区签署战略合作协议，双方共同出资成立合资铁路公司。地方政府承担征地拆迁，并以权益性投资方式投入超过 4000 亿。

投资规模爆炸式增长：

• 2003 年：533 亿
• 2010 年：7075 亿（翻了十几倍，一度超过国防军费）
• 任内在建铁路约 1.8 万公里，再建铁路接近 3 万公里
• 全国铁路运营里程从 2002 年的 7.19 万公里增至 2010 年的 9.1 万公里

3.5 四万亿的助推

2008 年全球金融危机后，温家宝推出 4 万亿刺激计划，其中约 1.5 万亿投向铁路等基础设施。中长期规划随之调整：铁路里程目标从 10 万提高到 12 万公里以上，高铁里程从 1.2 万提高到 1.6 万公里。

四、刘志军的管理风格

刘志军在铁道部大权独揽、说一不二，被称为”刘疯子”。半夜翻材料发现问题就召集负责人开会，当场研究、当场定方案、当场敲时间表。反对者一律撤职。

每逢高铁提速或验收，他几乎都亲自坐进驾驶室——以自身安全为赌注倒逼施工质量。有人统计他曾连续几十个小时沿提速线路检查不下车。

另一面，他对风水颇为在意，重大工程开工前会请人选黄道吉日。

五、代价与事故

债务深渊

到 2011 年上半年，铁道部负债已超 2 万亿，负债率接近 60%。

重大安全事故

• 2008 年南方雪灾：京广铁路南端几乎瘫痪，超 20 万人被困广州火车站
• 2008 年 4 月 28 日胶济铁路事故：列车相撞，72 人死亡，刘志军受到记过处分
• 2011 年温州动车事故：40 人死亡、192 人受伤

六、腐败与权力掮客

6.1 弟弟刘志祥

刘志祥在哥哥庇荫下升至武汉铁路分局副局长，但纯粹是个祸害：

• 控制汉口火车站几乎所有卧铺票和热门座位票，将外部电脑接入配票系统倒卖车票
• 非法所得 4000 多万
• 2002 年指使承包商杀害举报人高铁柱
• 2005 年被纪委双规，最终被判死缓，后改判 16 年

6.2 丁书苗（丁羽心）——“高铁一姐”

丁书苗，1955 年生，山西商人，外号”傻粮”。从收鸡蛋、开饭店、跑煤炭运输起家，靠极强的人际关系能力逐步打入铁路系统核心。约 1997 年经人牵线结识刘志军。

高铁投资全面启动后，丁书苗成为最大的权力掮客：

• 2007-2010 年间帮助 23 家投标公司中标 57 个高铁项目，标的总额 1858 亿
• 收取 1.5%-3.8% 的中介费，个人获利超 20 亿
• 其中 53 个项目由刘志军亲自打招呼

丁书苗还为刘志军提供多种”服务”：

• 捞人：2007 年铁道部政治部主任何洪达被查，丁书苗花 4400 万试图摆平（未成功）
• 跑官：胶济铁路事故后刘志军想调离铁道部，丁书苗花 500 万找人打点（同样被骗）
• 安排女色：2009 年出资 5000 万参与拍摄新版《红楼梦》，据传帮刘志军潜规则剧组女演员
• 慈善洗白：汶川地震捐 1.14 亿、玉树地震捐 1580 万、舟曲泥石流捐 2300 万、捐 1.5 亿购买”母亲健康快车”。甚至为了做慈善还行贿国务院扶贫办官员范振玉 4000 多万

6.3 刘志军的受贿

刘志军本人在金钱上相当谨慎——很少直接拿钱，巨额利益基本留在丁书苗名下。官媒曾宣称查封 374 套房产、总价值 8 亿，但法庭证实这些基本在丁书苗名下。

法院最终认定刘志军受贿约 6460 万。民间传言的”刘百亿”与司法认定差距巨大，关键在于大量资产被认定为丁书苗个人所有——如果不这么切割，死缓判决就难以自圆其说。

七、落幕

事发经过

2010 年夏，国家审计署在跟踪审计京沪高铁时发现资金异常，顺藤摸瓜查到丁书苗，刘志军问题随之浮出水面。

2011 年 1 月春运期间，刘志军突然消失十多天，后重新露面，连续乘坐和巡查各条高铁线路超过 7000 公里——更像一场告别。

2011 年 2 月 11 日夜，刘志军被中纪委带走。

态度与判决

在秦城监狱中，刘志军：

• 告诉律师”无论生死都不上诉”
• 对审查意见全部签字、不做反对
• 从未检举揭发过任何其他人
• 嘱托律师转告女儿”千万不要从政”
• 与律师聊历史人物（从胡适到傅斯年），推荐《南渡北归》
• 能从记忆中细述每一条高铁线路、每一个高铁站的设计方案

刘志军放弃辩护的逻辑：不与组织讨价还价，以换取活命。高铁利益盘子巨大，必然牵涉更高层，但他从未检举任何人。

2013 年 7 月，刘志军一审被判死缓。

丁书苗被判 20 年，罚金 25 亿，没收财产 2000 万。

据英国《每日电讯报》报道

有消息人士称不判刘志军死刑，与其和胡锦涛之子胡海峰、前政治局委员王兆国之子王新亮的关系有关，也有说法称江泽民出面保了他。

八、后续影响

铁道部的终结

2013 年，国务院撤销铁道部，行政职能并入交通运输部和新组建的国家铁路局，企业职能划入新组建的中国铁路总公司，实现政企分开。”独立王国”的日子结束。

继任者同样落马

接替刘志军的盛光祖（铁道部最后一任部长），上任第二天即立”廉政军令状”，但 2023 年 12 月因受贿 6300 万被判 15 年。

高铁的长期回报

• 降速后安全隐患大幅降低
• 京沪高铁实现盈利
• 部分当年被质疑的线路逐渐具备长期回报能力
• 客运分流释放了传统铁路的货运能力
• 但大量中西部高铁线依然长期依赖补贴和债务滚动

九、核心启示

视频最后指出，中国高铁的发展模式与中国过去几十年的整体发展模式高度相似——靠超大规模投资换取高速增长。这种模式短期极其有效，但当投资规模无限放大而约束机制滞后时，债务堆积、权力与资本勾连、寻租空间成倍放大。效率和腐败、发展和风险往往同时出现。

视频认为，如果反腐只寄希望于官员的自觉自律，本身就是反人性的。真正的问题从来不只是”谁贪了”，而是有没有一套制度让人”不敢贪、不能贪、贪了必然付出无法承受的代价”。

注：以上内容基于视频字幕自动转录整理，部分细节可能因语音识别误差存在偏差。

附录：核心事实声明可信度校验

对视频中 25 条核心事实声明进行了逐条校验，主要来源为中文/英文维基百科及公开报道。

汇总

总体评价：视频事实陈述质量较高，大部分核心事实与权威来源吻合。无明显的事实错误。

逐条校验

确认（15 条）

部分准确（5 条）

无法确认（2 条）

有争议（1 条）

值得注意的额外信息

维基百科提供了视频未提及的一些补充信息：

• 丁书苗行贿何洪达的金额，维基百科记载为 4390 万（视频说 4400 万，基本吻合）
• 刘志军 2015 年 12 月已由死缓减为无期徒刑
• 盛光祖的 15 年实际由两项罪名合并：受贿罪 14 年 + 利用影响力受贿罪 7 年

Dell R670 (Xeon 6517P) vs Xeon 4214 硬件性能对比报告

测试日期：2026-08-25 ~ 2026-08-28
测试目的：对新物理机 Dell R670 (Xeon 6517P) 进行性能摸底，与现有 Xeon 4214 机器对比

1. 硬件配置对比

R670 存储架构

1
2
3
4
5

CPU ──PCIe 5.0──┬── NVMe PM9D3a 7.68TB (/data0, 直通, 无RAID)
                │
                └── PERC H365i (PCIe 4.0 x8, Broadcom Fusion-MPT 24GSAS)
                      └── RAID VD 893.8GB (系统盘, SSD behind RAID)
                            └── 背板 32 槽位

6517P 架构定位：Granite Rapids 是第几代？

1
2
3
4
5
6

代际路线（Server Xeon Scalable）:

Skylake-SP (2017)  →  Cascade Lake (2019)  →  Ice Lake-SP (2021)  →  Sapphire Rapids (2023)  →  Emerald Rapids (2024)  →  Granite Rapids (2024 Q4)
   1st Gen               2nd Gen                 3rd Gen                4th Gen                    5th Gen                    6th Gen
   14nm                  14nm                    10nm                   Intel 7                    Intel 7                    Intel 3
   Xeon 8180             Xeon 4214/8269          Xeon 8380             Xeon 8480+                 Xeon 8592+                 Xeon 6900P/6517P

Xeon 6517P (Granite Rapids) 是第 6 代 Xeon Scalable，比 4214 (Cascade Lake, 第 2 代) 领先 4 代。

6517P vs 4214 架构核心差异

R670 CPU 拓扑（lstopo）

1
2
3
4
5
6
7
8
9
10
11
12
13

┌─ Socket 0 (Package 0) ──────────────────────────────────────┐
│  ┌── Single Compute Die (16 P-cores, 共享 72MB L3) ──────┐  │
│  │  Core 0~15, 每核含 2 HT (共 32 逻辑核)                │  │
│  │  cluster_id 各不同, 但同 die, 无跨 tile 延迟差异       │  │
│  └────────────────────────────────────────────────────────┘  │
│  ┌── I/O Die (4ch DDR5-6400 Memory Controller) ──────────┐  │
│  │              NUMA Node 0 (125GB)                       │  │
│  └────────────────────────────────────────────────────────┘  │
└───────────────────── UPI 2.0 (+118ns) ──────────────────────┘
                           │
┌─ Socket 1 (Package 1) ──────────────────────────────────────┐
│  同样结构: 1 Compute Die + 1 I/O Die, NUMA Node 1 (126GB)   │
└──────────────────────────────────────────────────────────────┘

2. 测试方法与工具

关于 OpenSSL 硬件加速验证

两台机器的 openssl 编译参数均包含 -DAESNI_ASM -DVPAES_ASM，且 CPU flags 中均有 aes 标志，确认 两台都走了 AES-NI 硬件加速路径。

验证方式：对比 openssl speed aes-256-cbc（低级别 AES-NI）和 openssl speed -evp aes-256-cbc（EVP 接口，完全硬件加速）：

两台 EVP/非EVP 加速比接近(5.2~5.4x)，证明硬件加速路径一致。吞吐差异来自频率和微架构，非加速能力差异。

关于 FIO 测试文件大小

• R670 (NVMe)：测试用 1G 和 8G 文件结果一致（15.3K vs 15.4K IOPS），企业级 NVMe DRAM 缓存通常仅 1-4GB，且 PM9D3a 是 Read-Intensive 盘无大容量写缓存，1G 文件已足够可靠
• 4214 (RAID)：使用 8G 文件测试，超过 PERC H730P 的 2GB BBU 缓存，确保测到真实盘性能。写入测试中 RAID 控制器写缓存仍会影响小 IO 延迟（iodepth=1 时 write 61us 明显受 BBU 缓存加速）

3. Cache / 内存延迟对比

3.1 相同参数对比（lat_mem_rd -t 256M）

3.2 各级缓存延迟对比（-t 512M）

3.3 关键洞察

DDR5 延迟悖论：R670 内存延迟(111ns)反而比 4214(89ns)高 25%。

原因是多方面叠加的：

① DRAM 物理层：DDR5 CAS Latency 绝对时间并未改善

DDR5 虽然频率翻倍，但 CL 数值也成比例增大，实际首次访问时间（tCL/频率）几乎没变：

• DDR5-6400: CL=46, 绝对延迟 = CL / (频率/2) = 46 / 3200MHz = 14.4ns
• DDR4-2400: CL=17, 绝对延迟 = 17 / 1200MHz = 14.2ns
• DDR4-3200: CL=22, 绝对延迟 = 22 / 1600MHz = 13.75ns

DDR5 的带宽收益来自”每个时钟周期传输更多数据（burst length 从 8 增到 16）”，而不是”更快地开始传输”。首次访问延迟（latency）天然就没有进步。

② 内存控制器架构变化：DDR5 每 DIMM 两个独立通道

DDR5 将每根 DIMM 拆成两个 32-bit 子通道（DDR4 是单通道 64-bit）。这提升了带宽和并发，但增加了控制器调度复杂度，引入额外的仲裁延迟。

③ On-die ECC

DDR5 DRAM 颗粒内部强制集成 ECC（用于修正内部位翻转），每次读取都需要额外的校验周期，增加约 1-2ns。

④ CPU uncore/环形总线更长

Granite Rapids 的 72MB L3 需要更大的环形互连（ring bus），core 到内存控制器的物理距离更远。即使 cache miss 后发出内存请求，请求本身在 uncore 上的传播也比 4214（16.9MB L3, 更短的 ring）多耗 5-10ns。

⑤ 总延迟拆解估算

1
2
3
4
5
6
7
8

                        DDR5-6400 (R670)    DDR4-2400 (4214)
DRAM CAS 延迟:            ~14.4ns              ~14.2ns
On-die ECC:               ~1-2ns               0ns
内存控制器调度:            ~5-8ns               ~3-5ns
Uncore/Ring Bus:          ~15-20ns             ~8-12ns
TLB miss 开销(与-t有关):  ~70-75ns             ~60-65ns
─────────────────────────────────────────────────────────
总计 (lat_mem_rd -t):     ~111ns               ~89ns

结论：DDR5 的设计哲学是”用延迟换带宽”——每次访问不会更快，但单位时间能搬运的数据量是 DDR4 的 2-3 倍。

但 R670 通过 72MB 超大 L3 补偿：大部分数据库 working set 在 L3 内（43ns）就能命中，而 4214 只有 16.9MB 很快就溢出到 89ns。

但 R670 通过 72MB 超大 L3 补偿：大部分数据库 working set 在 L3 内（43ns）就能命中，而 4214 只有 16.9MB 很快就溢出到 89ns。

3.4 完整延迟曲线对比（关键节点，-t 512M）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Size(MB)    6517P(ns)    4214(ns)     优胜方
0.032       1.254        1.318        ≈ 平
0.048       1.256        4.435        R670 (L1d=48K vs 32K)
0.064       4.012        4.425        ≈ 平 (都在L2)
0.250       4.202        6.754        R670
1.000       5.769        11.785       R670 (2MB L2 vs 1MB L2)
2.000       15.974       23.073       R670
4.000       35.965       23.163       4214 (4214仍在L3内, R670在L3深处)
8.000       38.174       23.459       4214
16.000      42.873       33.138       4214 (4214 L3边界16.9MB)
32.000      43.363       65.431       **R670** (4214已到内存, R670仍在L3!)
64.000      53.915       77.831       **R670** (R670仍在72MB L3!)
128.000     86.131       84.381       ≈ 平 (都在内存了)
256.000     102.399      87.439       4214
512.000     111.135      89.133       4214 (DDR5延迟更高)

转折点在 ~17MB：小于 17MB 时 4214 的小 L3 延迟更低；大于 17MB 后 4214 溢出到内存而 R670 仍在 L3 缓存中——这是 72MB L3 的核心优势。

4. 内存带宽对比（bw_mem 512MB read）

4.1 单核带宽

4.2 多核聚合带宽（单 socket，Read）

4.3 内存带宽验证结论

单 socket 饱和带宽：

• R670: 16核 × 9,812 MB/s = 153.4 GB/s（DDR5-6400 理论 4通道 × 51.2 = 204.8 GB/s，利用率 75%）
• 4214: 12核 × 4,349 MB/s = 51.0 GB/s（DDR4-2400 理论 6通道 × 19.2 = 115.2 GB/s，利用率 44%）

饱和带宽 R670 是 4214 的 3.0x，这正是 DDR5-6400 vs DDR4-2400 的核心优势所在。

4.4 内存墙假设验证

假设：“两个物理机最大的差异是内存速率（6400 vs 2400 MT/s），因为只要不是 CPU bound 都需要大量访问内存，内存墙才是最大的瓶颈。”

验证结论：部分成立，但需要细化

结论：对数据库场景（MySQL buffer pool 通常 32-64GB），R670 的 72MB L3 能覆盖大量 hot data 的 index page。真正的优势不仅是内存带宽 3x，更是 L3 容量 4.3x 带来的 “避免打到内存墙” 的能力。对单线程延迟敏感的场景，DDR5 绝对延迟反而是劣势；但多线程并发场景下带宽优势碾压延迟劣势。

5. NUMA / 跨 Socket 延迟

5.1 跨 Socket 延迟（lat_mem_rd -t 256M）

5.2 Socket 内各 Core 延迟一致性验证

测试：Socket 内不同 core（不同 cluster_id）访问本地内存

结论：同 socket 内不同 core 延迟差异 < 3%，确认 16 核同处一个 compute die，无跨 tile 延迟差异。

5.3 与历史 CPU 跨 NUMA 对比

R670 跨 socket 惩罚在 Intel 家族里偏大，数据库部署务必做好 NUMA 绑定（numactl --cpunodebind=0 --membind=0）。

6. 单核计算性能对比

6.1 7^999999 计算

测试命令：perf stat -e cpu-cycles,instructions,branch-misses,cache-misses,cache-references -- bash -c 'echo 7^999999 | bc > /dev/null'

注意：两台机器执行的 instructions 数量完全一致（123.2B），这是同一个计算任务。差异完全来自 IPC 和时钟频率：

• R670: 123.2B / 45.3B cycles = IPC 2.72, 实测11.36s（turbo boost 生效）
• 4214: 123.2B / 67.8B cycles = IPC 1.82, 实测21.46s

R670 单核比 4214 快 89%（11.36 vs 21.46），其中 IPC 贡献：2.72/1.82 = 1.49x（Granite Rapids 微架构比 Cascade Lake IPC 高 49%）

6.2 Pi(5000) 计算

测试命令：time bash -c 'echo "scale=5000; 4*a(1)" | bc -l -q >/dev/null'

7. OpenSSL AES-256-CBC 吞吐对比

7.1 单核吞吐（非EVP模式，验证CPU计算能力）

测试命令：openssl speed aes-256-cbc

7.2 多核吞吐

测试命令：openssl speed -multi N aes-256-cbc

历史 CPU 对比（32 线程）

8. 存储性能对比（FIO）

8.1 测试参数说明

8.2 4K 随机读写（延迟优先，iodepth=1, numjobs=1）

测试命令：fio --ioengine=libaio --direct=1 --bs=4k --iodepth=1 --numjobs=1 --rw=randread/randwrite --size=8G --runtime=30 --time_based

注：4214 的随机写延迟(61us)受 RAID BBU 写缓存加速。若无缓存（缓存满或透写模式），实际延迟可能 10x+。

8.3 4K 随机读写（高并发，iodepth=64, numjobs=4）

测试命令：fio --ioengine=libaio --direct=1 --bs=4k --iodepth=64 --numjobs=4 --rw=randread/randwrite --size=8G --runtime=30 --time_based

8.4 顺序读写（1M block, iodepth=32, numjobs=1）

测试命令：fio --ioengine=libaio --direct=1 --bs=1m --iodepth=32 --numjobs=1 --rw=read/write --size=8G --runtime=30 --time_based

8.5 混合随机读写（70/30, 4K, iodepth=32, numjobs=4）

测试命令：fio --ioengine=libaio --direct=1 --bs=4k --iodepth=32 --numjobs=4 --rw=randrw --rwmixread=70 --size=8G --runtime=30 --time_based

8.6 磁盘配置与性能总结

性能对比总结（单队列延迟 = 数据库最关心的指标）：

*4214 写延迟受 RAID BBU 写缓存加速。从 IOPS 和延迟数据综合判断，4214 RAID 后面是 SSD（非 HDD），因为 HDD 4K 随机读只能做到 100-200 IOPS / 5-10ms 延迟，而 4214 实测 9,801 IOPS / 101us，这是 SSD 的特征。

关键差异来源：

1. NVMe 直通 vs RAID 控制器：R670 的 NVMe 直连 CPU PCIe 总线，省去了 RAID 控制器的转发开销（~30-50us）
2. PM9D3a 企业级 NVMe：三星 OEM 旗舰企业盘，内部并行度高（多 die 并发）
3. 队列深度利用：NVMe 原生支持 64K 队列深度 × 64K 队列数，而 RAID 卡受限于控制器处理能力
4. 写路径：NVMe 写直达闪存控制器（11.7us），RAID 卡写入 BBU 缓存后返回（61us，含 RAID 逻辑开销）

9. 综合对比总结

9.1 性能倍数一览

9.2 结论

1. CPU 计算能力：R670 单核比 4214 快 89%（IPC 2.72 vs 1.82 + 频率差），在所有历史测试 CPU 中单核性能最强
2. 内存子系统：
   • 带宽：DDR5-6400 单核 1.78x，多核聚合 3.0x——多线程数据库场景的核心优势
   • 延迟：DDR5 绝对延迟更高(111ns vs 89ns)——但被 72MB L3 缓存弥补
   • 内存墙结论：R670 通过 “超大 L3 + 超高带宽” 两手策略应对内存墙，延迟敏感路径靠 L3，带宽敏感路径靠 DDR5 多通道
3. 存储：NVMe 对 RAID 是降维打击，不在同一量级（18-50x 差距）
4. NUMA：R670 跨 socket 惩罚(2.16x)比 4214(1.62x)更大，务必绑定 NUMA
5. 适用场景：R670 极适合 MySQL 主库、Redis、低延迟中间件

9.3 内存墙假设验证总结

结论：假设成立但需要修正表述。

• ✅ 带宽层面：DDR5-6400 确实是最大差异因素，提供 3x 聚合带宽，多线程 memory-bound 场景直接受益
• ⚠️ 延迟层面：DDR5 延迟反而更高 14-25%（取决于 working set 大小）。但 R670 用 72MB L3（4.3x容量）把”内存墙”推后了——只有 working set > 72MB 才真正碰到 DDR5 的高延迟
• ✅ 实际数据库效果：MySQL buffer pool 的 hot page 如果在 72MB 以内（非常多 OLTP 场景满足），R670 以 43ns L3 延迟服务，而 4214 在 17MB 就溢出到 89ns 内存——等效延迟 R670 反而快 35-50%

附录 A：R670 6517P 完整 lat_mem_rd 原始数据（-t 512M）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Size(MB)   Latency(ns)
0.048      1.256    (L1d上限)
0.051      4.013    (L2起始)
0.250      4.202
1.000      5.769    (L2稳态)
2.000      15.974   (L3起始)
4.000      35.965
8.000      38.174
16.000     42.873
32.000     43.363
64.000     53.915   (L3尾部)
128.000    86.131   (Memory过渡)
256.000    102.399
512.000    111.135  (Memory稳态)

附录 B：4214 完整 lat_mem_rd 原始数据（-t 512M）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Size(MB)   Latency(ns)
0.031      1.318    (L1d上限)
0.035      4.435    (L2起始)
0.250      6.754
1.000      11.785   (L2尾部/L3起始)
2.000      23.073   (L3稳态)
4.000      23.163
8.000      23.459
16.000     33.138   (L3边界16.9MB)
32.000     65.431   (Memory过渡)
64.000     77.831
128.000    84.381
256.000    87.439
512.000    89.133   (Memory稳态)

附录 C：历史 CPU 性能基准（来自 wiki 数据）

单核计算 7^999999

OpenSSL aes-256-cbc 单核 (8192B block)

历史 lat_mem_rd 内存延迟（local NUMA, @64MB -t 64M）

*注：R670 在 @64MB 时数据仍在 72MB L3 缓存内，并非真实内存延迟。其真实内存延迟为 102-111ns (@256-512MB)。

https://www.servethehome.com/intel-xeon-6700p-and-6500p-granite-rapids-sp-for-the-masses-initial-benchmarks-and-first-look/4/

开源代码加个壳，年收你 15 万美金——一次 RDS 迁移自建的成本审计

一句话结论

我们把 6 个 RDS MySQL 集群迁到 EC2 自建，年省 $151,425（76%）。这不是什么黑科技，就是把云厂商帮你装好的 MySQL 自己装了一遍。

云数据库的定价逻辑

RDS 的本质是：在 EC2 上跑一个开源数据库，加一层管控面板，然后把价格翻一倍往外卖。

以 ap-east-1 区域 db.m5d.xlarge（4C 16G）为例：

存储更离谱。同样的 gp3 磁盘：

你没看错——同一块硬盘、同一个 IOPS，挂在 RDS 上比挂在 EC2 上贵 12 倍。

那管控面板值这个差价吗？

管控做了什么：收钱的自动化

RDS 管控提供的核心能力：

1. 自动备份 —— 一个 cron + mysqldump/xtrabackup 的事
2. 自动故障切换 —— 开源社区 orchestrator/MHA 免费且更灵活
3. 自动小版本升级 —— 这不是优点，这是灾难（下面细说）
4. 监控 —— Performance Insights 还要额外收费，基础 CloudWatch 指标连 QPS 都看不到
5. 参数管理 —— 一个 my.cnf 的事，还不让你改一半参数

真正恶心的是强制升级。

MySQL 8.0 社区还在维护，RDS 直接宣布 EOL，逼你升 8.4。理由？”降低我们的运维成本”。从来不考虑：

• 你的 ORM 框架兼不兼容
• 你的 CDC 组件（Canal/Debezium）测过没有
• 你的 SQL 在新优化器下会不会回退

云厂商嘴上说”客户第一”，实际做的每一个决策都是”降低自己的运维成本，把风险转嫁给客户”。一个 Terraform apply 就把你几百个集群的引擎版本全换了，你连说不的机会都没有。

实战：6 个集群的迁移账本

原始配置

迁移后实际 EC2 配置

成本分析

RDS 年费：$199,174
EC2 年费：$47,749
年省：$151,425（76%）

省钱的三个层次

第一层：平移替换（省 50-60%）

单纯把 RDS 换成同规格 EC2 自建 MySQL，不做任何优化。省钱来源：

• 去掉 RDS 的”管控溢价”（计算 2-3 倍）
• 去掉存储的”托管溢价”（IOPS 12 倍）
• 使用 gp3 基线 3000 IOPS 免费额度（RDS 要额外收钱）

第二层：基于监控降配（再省 15-20%）

拉取 48 小时监控后发现：

集群 1 尤其荒唐：RDS 上跑着 16C 64G 的大实例，实际 CPU 平均 2.5%，存储 IOPS 日常仅 20。我们直接降到 4C 16G，一个集群就省了 $65,687/年。

这不是什么高难度操作——拉个 CloudWatch 指标谁都会。但如果你用着 RDS，你永远不会去想”我要不要降配”，因为：

1. RDS 没有直观的利用率告警（连 QPS 都不给你看，要开 Performance Insights 再付钱）
2. 修改实例规格需要重启，Multi-AZ 切换有风险
3. 反正不是自己的钱，KPI 不考核基础设施成本

第三层：总结

这只是冰山一角

上面 6 个集群的 RDS 年费不到 20 万美金。在我们整个基础设施账单里，这连 5% 都不到。

如果把所有托管服务（RDS、ElastiCache、MSK、OpenSearch……）全部迁移自建，按同样的比例估算，年省百万美金量级不是梦话。

而在国内互联网行业，很多公司一年在云上花几千万甚至几个亿人民币。按我们实测的 76% 节省比例，实际可能只需要 20-30% 的预算就能跑同样的业务。剩下的钱去哪了？去了云厂商的毛利率报表里。

更进一步：EC2 到 IDC 自建

如果 RDS 到 EC2 能省 76%，那 EC2 到自建 IDC 呢？

EC2 本身也有”云溢价”。同样一台 4C 16G 的服务器：

经验法则：当你的年云支出超过 1000 万人民币（约 $140 万美金），就应该认真评估自建 IDC 或混合架构了。在这个规模下：

• 你已经有足够的运维团队
• 服务器采购有议价空间
• 网络带宽成本可以通过 BGP 直连大幅降低
• 3 年折旧后硬件几乎是”免费”的

工程师的价值

$151,425/年。

这是一个 DBA 花两周时间做迁移评估 + 执行带来的年化收益。这笔钱：

• 在北京够招一个资深工程师
• 在二线城市够招两个
• 比 90% 的”降本增效”项目 ROI 都高

而且这还只是”小试牛刀”——6 个中小规格集群。

别忘了，这原本 20 万刀的开支上面，云厂商还要再收 8% 的企业支持服务费（Enterprise Support）。$199,174 × 8% = $15,934/年，又是一个工程师的工资。

放大到整个公司：如果你一年在云上花 1000 万人民币，8% 就是 80 万——够养一个 3-4 人的专职运维团队了。而云厂商的”支持服务”给你什么？一个工单系统、一个响应 SLA、偶尔帮你提个 limit。你自己的工程师调个参数 5 分钟搞定的事，走工单要等 24 小时。

如果你是多云架构，情况更糟：

• 每家云都要交一份支持费
• 每家的 API/控制台/计费模型都不一样，运维工具要写多套
• 跨云网络打通本身就是成本（专线、VPN、流量费）
• 出了问题两家互相甩锅，你夹在中间当传话筒

如果你已经有了 IDC 自建能力，云上的托管服务就是在给云厂商交智商税。 同样的 MySQL、同样的 Redis、同样的 Kafka——跑在你自己机房的服务器上，性能更好、延迟更低、成本是云上的 1/5。

云厂商的销售会告诉你”自建运维成本高””要招人要管理”。但他们不会告诉你：

• 他们的托管服务本身就是你花钱让别人招了个运维
• 这个运维收费是市场价的 5-10 倍
• 这个运维还会强制你升级、限制你改配置、监控还要额外付费
• 你交的 8% 支持费，换来的是一个工单系统和一句”建议您升级到最新版本”

AI 才是真正的降本增效工具

很多人问：自建听起来好，但你哪来的人力做迁移评估、写管控脚本、搞高可用切换？

答案是：AI。

这次 6 个集群的迁移评估，从拉取 RDS 配置、查询 CMDB 元数据、获取 EC2 实际规格、抓取 AWS 官方定价 JSON、计算成本对比、生成汇总报告——全程由 AI Agent 完成。一个 DBA 坐在终端前给指令，AI 负责执行。整个成本审计过程不到 2 小时。

传统做法？开会讨论 → 安排人力 → 写脚本拉数据 → Excel 算半天 → 做 PPT 汇报 → 领导审批。一个月能出结果算快的。

AI 在这次迁移中具体干了什么

为什么很多公司 AI “烧 token 看不到效果”

每月花几万块 token 费，产出是什么？让员工用 ChatGPT 润色周报、用 Copilot 补全几行代码、开会用 AI 做纪要。这些场景有价值吗？有。但 ROI 约等于零——因为省的是”5 分钟”，不是”5 万美金”。

AI 降本增效的正确姿势：让 AI 去做那些”能做但没人力做”的事。

成本审计就是典型。每个公司都知道云上可能有浪费，但：

• 没人有空去逐个实例拉监控
• 没人愿意花一周时间算 Excel
• 算完了还不一定能推动执行

AI 把这个成本降到接近零。一次对话 = 一次完整审计 = 发现 $15 万/年的节省机会。 这次对话消耗的 token 费？不到 $5。

ROI 对比

差距不是 AI 本身的问题，是你让 AI 做什么的问题。

让 AI 帮你写”尊敬的领导，现将本周工作汇报如下”——这不叫降本增效，这叫浪费电。让 AI 帮你查明白每年有 15 万美金在被云厂商白拿——这才叫降本增效。

给管理者的建议

1. 别让 AI 去做”锦上添花”的事，让它去做”本来没人力做”的事
2. 基础设施成本审计是最容易落地的高 ROI 场景——数据结构化、API 可调用、结果可量化
3. 把 AI 当成一个 7×24 的初级运维，给它明确的指令和工具权限，它能干的活比你想象的多
4. 衡量 AI 投入的标准不是”省了多少时间”，而是”做了多少原来做不了的事”

结语

云厂商不是做慈善的。RDS 的商业模式就是：

把 MySQL 官网免费下载的二进制文件装到你本来就在付费的 EC2 上，加一个 Web 控制台，然后跟你收 2-12 倍的溢价。

这门生意的毛利率，做梦都能笑醒。

而你只需要一个懂 MySQL 的工程师、一套开源高可用方案（orchestrator + ProxySQL）、一个备份脚本——就能省下 75% 的钱，还能获得更大的灵活性。

不是所有上云都是降本。绝大多时候，下云才是。

云计算极致弹性的骗局

一句话总结

云厂商卖的是”随时扩容、秒级弹性”，实际交付的是”库存看运气、升配等半天、换代要验证、出了问题没人兜底”。

今天发生了什么

我们的内部某个系统需要紧急扩容。业务处于重保状态，绝对不能出问题。

结果呢？在阿里云上升配一台 ECS，花了超过 5 个小时，到现在还没搞定。

原因：

• 7 代机库存不足，扩不上去
• 9 代机有库存，但不让从 7 代直接升——AMD/Intel 架构差异、机器代数差异等”稳定性考量”不允许跨代升配
• 资源明明有，但就是用不上

这就是云厂商口中的”极致弹性”。

弹性的真相：一张限制清单

云厂商的宣传：需要资源？点一下，秒级到位。

实际情况：

升级坑死你的案例：https://plantegg.github.io/2026/04/15/AWS-HikariCP-%E8%BF%9E%E6%8E%A5%E8%B6%85%E6%97%B6%E6%A0%B9%E5%9B%A0%E5%88%86%E6%9E%90/

更讽刺的是——今天有库存不代表明天有。库存是动态的，哪天一个大客户扫一波资源，你原来能扩的机型就扩不动了。

换代验证：花钱替云厂商做测试

云厂商每隔两三年推出新一代实例。旧代际的库存会逐渐减少。为了保证未来能弹性扩容，你就得主动迁移到新代际。

迁移意味着什么？

1. 新旧代际的默认参数可能不一致
2. 你要停下业务开发，专门去做兼容性验证
3. 验证过了，也不能保证不漏——因为有些差异只在特定场景才暴露

这不是假设，是真实踩过的坑：

AWS 第 8 代 EC2 实例（2025 年 9 月上线），把 ENI 安全组的连接跟踪超时从 5 天（432000 秒）悄悄改成了 350 秒。没有独立公告，没有迁移指南，甚至 API 在 6 个月后才开始返回这个参数：https://plantegg.github.io/2026/04/15/AWS-HikariCP-%E8%BF%9E%E6%8E%A5%E8%B6%85%E6%97%B6%E6%A0%B9%E5%9B%A0%E5%88%86%E6%9E%90/

后果：所有跨网络的长连接（数据库、消息队列、RPC），只要空闲超过 350 秒，就会被安全组静默丢弃——不发 RST，不通知任何一方。应用端看到的就是”莫名超时”。我们的 Java 服务迁移到 AWS 8 代实例后，HikariCP 连接池每隔 20 分钟就批量报错。

排查花了多久？ 从开 case 到定位根因，19 小时。AWS 自己的支持工程师都要开两轮会议才找到原因。而 AWS 确认，已有 6 家大型企业、10 余个支持案例报告了同一问题——实际受影响的用户远不止这些，因为”静默丢包”根本不会产生明确的错误信号。

这就是你要做的”换代验证”——替云厂商测试他们自己都没文档化的行为变更。

自建机房为什么不需要这种验证

“买新物理机不也要验证吗？”——不需要，或者说简单到可以忽略。

原因很直接：

物理机是干净的。 一台戴尔/联想的服务器，装完 OS 就能用。服务器厂商在出厂前已经做过 OS 兼容性测试。你的业务直接跑在裸金属上，中间没有任何隐藏层。

ECS/EC2 不是干净的。 云厂商在你的 VM 和物理硬件之间塞了一堆自己的服务：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

你以为的结构：          实际的结构：

┌─────────────┐        ┌─────────────┐
│   你的应用   │        │   你的应用   │
├─────────────┤        ├─────────────┤
│     OS      │        │     OS      │
├─────────────┤        ├─────────────┤
│   硬件      │        │  虚拟化层    │  ← 你看不到、控制不了
└─────────────┘        ├─────────────┤
                       │  ENI 连接跟踪│  ← 默认参数随代际变
                       ├─────────────┤
                       │  云盘 IO 调度│  ← 性能特征随代际变
                       ├─────────────┤
                       │  管控面代理  │  ← 占 CPU/内存
                       ├─────────────┤
                       │  Nitro/神龙卡│  ← 固件行为不透明
                       ├─────────────┤
                       │   物理硬件   │
                       └─────────────┘

每换一代实例，这些隐藏层的行为都可能变化。而且云厂商不会事先告诉你变了什么——因为这些是他们的”内部实现细节”。

物理机换代： 装 OS → 简单压测 → 上线。一个运维花半天搞定。不需要惊动业务研发。

ECS 换代： 申请新代际实例 → 部署全套应用 → 回归测试 → 性能对比 → 连接行为验证 → 灰度切流 → 观察一周。一个团队花两周，业务研发全部停下来配合。

你花钱买了”弹性”，结果每两年要停下来做一次全量迁移验证。这不是弹性，这是供着一个祖宗。

库存问题无解

有人说：”跟云厂商提前报备，让他们预留库存。”

想想这意味着什么：

• 你要提前规划未来的扩容需求（那还要弹性干什么？）
• 你要信任云厂商的库存承诺（今天有库存明天就没了）
• 你要绑定特定代际（否则哪天被迫换代又要全量验证）

按需、弹性、免规划——卖点一个都兑现不了。

结论

云计算的”极致弹性”是一个营销概念，不是工程事实。

真实的云计算体验是：

• 扩容要看库存脸色——紧急时刻扩不动
• 换代要做全量验证——业务研发替云厂商测试
• 默认参数会变——不通知、不文档化、出了问题你自己查
• 中间层行为不透明——静默丢包连错误信号都没有

如果你的业务对可用性有要求，在做架构决策时，请把这些成本算进去。不要被”秒级弹性”的 PPT 忽悠了。

5 个小时了，我只是想给一台 ECS 加点配置而已。

JVM DNS 缓存 TTL 配置避坑指南（实验验证版）

适用范围：所有 Java 业务，尤其在用域名而非 IP 接入下游服务（数据库、Kafka、Redis、HTTP 服务等）的场景。
验证环境：OpenJDK 17（Rocky Linux 8.10）；结论同样适用 Java 8/11/21。
验证日期：2026-05-25。

TL;DR（先看这部分）

如果你只想拿走一条结论：

-Dnetworkaddress.cache.ttl=N 是错的，不会生效。

想用 JVM 启动参数控制 DNS 缓存 TTL，只有 -Dsun.net.inetaddr.ttl=N 这一种正确写法。

如果还能拿走第二条：

代码里 Security.setProperty("networkaddress.cache.ttl", "N") 极易被 log4j2、Spring、Kafka client 等抢跑而失效。生产配置不要依赖这种方式。

如果还能拿走第三条：

推荐配置（任选其一，不用全选）：

1. 启动参数：-Dsun.net.inetaddr.ttl=30 -Dsun.net.inetaddr.negative.ttl=10
2. 或修改 $JAVA_HOME/conf/security/java.security 里 networkaddress.cache.ttl=30、networkaddress.cache.negative.ttl=10

下面是 11 组对照实验的证据。

1. 背景：两个属性、两套存储、一个静态字段

1.1 控制 JVM DNS 缓存 TTL 的两个属性

负向缓存对应 networkaddress.cache.negative.ttl / sun.net.inetaddr.negative.ttl。

1.2 JDK 内部的读取逻辑（OpenJDK 17 源码 sun.net.InetAddressCachePolicy）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public final class InetAddressCachePolicy {
    private static volatile int cachePolicy;          // ← 真正起作用的值
    
    static {                                          // ← 类首次加载时执行 1 次，之后再不读取
        Integer tmp = AccessController.doPrivileged(...) {
            // 1) 优先读 Security.getProperty("networkaddress.cache.ttl")
            // 2) fallback 读 System.getProperty("sun.net.inetaddr.ttl")
        };
        cachePolicy = (tmp != null) ? tmp 
                                    : (hasSecurityManager ? FOREVER : 30);  // 默认 30s
    }
    
    public static int get() { return cachePolicy; }
}

三个关键事实：

1. 静态块只跑一次（class load 时），之后不再读 Security/System property。
2. 所以业务代码里再调 Security.setProperty(...) 改 TTL，InetAddressCachePolicy 不会回头读——值已经被冻在 cachePolicy 字段里了。
3. JVM 内部 System Properties 与 Security Properties 是两套独立存储：
   • -Dnetworkaddress.cache.ttl=N 写进的是 System Properties
   • 但 InetAddressCachePolicy 第一步走 Security.getProperty(...)，根本不读 System Properties
   • 所以这种写法虽然不报错，但完全没有效果

1.3 默认值

• 无 SecurityManager（绝大多数现代生产场景）：正向 30 秒，负向 10 秒
• 有 SecurityManager（极少见）：正向 forever（永久），负向 10 秒

2. 实验设计

2.1 待验证的核心假设

任何在你 Security.setProperty(...) 之前调用 InetAddress.getXxxByName() / getLocalHost() 的代码，都会触发 InetAddressCachePolicy 类首次加载，使 cachePolicy 字段被冻结到 JVM 默认值。其中最常见的抢跑者就是 log4j2 的 LogManager.getLogger(...)——尤其是写在 static final 字段里的那种。

2.2 测量方法（双重证据）

• 直接证据：反射读取 sun.net.InetAddressCachePolicy.get() 拿到 effective 值
• 间接证据：tcpdump 抓 udp dst port 53 包，统计 20 秒内对目标域名的实际 DNS 查询次数
  • 若 TTL=2 生效：约 20+ 次（每秒一查，缓存基本不命中）
  • 若 TTL 失效（默认 30s）：约 4~6 次（启动 overhead + 全程命中缓存）
  • 差异 4~6 倍，结论稳定

2.3 11 个对照场景

3. 实验结果

TTL=2，每秒解析一次共 20 次。生效时 cachePolicy=2、DNS 查询数 ≈ 20+；失效时 cachePolicy=30、查询数 ≈ 46（这 46 次是 JVM 启动期 hostname/reverse-lookup 等开销，业务期完全命中缓存）。

3.1 四种主流设置方式的最终判定

4. 为什么 log4j2 会”覆盖”你的设置（机制澄清）

严格说不是覆盖，是读取时机错过。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

时间轴（坏写法 S4）：

t0   类加载 MyClass（业务的 main 类）
t0a  → static final Logger LOG = LogManager.getLogger(MyClass.class);   ← 类加载阶段
t0b   → log4j2 LoggerContext init
t0c    → 解析配置 / 注册 ServiceLoader / hostname lookup
t0d     → 第一次调到 InetAddress.getXxxByName()
t0e      → 触发 InetAddressCachePolicy.<clinit>
t0f       → Security.getProperty("networkaddress.cache.ttl") = null
t0g       → System.getProperty("sun.net.inetaddr.ttl")     = null
t0h       → 用默认值 30，写入 cachePolicy 字段，**永久冻结**

t1   main() 进入
t1a  Security.setProperty("networkaddress.cache.ttl", "5");
     ↑ 写进了 Security Properties Map，但 cachePolicy 字段不再被读
t1b  之后所有 InetAddress 操作 → InetAddressCachePolicy.get() → 30

4.1 抢跑者远不止 log4j2

任何在 Security.setProperty 之前触发 InetAddress.getXxxByName/getLocalHost 的代码，都会冻结 cachePolicy。常见的有：

只要这个清单里任意一项先于业务代码 Security.setProperty，TTL 就被冻在默认值。

5. 业务方避坑清单（必读）

5.1 必须避免

5.2 推荐做法（任选其一）

方案 A：JVM 启动参数（最方便、最不容易出错）

1
2
3

java -Dsun.net.inetaddr.ttl=30 \
     -Dsun.net.inetaddr.negative.ttl=10 \
     -jar app.jar

适用场景：业务团队普遍写 java.security 文件不方便，或者运维平台/发布系统能统一注入 JVM 参数。

方案 B：修改 java.security 配置文件（系统级、所有 Java 进程统一生效）

编辑 $JAVA_HOME/conf/security/java.security（Java 8 是 $JAVA_HOME/jre/lib/security/java.security）：

1
2

networkaddress.cache.ttl=30
networkaddress.cache.negative.ttl=10

注意：

• 该文件可能本来就有这两行，要么注释掉、要么是默认值。不要新增重复行。
• 修改后所有运行该 JDK 的进程都会生效，改之前确认无副作用。
• RPM 装的 JDK 在升级时会用包里的版本覆盖该文件，升级流程要带回这个修改。
• 实测发现 RHEL/Rocky 默认就有 networkaddress.cache.negative.ttl=10 这行（不是 JDK 默认 0），删它会改变行为。

方案 C：代码内 Security.setProperty(...) —— 不推荐

如果实在因为某些原因要用代码方式设置：

1
2
3
4
5
6

public static void main(String[] args) {
    // 必须是 main 第一行（甚至要早于该类的 static field 初始化，但 static field 在 main 之前已执行）
    Security.setProperty("networkaddress.cache.ttl", "30");
    Security.setProperty("networkaddress.cache.negative.ttl", "10");
    // ……
}

且必须确保这个 main 类不持有任何 static final Logger 字段——否则 log4j 在类加载期就跑完了。

但即便这样，仍然防不住 -javaagent 在 premain 阶段抢跑。所以代码方式只在简单场景下能用，在带 APM agent 的环境里基本必败。

5.3 取值建议

6. 验证与诊断

6.1 一行命令验证 TTL 是否生效

1
2
3
4
5

# 替换 -Dsun.net.inetaddr.ttl=2 为你实际的写法，看打印是不是 2
java -Dsun.net.inetaddr.ttl=2 \
     --add-opens java.base/sun.net=ALL-UNNAMED \
     -e 'System.out.println(((Integer)Class.forName("sun.net.InetAddressCachePolicy").getMethod("get").invoke(null)));' \
     2>/dev/null

或者写一个最简验证类：

1
2
3
4
5
6
7
8

public class TtlCheck {
    public static void main(String[] args) throws Exception {
        java.lang.reflect.Method m = Class.forName("sun.net.InetAddressCachePolicy")
                                          .getMethod("get");
        m.setAccessible(true);
        System.out.println("Effective TTL = " + m.invoke(null) + " seconds");
    }
}

运行：java --add-opens java.base/sun.net=ALL-UNNAMED TtlCheck

期望输出：Effective TTL = 30 seconds（或你设置的值）；如果是其他奇怪值就有问题。

6.2 定位是谁在抢跑（深度排查）

1

java -Xlog:class+init=info ...your-app... 2>&1 | grep -E 'InetAddressCachePolicy|InetAddress\$'

能看到 InetAddressCachePolicy 在哪个时点、被哪个类引用首次初始化。结合 -XX:+TraceClassLoading 或在该类静态块挂断点能看到完整调用栈。

6.3 用 tcpdump 验证业务运行期的 DNS 查询频次

1
2
3
4

# 在业务实例上抓 30 秒
sudo tcpdump -i any -nn 'udp port 53' -w /tmp/dns.pcap &
sleep 30 ; sudo killall tcpdump
sudo tcpdump -nn -r /tmp/dns.pcap | grep '<your-domain>' | wc -l

把这个数字除以 30 得到每秒查询频次。如果查询频次 << 1/TTL，说明 TTL 比预期大；如果 ≈ 业务每秒解析次数，说明缓存几乎不命中。

7. 附录

7.1 实验脚本与原始日志

• 实验目录：~/q/tmp/jvm-dns-ttl-log4j-test/（本地）/ /root/jvm-dns-ttl-log4j-test/（测试机 172.30.65.103）
• 主程序：TtlProbe.java
• 跑 S1~S9：bash run-experiment.sh
• 跑 S10/S11：bash run-jsec-experiment.sh（自动备份/还原 java.security）
• 原始 pcap + log：results/

7.2 历史背景：为什么 JVM 有”两个名字”

• JDK 1.4 之前：只有 sun.net.inetaddr.ttl，Sun 私有 system property
• JDK 1.4（2002 年）：把 DNS 缓存策略正式化到 Security property 标准里，引入 networkaddress.cache.ttl 作为官方名
• 此后至今：旧名 sun.net.inetaddr.ttl 没废弃，作为 fallback 保留——保兼容

设计层面的内在矛盾：官方名是 Security property，但 JVM 最方便的设置方式（-D）只能设 System property。绝大多数业务方踩坑，根源就是直觉地把这两者拼成 -Dnetworkaddress.cache.ttl=N，然后悄悄失效。

7.3 相关资源

• Java 官方文档（Networking Properties）：
  https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/doc-files/net-properties.html
• OpenJDK 源码 InetAddressCachePolicy.java：
  https://github.com/openjdk/jdk17u/blob/master/src/java.base/share/classes/sun/net/InetAddressCachePolicy.java
• 个人验证 demo（带 log4j2 的 DNS 解析重现）：
  https://github.com/plantegg/DnsDemo

7.4 验证环境

• OS：Rocky Linux 8.10
• JDK：OpenJDK 17.0.19（Red_Hat-17.0.19.0.10-1）
• log4j2：2.20.0
• 测试域名：3 条 A 记录的内网域名
• 验证日期：2026-05-25

MySQL PreparedStatement 性能问题重现报告

1. 问题概述

1.1 问题描述

在 MySQL 使用 useServerPrepStmts=true 时，处理大量参数（5万个）的 PreparedStatement IN 查询时存在严重性能问题。根据原始报告，服务器端预编译比客户端预编译慢 190-207倍。

1.2 问题来源

• GitHub 仓库: https://github.com/plantegg/MySQLPrepared
• 原始发现版本: MySQL 5.7.29
• JDBC 驱动: mysql-connector-j-8.0.33

1.3 问题根因（原始报告）

MySQL 服务器在处理大量参数的 PreparedStatement 时：

1. 大量内存重分配: 50,000 次参数替换操作
2. 字符串操作复杂度: O(SQL长度) × 参数数量
3. 内存碎片化: 频繁的大块内存分配和释放

2. 测试环境

2.1 AWS 资源信息

2.2 RDS MySQL 8.0 实例

2.3 RDS MySQL 5.7 实例

2.4 EC2 测试客户端

3. 测试方法

3.1 测试代码

1
2
3
4

git clone https://github.com/plantegg/MySQLPrepared.git
cd MySQLPrepared
./run_test.sh --host <mysql-host> --port 3306 --database test \
    --user admin --password '<password>' --rounds 3

3.2 测试参数

3.3 AWS CLI 命令

创建 RDS MySQL 8.0 实例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

aws rds create-db-instance \
    --profile default --region ap-southeast-1 \
    --db-instance-identifier mysql-prepared-test \
    --db-instance-class db.t3.medium \
    --engine mysql \
    --engine-version 8.0 \
    --master-username admin \
    --master-user-password 'Tiger#2612' \
    --allocated-storage 50 \
    --storage-type gp3 \
    --db-subnet-group-name mysql-benchmark-subnet-group \
    --vpc-security-group-ids sg-01541b078e0b483d0 \
    --no-multi-az \
    --publicly-accessible \
    --backup-retention-period 0 \
    --no-auto-minor-version-upgrade

创建 RDS MySQL 5.7 实例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

aws rds create-db-instance \
    --profile default --region ap-southeast-1 \
    --db-instance-identifier mysql57-prepared-test \
    --db-instance-class db.t3.medium \
    --engine mysql \
    --engine-version 5.7.44-rds.20240408 \
    --master-username admin \
    --master-user-password 'Tiger#2612' \
    --allocated-storage 50 \
    --storage-type gp3 \
    --db-subnet-group-name mysql-benchmark-subnet-group \
    --vpc-security-group-ids sg-01541b078e0b483d0 \
    --no-multi-az \
    --publicly-accessible \
    --backup-retention-period 0 \
    --no-auto-minor-version-upgrade

创建 EC2 测试实例

1
2
3
4
5
6
7
8

aws ec2 run-instances \
    --profile default --region ap-southeast-1 \
    --image-id ami-0d1c0ec9903f7b01f \
    --instance-type t3.medium \
    --key-name renxijun-ec2-key \
    --security-group-ids sg-0706d5fbe75649370 \
    --subnet-id subnet-09d864b724dce6434 \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=mysql-prepared-test-ec2}]'

4. 测试结果

4.1 MySQL 8.0.43 测试结果

紧凑格式 (spaces=0, SQL长度 ~100KB)

带空格格式 (spaces=128, SQL长度 ~6.5MB)

4.2 MySQL 5.7.44 测试结果

带空格格式 (spaces=128, SQL长度 ~6.5MB)

4.3 与原始报告对比

5. 结论

5.1 问题重现结果

在 MySQL 5.7.44 和 8.0.43 版本上，原始报告中描述的性能问题未能重现。

测试结果显示：

• 在两个版本上，useServerPrepStmts=true 反而比 false 更快
• MySQL 5.7.44: 服务器端预编译快 6.7 倍
• MySQL 8.0.43: 服务器端预编译快 4.0 倍

5.2 可能原因分析

1. MySQL 版本差异

   • 原始问题发现于 MySQL 5.7.29
   • 本次测试使用 MySQL 5.7.44 和 8.0.43
   • 问题可能已在 5.7.29 之后的版本中被修复

2. AWS RDS 优化

   • AWS RDS 可能包含特定的性能优化
   • 与原生 MySQL 行为可能存在差异

3. JDBC 驱动版本

   • 测试使用 mysql-connector-j-8.0.33
   • 驱动可能已优化参数处理逻辑

5.3 建议

1. 如需重现原始问题

   • 使用 MySQL 5.7.29 或更早版本
   • 使用原生 MySQL 而非 AWS RDS

2. 生产环境建议

   • 在较新版本的 MySQL 上，useServerPrepStmts=true 性能更优
   • 建议进行实际业务场景的性能测试
   • 对于大量参数的 IN 查询，考虑使用分批查询或临时表方案

6. 附录

6.1 测试日志

MySQL 8.0.43 完整输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

=== MySQL PreparedStatement性能对比测试 ===
连接信息: mysql-prepared-test.cfsoq6muu0jv.ap-southeast-1.rds.amazonaws.com:3306/test
参数数量: 50000
测试轮次: 3

测试配置: useServerPrepStmts=false
参数空格数: 128
SQL长度: 6500023 字符
执行第1次查询...
第1次: 571ms (返回0条记录)
执行第2次查询...
第2次: 317ms (返回0条记录)
执行第3次查询...
第3次: 314ms (返回0条记录)

=== useServerPrepStmts=false 测试结果 ===
总执行时间: 1202ms
平均执行时间: 400.7ms
返回记录数: 0
Com_stmt_prepare: 0 -> 0

测试配置: useServerPrepStmts=true
参数空格数: 128
SQL长度: 6500023 字符
执行第1次查询...
第1次: 138ms (返回0条记录)
执行第2次查询...
第2次: 92ms (返回0条记录)
执行第3次查询...
第3次: 73ms (返回0条记录)

=== useServerPrepStmts=true 测试结果 ===
总执行时间: 303ms
平均执行时间: 101.0ms
返回记录数: 0
Com_stmt_prepare: 0 -> 1

MySQL 5.7.44 完整输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

=== MySQL PreparedStatement性能对比测试 ===
连接信息: mysql57-prepared-test.cfsoq6muu0jv.ap-southeast-1.rds.amazonaws.com:3306/test
参数数量: 50000
测试轮次: 3

测试配置: useServerPrepStmts=false
参数空格数: 128
SQL长度: 6500023 字符
执行第1次查询...
第1次: 639ms (返回0条记录)
执行第2次查询...
第2次: 681ms (返回0条记录)
执行第3次查询...
第3次: 480ms (返回0条记录)

=== useServerPrepStmts=false 测试结果 ===
总执行时间: 1800ms
平均执行时间: 600.0ms
返回记录数: 0
Com_stmt_prepare: 0 -> 0

测试配置: useServerPrepStmts=true
参数空格数: 128
SQL长度: 6500023 字符
执行第1次查询...
第1次: 117ms (返回0条记录)
执行第2次查询...
第2次: 77ms (返回0条记录)
执行第3次查询...
第3次: 76ms (返回0条记录)

=== useServerPrepStmts=true 测试结果 ===
总执行时间: 270ms
平均执行时间: 90.0ms
返回记录数: 0
Com_stmt_prepare: 0 -> 1

6.2 参考资料

• MySQL PreparedStatement 性能问题重现项目
• MySQL Connector/J 文档

报告生成时间: 2026-01-12
测试执行者: Kiro CLI
AWS Account: 872515255872