关于本博

find me on twitter: @plantegg

知识星球：https://t.zsxq.com/0cSFEUh2J

Github: 欢迎star

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

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

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

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

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

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

精华文章推荐

在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

普京的克里米亚 —— 高晓松谈俄乌局势（2014年）

本文根据高晓松2014年《晓松奇谈》节目音频转录整理，原视频约54分钟。

一、克里米亚为什么重要

在西方人心中的地位

克里米亚对中国人来说不算特别著名，大概只有军迷比较熟悉——中国第一批航母飞行员就在克里米亚的陆上模拟航母基地训练过。但对西方人来说，克里米亚可太著名了。欧洲人提到克里米亚、塞瓦斯托波尔，比提到基辅（乌克兰首都）还要熟悉。巴黎有一条重要大街就叫”塞瓦斯托波尔大街”——法国这么骄傲的国家，用一个俄国地名来命名街道，正是因为法军攻克塞瓦斯托波尔是法国军事史上最光荣的战役之一。

克里米亚战争：现代战争的雏形

1853-1856年的克里米亚战争是英法联军加奥斯曼土耳其帝国对阵沙俄。这场战争创下了大量的”世界第一”：

• 第一次用电报指挥和发战报的战争——欧洲人第一次实时看到战争，相当于一场”直播的战争”
• 第一次有照片的战争——摄影术刚发明，克里米亚战争留下了最早的战地照片
• 第一批战地记者诞生于此
• 第一次使用线膛枪（莱福枪）的战争
• 第一次使用铁路运输的战争
• 第一次有战地救护的战争——著名的南丁格尔就在克里米亚战场上首次开展护理工作，护士节因此纪念南丁格尔
• 第一次蒸汽战舰参战
• 天气预报图首次被应用于军事
• “Red Line“（红线）这个成语的起源——英军步兵画了一条红线对抗哥萨克骑兵冲锋

可以说，克里米亚战争奠定了现代战争的雏形，是人类历史上第一场真正意义上的现代化战争（美国南北战争是几年后的第二场）。

对俄国的战略意义

俄国历代沙皇梦寐以求一个出海口。彼得大帝找到了圣彼得堡的出海口，但那只通往北欧，容易被封锁。俄国拼命向南扩张，终于见到了黑海，打到了克里米亚。这是全体俄国人”痛哭流涕”的大事——终于可以进入地中海，接触欧洲文明的中心了。

克里米亚对俄国的军事地位极为重要：有了克里米亚，黑海舰队就有了自己的基地（塞瓦斯托波尔）；没有克里米亚，就得租用乌克兰的基地，而租用的基地永远是不靠谱的——乌克兰随时可以涨价或收回。

二战中的克里米亚

二战德军第一能打的统帅曼施坦因元帅的成名作就是进攻克里米亚。他在缺乏坦克的情况下，带着德国步兵和一批罗马尼亚军队，面对拥有坦克、飞机和黑海舰队的苏军，艰苦地打下了克里米亚。围攻塞瓦斯托波尔时，德军调来了800毫米口径的超级大炮轰击要塞，创下人类战争史的纪录。曼施坦因在前线被升为元帅，从此一战成名。

二、普京——强人领导弱国

普京是什么人？用一句话概括：一个强人领导了一个弱国。

俄国不管从GDP还是其他方面来看，都不能算一个强国。不能说有原子弹就算强国——朝鲜还有原子弹呢。一辆像样的汽车都制造不出来的国家（拉达已经非常古老了），不能算一个强国。

这种情况非常像一战和二战时期的德国——二战前德国也没有美国和苏联强，但有了强人领导，就敢于冒险：占领苏台德地区、吞并奥地利、入侵波兰。日本当时也不是最强国，但有强人领导，就敢冒险发动战争。

普京的冒险路径：车臣 → 格鲁吉亚（南奥塞梯）→ 克里米亚，一步步试探西方底线。

三、克里米亚的法理之争

普京的理由

克里米亚一直到1954年还是俄罗斯的。赫鲁晓夫是乌克兰人，他上台后把克里米亚划给了乌克兰——当时都在苏联这一个国家内，只是行政区划变动，谁都没当回事。就像中国解放后撤销热河省、察哈尔省一样，大家反正都在一个国家里。

而且你去问欧洲人，所有人都会说克里米亚是俄罗斯的——因为从小读到的文学作品、看到的战争英雄，都是跟俄国打仗。

普京没有提到的事实

1991年苏联解体时，克里米亚人民举行了公投——54%的多数决定跟着乌克兰走。这次公投从国际法和基本法理来说都是合理的：一个大国分裂，局势未定，由人民公投决定归属——就像德国统一时，东德解散后五个州各自公投加入德意志联邦。

一个已经在一起20多年的国家，其中一部分地区能不能随时公投决定离开？这在国际上是一个复杂问题。

各国公投的不同命运

• 苏格兰：经过议会斗争，获得英国议会同意后公投，完全合法合理
• 魁北克：加拿大同意公投，但约定了公投间隔年限
• 加泰罗尼亚：西班牙不同意公投，所以全世界都不能承认
• 科索沃：西方支持公投独立，但西班牙和罗马尼亚因自身”麻筋”没有承认

普京抓得最准的一点就是拿科索沃做类比：你们支持科索沃公投独立，为什么不能支持克里米亚？

四、各国的态度与利益博弈

德国：最值得敬佩的表态

高晓松表示最敬佩的是德国。因为德国本身是最多领土在外面的国家——东普鲁士首府柯尼斯堡（现在的加里宁格勒）在二战后割给了俄罗斯，康德就在那里出生长大。如果德国支持克里米亚回归俄罗斯的逻辑，那柯尼斯堡要不要公投回德国？波兰西部原来也是德国的领土……这将引发连锁反应。

但德国总理默克尔第一个站出来坚决反对普京吞并克里米亚，等于堵住了未来德国追讨失去领土的后路。这是非常伟大的：再次向全世界表态，承认二战以后的所有边界，不再追求”历史上的领土”。

法国：暧昧

法国经济差，俄罗斯向法国订购了两艘”西北风”级两栖攻击舰（高晓松误说为四艘），给法国造船厂提供了大量就业机会。

英国：暧昧

俄国寡头大量住在伦敦，买了切尔西足球队，洗钱成本20%归了英国银行，投资房产推高了伦敦房价。

其他欧洲国家

对俄罗斯天然气和石油的依赖，让他们不敢太”闹”。

五、日内瓦协议：像极了慕尼黑协定

2014年签署的日内瓦协议由俄罗斯、乌克兰、欧盟和美国四方达成。高晓松震惊地发现，这个协议只字未提克里米亚——等于默认归俄罗斯了。协议只要求乌克兰其他地方的非正规武装解除武装。

这和1938年的慕尼黑协定惊人地相似：当年英法默认苏台德地区归德国，希特勒答应”没有别的需求了”——然后转眼就吞并了奥地利，紧接着入侵波兰。

“历史上没有一次绥靖真的让对方消停。什么时候才真消停？兵临城下，你再往前一步我就开炮。”

六、联合国投票的微妙格局

联合国大会（非安理会，无法律效力）对克里米亚问题的投票结果：

• 100国赞成谴责（以美欧为首）
• 11国反对（基本是反美的国家：白俄罗斯、委内瑞拉、朝鲜、古巴等）
• 58国弃权（最值得关注）
• 24国缺席

弃权的58国中包括金砖四国（除俄罗斯外的中国、印度、巴西、南非），这是给西方一个明确信号：这个世界来了新玩家，不是你们几个大国商量完就完了。

美国宣布胜利：100对11。俄罗斯也宣布胜利：93国没有支持美国（58弃权+11反对+24缺席）。

七、谁是最大受益者

中国：第一大受益者

高晓松认为中国是克里米亚事件的最大受益者，理由是”国运”论：

1. 冷战后期，西方为了拉拢中国对抗苏联，给了大量援助
2. 苏联解体后，西方刚要对付中国，拉登来了（911），于是又需要拉拢中国一起反恐
3. 好不容易击毙拉登，回头一看中国已经庞大极了
4. 刚要说”不能让你再大了”，俄罗斯又冲上去了——替中国挡住了西方的注意力

俄罗斯：短期受益、长期堪忧

克里米亚”装兜里了”，但被孤立的伤害在全球化时代比一战二战时期要严重得多。

八、”俄国对中国的伤害不亚于日本”

高晓松直言：

• 俄国从沙俄到苏联到今天，从没遵守过协议
• 日俄战争期间双方在中国东北都没少犯罪
• 二战末苏联把东北所有工厂、铁路全部拆走，银行黄金拉回苏联，发行废纸般的红军票
• 华人在俄国备受歧视，在莫斯科的市场被抢了不止一两次
• 在所有大国中，”对中国最好的就是美国”——建了清华大学、协和医院，给了大量援助，华人在美国可以当部长、州长、参议员

“不知道为什么网上的愤青天天骂美国、要跟俄国站一块。”

第二部分：事实校对

以下对节目中涉及的具体历史事实逐一查证，标注准确性。

校对1：克里米亚1950年代划归乌克兰

✅ 正确。 赫鲁晓夫于1954年2月19日签署法令，将克里米亚从俄罗斯苏维埃联邦社会主义共和国划归乌克兰苏维埃社会主义共和国。

校对2：”1991年公投54%决定跟乌克兰走”

⚠️ 部分正确，表述有误导性。 实际上1991年发生了两次公投：

• 1991年1月20日：克里米亚自治公投，问的是”是否恢复克里米亚自治苏维埃社会主义共和国”，94.3%赞成——这次公投的本意是让克里米亚恢复为苏联的直接主体，而非留在乌克兰。
• 1991年12月1日：乌克兰全国独立公投，克里米亚地区54.19%投赞成乌克兰独立。

“54%”这个数字来自后者。这不是克里米亚单独举行的”跟乌克兰还是跟俄罗斯”的公投，而是乌克兰全国公投在克里米亚地区的投票结果。

校对3：巴黎塞巴斯托波尔大街

✅ 正确。 巴黎确有 Boulevard de Sébastopol，长1,332米，宽30米，位于巴黎第1、2、3、4区之间，1855年以克里米亚战争中的塞瓦斯托波尔围攻命名。

校对4：克里米亚战争的多个”第一次”

更准确的说法是”最早之一”（one of the first），而非绝对第一：

校对5：”Red Line源自克里米亚战争”

❌ 不准确，有两处错误：

1. 正确名称是 “Thin Red Line”（细红线），不是 “Red Line”（红线作为”底线”的含义另有来源）
2. 1854年巴拉克拉瓦战役中，是93苏格兰高地兵团以两列纵深抵挡俄国骑兵（非专指哥萨克骑兵），记者Russell描述为 “a thin red streak topped with steel”

校对6：”曼施坦因一辆坦克都没有”

❌ 不准确。 塞瓦斯托波尔围攻期间，第11集团军拥有约150辆坦克，编成中包括第22装甲师和约65辆三号突击炮。曼施坦因确实以步兵为主力、装甲力量相对薄弱，但说”一辆坦克都没有”是错误的。

校对7：800毫米口径大炮

✅ 正确。 指的是**”古斯塔夫重炮”（Schwerer Gustav）**，口径800毫米，是有史以来实战使用过的最大口径线膛武器。1942年在塞瓦斯托波尔围攻中发射了47发炮弹。另有三门600毫米卡尔臼炮参战。

校对8：”法国订购四艘大型登陆舰”

❌ 数量不准确。 实际是两艘（不是四艘）”西北风”级（Mistral-class）两栖攻击舰，分别命名为”符拉迪沃斯托克号”和”塞瓦斯托波尔号”。合同金额12亿欧元。

校对9：联合国投票100:11:58

✅ 完全正确。 2014年3月27日联合国大会第68/262号决议投票结果：100票赞成、11票反对、58票弃权、24国缺席。金砖四国（中印巴南）均弃权。

校对10：苏联策动外蒙古独立公投

✅ 基本正确。 1945年10月20日举行公投，官方结果100%赞成独立（487,409票赞成，0票反对），投票率98.47%。公投是在苏联压力下、中国被迫签署《中苏友好同盟条约》后进行的，100%的结果显然不可能是自由投票。

校对11：”美国援助超过中国赔款总和的数十倍”

❌ 夸大。 中国近代主要赔款（《南京条约》《马关条约》《辛丑条约》等）折合约7-13亿美元；美国二战租借法案援华约16.27亿美元加上其他援助约20-30亿美元，大约为赔款的2-4倍量级，远非”数十倍”。

校对总结

第三部分：十年后验证——2014年预测 vs 2026年现实

高晓松在2014年做了若干关于未来的预测和判断。12年后，哪些被证实了？

预测1：”克里米亚这件事远远没完” ★★★★★

完全正确，甚至超出预期。

• 2014年起，顿巴斯地区爆发武装冲突
• 2014年7月，马航MH17被俄制导弹击落，298人遇难
• 2022年2月24日，俄罗斯发动全面入侵乌克兰——二战以来欧洲最大规模地面战争
• 战争造成数十万人伤亡，数百万难民

高晓松说得对：克里米亚只是一个开始。

预测2：”日内瓦协议就像慕尼黑协定” ★★★★★

慕尼黑类比精准。 日内瓦协议签字墨迹未干，顿巴斯冲突就全面升级。2015年明斯克协议同样未能约束俄罗斯。默克尔后来承认，明斯克协议在某种程度上只是为乌克兰争取了准备时间。绥靖确实没有让普京停下。

预测3：”中国是最大受益者” ★★★☆☆

部分正确，但有重大保留。

获益面：

• 以大幅折扣购买俄罗斯石油天然气
• 中俄关系中中方主导地位更加明确
• GDP从2014年10.7万亿美元增长到2024年18.7万亿美元

代价面：

• 中美关系急剧恶化，面临技术脱钩、芯片禁令
• 被视为俄罗斯”沉默盟友”，在欧洲声誉下降
• 经济增速从7%+降至~4.5%，房地产危机等内部问题
• 与美国GDP差距以美元计反而从6.9万亿扩大到10.5万亿

“最大受益者”过于乐观。

预测4：”俄国长远被孤立受伤害” ★★★★☆

基本正确。

2022年后俄罗斯遭受史无前例的制裁：

• 约3,000亿美元央行外汇储备被冻结
• 超过1,000家跨国公司撤出
• SWIFT切断
• 国际刑事法院对普京发出逮捕令
• 芬兰、瑞典加入北约（30→32国），”安全缓冲区”反而缩小

但俄罗斯经济在战时体制下并未崩溃，通过中印等国部分规避制裁，韧性超出预期。

预测5：”叙利亚反对派彻底失败” ★☆☆☆☆

严重误判。这是高晓松最大的错误。

• 2015年俄罗斯直接军事介入后，阿萨德政权确实稳住了
• 2016-2023年反对派退缩到伊德利卜等有限区域
• 2024年12月——惊天逆转：反对派发动闪电攻势，12月8日推翻阿萨德政权。阿萨德出逃，反对派组建过渡政府

历史证明，”彻底”二字往往靠不住。

预测6：”等普京时代过去，中国几乎跟美国一样强大” ★★☆☆☆

与现实有较大偏差。

普京仍在位（2024年”连任”至2030年，修宪可执政到2036年）。中美差距以美元计反而扩大，人口老龄化、房地产危机、半导体”卡脖子”等使追赶放缓。

预测7（事实验证）：法国军舰交易

交易最终被取消。 2014年9月法国暂停交付，2015年8月正式取消，退款约9.5亿欧元。两艘舰转售埃及。

预测8（事实验证）：切尔西与俄国寡头

2022年后遭清算。 阿布拉莫维奇被英国制裁，切尔西以25亿英镑强制出售给美国财团。伦敦”Londongrad”时代终结，大量俄寡头资产被冻结。

预测9（事实验证）：苏格兰独立公投

公投举行但独立被否决。 2014年9月18日，55%反对、45%支持。2022年英国最高法院裁定苏格兰无权自行举行第二次公投。

预测10：”不能一方用坦克一方用冰糖雪梨” ★★★★★

极具前瞻性。 2022年后西方政策发生根本转变：

• 美国援乌超1,150亿欧元，包括防空导弹、HIMARS等
• 德国设立1,000亿欧元特别国防基金
• 从”只给防弹衣”升级到提供豹2坦克、F-16战斗机
• 芬兰、瑞典加入北约

从”冰糖雪梨”转向大规模军事援助——虽然这个觉醒晚了8年。

总体评价

高晓松在地缘政治大势上展现了相当敏锐的洞察力——对俄罗斯扩张意图和西方绥靖政策的批评极为准确。主要失误在于对叙利亚的判断（低估历史不确定性）和对中国崛起速度的过于乐观。

12年后回看，他在2014年的分析水准明显超出了当时大多数中文媒体评论者。最核心的判断——“绥靖不会带来和平，克里米亚只是开始”——被2022年的全面战争彻底证实。

从 0 到 1 复刻一个 Claude Code 这样的 Agent

基于 DBA 运维 Agent 的实战开发过程，结合 ReAct 论文原理，帮助你理解 Claude Code 这类 Agent 的工作本质，并具备自己动手构建一个专属 Agent 的能力。

为什么要了解 Agent

我们日常使用 Claude Code 这样的工具时，可能觉得它很神奇——丢一个问题进去，它就能帮你定位问题、修改代码、甚至操作服务器。但如果你不理解它背后的运行原理，就很难把 AI 真正融入自己的工作流。

了解 Agent 的意义有两个层面：

1. 理解原理，提升使用效率：知道 Claude Code 怎么工作的，你就知道怎么更好地跟它协作，什么该交给它，什么需要你来把控。
2. 自己动手，定制专属工具：当你理解了 Agent 的本质之后，你完全可以基于公司提供的 API 和模型，开发一个专属于自己业务场景的 Agent——比如一个 MySQL 运维 Agent、一个监控告警分析 Agent。

本文的目标就是：通过开发一个极简的 MySQL 运维 Agent，彻底搞懂 Claude Code 这类工具是怎么工作的。以后再看到小龙虾/Claude code/kiro 这样的 agent/智能体就犹如庖丁解牛

一、从”一问一答”到”自主解决问题”

网页聊天 vs Agent 的本质区别

以前我们在网页上使用大模型，交互方式是一问一答：你丢一个问题，模型基于训练数据吐一个答案，仅此而已。模型不知道你的服务器状况，不知道你的数据库配置，也没办法帮你执行任何命令。

Claude Code 的方式完全不同。它拿到你的问题之后，会带着一堆工具（比如执行 bash 命令、读写文件、查看 CPU 等），反复跟大模型交互：

1. 把你的问题 + 工具列表发给大模型
2. 大模型分析后说：”帮我执行一下 top 命令”
3. Claude Code 执行 top，把结果塞回去
4. 大模型看到结果，又说：”再帮我看一下磁盘”
5. 继续执行，继续把结果塞回去
6. 反复迭代十几轮，直到大模型说：”信息够了，我来给你最终结论”

对用户来说，你只输入了一句话，然后等着就行。 但背后 Agent 可能已经跟模型来回跑了十几轮。

2025 年 AI 为什么突然”厉害了”

很多人感觉从 2025 年下半年开始，AI 工具突然变得非常实用——能帮你写代码、部署服务、定位故障。但这里有一个常见的误解：不是模型本身变强了多少，而是 Agent 这个”客户端”变强了。

以前的模型只能基于训练数据回答问题，现在的 Agent 可以不断地给模型”喂”新信息——实时的系统状态、数据库查询结果、日志内容。模型不再是闭卷考试，而是变成了”开卷 + 有助手帮你翻书”的模式。

二、两个必须记住的基本原则

原则一：模型没有记忆

这一点非常关键，虽然很多人在各种文章中看到过，但可能理解不够深刻。

大模型是没有任何记忆的。 不管你是同一个账户、同一次会话，前后两次提问之间，模型不会记住或关联它们。你觉得它”记住了”上一轮的内容，那是因为 Agent 帮它做了一件事：把前面所有的对话历史、工具执行结果，全部打包成一个巨大的 prompt，每次都完整地发给模型。

所以你会看到，每一轮交互，Agent 发给模型的内容会越来越长——第一轮可能 1000 字，第五轮可能 5000 字，第十轮可能上万字。这就是为什么 token 消耗会这么快。

原则二：模型永远不会执行工具

大模型自己不会也不能执行任何工具。它只做一件事：根据你的问题和已有信息，告诉 Agent 应该调用什么工具、参数是什么。

真正去执行 SSH 命令、跑 MySQL 查询的是 Agent 程序本身。执行完之后，Agent 也不理解这些返回结果（可能成功了、可能报错了），它只是原样把结果丢给模型，让模型来判断下一步该怎么做。

三、什么是 Agent

Agent（智能体）= 让模型持续思考、持续调用外部工具、直到解决用户问题的程序。

Claude Code、OpenCode 这些都是 Agent，它们只是一个客户端工具，背后需要一个大模型来完成推理工作。

用一张图来理解：

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

       你的代码（Agent 框架）
       ┌──────────────────────────────────────────┐
       │                                          │
用户 ─►│  循环 {                                  │
       │    1. 把问题 + 工具列表 发给 LLM          │
       │    2. LLM 返回: 我要调用 XX 工具          │
       │    3. Agent 执行工具，拿到结果             │
       │    4. 把结果喂回给 LLM                    │
       │    5. LLM 判断：信息够了吗？               │
       │       - 不够 → 回到 1                     │
       │       - 够了 → 输出 Final Answer          │
       │  }                                        │
       └──────────────────────────────────────────┘

核心区别：

• 普通 LLM 调用：一问一答，模型只能靠训练数据回答
• Agent 模式：模型可以主动调工具获取实时信息，多轮推理后给出答案

这里还有一个细节值得注意：Agent 启动时会把所有工具的定义（名称、用途、参数说明）都一次性发给模型。比如你配了 GitHub、MCP、bash 等几十个工具，不管你的问题跟哪个工具有没有关系，全部都会带上。这就是为什么你一打开 Claude Code，上下文消耗就已经很高了——因为光工具定义就占了几万字。

四、ReAct：Agent 的核心工作模式

ReAct（Reasoning + Acting）是目前 Agent 最主流的工作模式，来自 2022 年发表的论文 ReAct: Synergizing Reasoning and Acting in Language Models。

核心循环

1
2
3
4
5
6
7
8
9
10

┌─────────────────────────────────────────────────────┐
│                    ReAct 循环                        │
│                                                     │
│   Thought ──► Action ──► Observation ──► Thought    │
│   (思考)      (行动)      (观察)         (再思考)    │
│      │                                     │        │
│      └─────── 信息不够，继续循环 ◄──────────┘        │
│                                                     │
│               信息够了 ──► Final Answer              │
└─────────────────────────────────────────────────────┘

核心理念是：大模型先思考（Thought）当前需要什么信息，然后决定一个行动（Action）让 Agent 去执行，Agent 执行后返回观察结果（Observation），模型再根据新信息继续思考。这个循环不需要你写任何 if-else 逻辑——模型自己决定调什么工具、调几次、什么时候停。

以前我们写自动化程序，靠的是模板匹配和条件判断，需要穷举各种场景，所以做起来很麻烦、动不动就要改。现在 Agent 把所有判断逻辑交给了模型，模型来决定下一步做什么。

实际运行示例

以”检查 MySQL 主从复制状态”为例，Agent 的实际思考过程：

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

[LLM #1]
  Thought: 需要检查主从状态，先看 SHOW SLAVE STATUS
  Action: mysql_query
  Action Input: {"query": "SHOW SLAVE STATUS"}
  → 工具返回: [无结果集]（说明不是从库）

[LLM #2]
  Thought: 不是从库，看看是不是主库
  Action: mysql_query
  Action Input: {"query": "SHOW MASTER STATUS"}
  → 工具返回: mysql-bin.000007 | 180681919 | ... | GTID:1-1833162

[LLM #3]
  Thought: 是主库。再看有没有从库连上来
  Action: mysql_query
  Action Input: {"query": "SHOW SLAVE HOSTS"}
  → 工具返回: [无结果集]（没有从库连接）

[LLM #4]
  Thought: 主库正常但无从库，再查半同步状态和错误日志
  Action: ssh_command
  Action Input: {"command": "tail -50 /data0/mysql_3306/log/error.log"}
  ...

[LLM #6]
  Thought: I now know the final answer
  Final Answer: ## 诊断报告 ...

在这个过程中，模型自己判断了：先查从库状态 → 发现不是从库 → 转查主库状态 → 确认是主库 → 检查从库连接 → 查日志。你完全不需要预设这些逻辑，模型根据每一步的返回自行决策。

五、Agent 开发三要素

1
2
3
4
5
6
7
8
9

┌────────────────────────────────────────────┐
│              Agent = LLM + Tools + Prompt   │
│                                            │
│  ┌─────────┐  ┌─────────┐  ┌───────────┐  │
│  │   LLM   │  │  Tools  │  │  Prompt   │  │
│  │  大模型  │  │  工具集  │  │ 角色定义  │  │
│  │  (大脑)  │  │  (手脚)  │  │  (指令)   │  │
│  └─────────┘  └─────────┘  └───────────┘  │
└────────────────────────────────────────────┘

80% 的开发工作在写 Tools。 LLM 和 Prompt 通常很快就定了。

六、Step by Step 开发流程

Step 1：明确场景，定义工具边界

先回答三个问题：

• Agent 要解决什么问题？→ MySQL/Linux 远程只读诊断
• 需要哪些工具？→ SSH 执行命令、MySQL 查询、写报告文件
• 安全边界是什么？→ 只读，不能执行写操作

1
2
3
4

场景：DBA 日常诊断
  ├── 需要 SSH 执行命令 → ssh_command 工具
  ├── 需要查 MySQL   → mysql_query 工具
  └── 需要保存报告   → write_file 工具

工具代码中的注释（description）非常重要——模型就是靠这些描述来决定什么时候调用哪个工具、传什么参数。这些注释不是给人看的，是给模型看的。

为了安全起见，我们还需要给工具加上黑白名单，比如 MySQL 工具只允许 SHOW、SELECT 等只读操作，禁止 DROP、DELETE、TRUNCATE 等危险命令。

Step 2：搭项目结构

1
2
3

mkdir -p ~/q/agent/tools
touch ~/q/agent/{config.yaml,main.py,crew.py,requirements.txt}
touch ~/q/agent/tools/{__init__.py,ssh_tool.py,mysql_tool.py,write_file_tool.py}

Step 3：写工具（核心工作量）

每个工具就是一个 Python 类，继承 BaseTool，实现 _run 方法：

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

from crewai.tools import BaseTool
from pydantic import BaseModel, Field

class MySQLQueryInput(BaseModel):
    query: str = Field(description="要执行的 SQL 查询语句")

class MySQLQueryTool(BaseTool):
    name: str = "mysql_query"
    description: str = "执行 MySQL 只读查询..."  # 模型靠这段话决定什么时候用这个工具
    args_schema: Type[BaseModel] = MySQLQueryInput

    def _run(self, query):
        # 1. 安全检查（只读白名单）
        # 2. 执行查询
        # 3. 返回格式化结果（字符串）
        return "结果文本"

工具开发要点：

• description 写清楚——模型靠它判断何时调用
• _run 返回纯文本——模型只能处理文本
• 做好安全拦截——模型可能尝试危险操作
• 加超时控制——防止 tail -f 等命令无限阻塞

Step 4：配置 LLM 连接

1
2
3
4
5

# config.yaml
llm:
  model: "openai/claude-sonnet-4-5-20250929"
  base_url: "https://your-api-gateway/v1"
  api_key: "sk-xxx"

1
2
3
4
5
6

from crewai import LLM
llm = LLM(
    model="openai/claude-sonnet-4-5-20250929",
    base_url="https://your-api-gateway/v1",
    api_key="sk-xxx"
)

注意：如果 API 网关是 OpenAI 兼容协议，模型名需要加 openai/ 前缀让 litellm 走 OpenAI 通道。

Step 5：组装 Agent

1
2
3
4
5
6
7
8
9
10

from crewai import Agent, Task, Crew

agent = Agent(
    role="DBA 运维专家",
    goal="诊断 MySQL 和 Linux 运行状况",
    backstory="你是资深 DBA，精通 MySQL 5.7/8.0...",
    tools=[ssh_tool, mysql_tool, write_tool],
    llm=llm,
    verbose=True,
)

Step 6：跑起来

1
2
3
4
5
6
7
8

task = Task(
    description="用户问题: %s" % user_input,
    expected_output="诊断结果和建议（中文）",
    agent=agent,
)
crew = Crew(agents=[agent], tasks=[task])
result = crew.kickoff()
print(result)

七、实战：一次完整的诊断过程

我们给 Agent 一个实际任务：”分析 SQL 响应时间以及内存资源”。

Agent 开始工作后，debug 模式下可以看到完整的交互过程：

第 1 轮：模型收到问题，决定先查慢查询配置

1
2

Action: mysql_query → SHOW GLOBAL VARIABLES LIKE '%slow%'
Observation: slow_query_log=ON, long_query_time=0.5

第 2 轮：模型知道了慢查询阈值是 0.5 秒，继续查慢查询数量

1
2

Action: mysql_query → SHOW GLOBAL STATUS LIKE 'Slow_queries'
Observation: Slow_queries=21

第 3 - 8 轮：模型继续查询 QPS、线程状态、锁信息、查询缓存…

第 9 - 12 轮：模型觉得还需要看系统资源，自动通过 SSH 执行 top、free 等命令

第 18 轮：模型终于认为信息足够了，输出 Final Answer：

• 慢查询数量：21 条，阈值 0.5 秒
• QPS 统计和慢查询占比
• 锁等待分析
• 内存使用状况
• 综合评分和优化建议

整个过程中，你只输入了一行命令，但 Agent 已经自动完成了 18 轮诊断。 这就是 Agent 的魅力所在。

八、踩坑记录

实际开发中遇到的问题和解决方案（这部分经验非常重要，第一次把代码写出来能直接跑通的概率几乎为零）：

关键经验：模型第一次生成的代码几乎不可能直接跑通。 你需要提供一个真实的调试环境（一台可以 SSH 的机器、一个可以连的 MySQL 实例），让 AI 在真实环境中反复调试。这个调试和验证的过程，才是开发 Agent 中最关键的一步。你需要做的是给 AI 搭好舞台——准备好机器、配好免密、提供连接信息，然后让它自己去试、去修、去迭代。

九、调试技巧

加 –debug 看完整的 LLM 交互

1

python3 main.py --host 10.0.0.1 --debug "检查MySQL版本"

输出每次发给模型的完整 prompt 和模型的完整回复，能清楚看到：

• 模型在”想”什么（Thought）
• 模型决定调什么工具（Action）
• 工具返回了什么（Observation）
• Token 消耗量

先单独测试工具

不要一上来就跑完整 Agent，先验证每个工具独立可用：

1
2
3
4
5
6
7

from tools.ssh_tool import SSHCommandTool
ssh = SSHCommandTool(host="10.0.0.1", cmd_timeout=10)
print(ssh._run("uptime"))

from tools.mysql_tool import MySQLQueryTool
mysql = MySQLQueryTool(host="10.0.0.1", mysql_password="xxx")
print(mysql._run("SELECT VERSION()"))

关键公式

1

Agent 效果 = 模型能力 × 工具质量 × Prompt 清晰度

• 模型不够强 → 换更大的模型
• 工具返回乱码 → 格式化输出
• 模型不知道用哪个工具 → 改 description
• 模型反复出错重试 → 加 –debug 看 prompt，调 backstory

十、进阶思考：从个人效率到团队赋能

第一阶段：用好现有工具

把 Claude Code 这样的工具融入日常工作，让以前花两三个小时的任务，现在 5 分钟搞定。这是最基础的提效。

第二阶段：定制专属 Agent

结合自己的业务场景，开发专属 Agent。比如 DBA 运维 Agent，可以进一步接入更多数据源：

• 监控数据：接入 Prometheus，让 Agent 能查看历史指标趋势
• 日志平台：接入 SLS 等日志服务，让 Agent 能自动拉取和分析错误日志
• 元数据库：接入 DBA 平台的元数据，让 Agent 通过实例名自动查到机器、端口、配置
• 即时通讯：接入飞书、Telegram 等，让团队成员直接在群里向 Agent 提问

工具越丰富，Agent 能做的事情就越多。 你最了解自己的日常工作，最清楚哪些环节可以让 Agent 来接手。

第三阶段：理解原理，看透产品

当你真正理解了 Agent 的运行原理之后，再去看市面上各种 AI 产品，你会发现：

• 它们的核心原理都是一样的——ReAct 循环 + 工具调用
• 产品之间的差异主要在于：提供了哪些工具、交互界面做成什么样、安全策略怎么设计
• 有些产品把命令行工具做成了白屏化的界面，降低了使用门槛，所以对非技术人员更友好
• 有些产品默认不做授权确认，用起来更”丝滑”，但在生产环境需要注意安全风险

理解了本质，你就能站在更高的视角去评估和选择工具，而不是被产品的外表所迷惑。

完整提示词参考

如果你想自己复刻这个 MySQL 运维 Agent，只需要将以下提示词依次交给 Claude Code：

起始提示词（创建项目）：

1
2
3
4
5

我想基于 CrewAI 来实现一个我自己的 DBA 运维 agent，~/q/agent/
我提供 ip+端口+账户+密码，agent 能通过 ssh 访问 ip 所在的机器，
也能够通过 mysql client 拉取所要的信息（只能是读，不能对实例做任何修改），
请帮我实现这样一个 agent，用 python 代码，可以提供一个配置文件配置好默认的账号+密码/端口；
我想在控制台完整输出 agent 发给 LLM 的提示词，以及完整的 LLM 返回内容，以便我学习

调试提示词（非常关键）：

1
2
3
4

<目标IP> 是我的部署机器，ssh root 免密了，请帮我部署并调试，
需要被调试的 mysql 机器是 <MySQL IP> <端口>
mysql -uroot -S /data0/mysql_${port}/data/mysql.sock -p<密码>
从部署机器 ssh root@<MySQL IP> 也是免密了

修复 Bug 示例：

1
2

请帮我修复当执行 ssh_command 比如 tail -100 /data0/mysql_3306/log/slow-queries.log
因为没有足够多 slow query 的产生导致 tool 一直不返回，请增加超时时间比如 10 秒（可配置）

增加工具示例：

1
2

非常好，现在帮我加一个写文件的 tool，然后可以将大模型的输出写入到某个文件中；
同时帮我生成一份 README.md 里面要有 --debug 时输出的解读

项目架构

1
2
3
4
5

用户输入 → main.py (CLI) → crew.py (CrewAI Agent)
                                ├── SSHCommandTool  (paramiko → 目标机)
                                └── MySQLQueryTool  (paramiko SSH → mysql CLI → unix socket)
                                         ↓
                            LLM: Claude Sonnet 4.5 via API 网关

使用方式：

1
2
3
4
5
6
7
8
9
10

cd /data0/scripts/agent

# 交互式模式
python3 main.py --host <目标IP> --mysql-port 3306

# 单次命令
python3 main.py --host <目标IP> --mysql-port 3306 "检查主从复制状态"

# 调试模式（查看完整 LLM 交互）
python3 main.py --host <目标IP> --mysql-port 3306 --debug "分析慢查询"

总结

一句话概括：Agent 就是一个死循环，把你的问题和工具带给模型，模型指挥 Agent 执行，执行结果再喂回模型，直到模型说”够了，这是最终答案”。

理解了这个本质，你就理解了 Claude Code、以及市面上所有 AI Agent 产品的工作原理。

TCP 网络性能排查实战：两个经典案例的深度学习总结

概述

本文总结了两个真实的 TCP 网络性能问题排查案例，涉及 Kafka 消息队列在跨机房和同机房场景下的延迟问题。两个案例从不同角度揭示了 TCP 缓冲区、拥塞控制、内核参数对应用性能的深远影响。

案例一：跨机房 Kafka 消费延迟高达 10 分钟

问题描述

每天上午 9:30 开盘后，位于 Region-B 的 Kafka 消费者从 Region-A 的 Kafka Broker 拉取消息时，延迟不断增高到 10 多分钟，持续数小时才恢复。而 Region-A 同机房的消费者拉取同一 Topic 完全正常。

排查过程

整个排查经历了多个阶段，逐步逼近根因：

阶段一：排除基础设施问题

• Broker/Client 进程状态、机器资源（CPU/内存/磁盘）均正常
• 网络带宽充足，丢包率正常，wget 测试带宽足够
• 初步怀疑方向：网络链路本身

阶段二：发现拥塞窗口异常（TCP 层面）

在客户端机器上抓包分析，发现关键线索：

1
2
3
4
5
6

# 查看 TCP 连接的拥塞窗口
ss -itmpn dst "x.x.x.x"

# 关键输出（问题连接）
cwnd:2 ssthresh:2    ← 拥塞窗口极小，只有 2 个 MSS
send 170.0Kbps       ← 发送速率极低

RTT 约 130ms，拥塞窗口只有 2（约 2.9KB），理论吞吐量：2 × 1448 / 0.13 ≈ 22KB/s，远不够传输开盘时的行情数据。

尝试通过 wget 大文件把 ssthresh 撑大，然后重启客户端新建连接，问题暂时缓解。但第二天又复发。

阶段三：发现内核虚假重传（深入内核层面）

通过 Wireshark 分析抓包文件，发现一个异常现象：

Broker 发送响应后，如果 10ms 内没收到 ACK，就触发重传。而正常的 RTO 应该是 200ms+。

这种 10ms 的重传远低于 RTO，也不是快速重传或 TLP。最终定位到 Linux 3.10 内核的 tcp_early_retrans 参数：

1
2
3
4
5
6

# 查看当前值
sysctl net.ipv4.tcp_early_retrans
# 输出: net.ipv4.tcp_early_retrans = 3

# 这是 3.10 内核 backport 新版本 early retrans 功能时引入的 bug
# 导致大量虚假重传，进而让拥塞控制算法误判网络拥塞，不断缩小 cwnd

修复方法：

1

sysctl -w net.ipv4.tcp_early_retrans=0

修改后，全网 TCP 重传率从万分之 5 降到正常水平。

阶段四：发现 Send Buffer 限制

解决虚假重传后，抓包发现新的瓶颈：

Broker 发送一批数据包后，在途字节（Bytes in flight）达到约 50KB 就停止发送，等一个 RTT（~130ms）收到 ACK 后才继续。

原因：Kafka Broker 默认配置 socket.send.buffer.bytes=102400（100KB），内核实际分配约一半（~50KB），限制了发送窗口。

阶段五：定位根因 — 客户端接收 Buffer

将 Broker Send Buffer 限制去掉后仍然不行。最终在客户端日志中找到关键配置：

1

receive.buffer.bytes = 65536    ← Kafka 客户端默认只有 64KB 接收缓冲区

TCP 三次握手时，客户端根据 receive.buffer.bytes 通告接收窗口（rwnd）。64KB 的 rwnd 意味着：

1

最大吞吐量 = rwnd / RTT = 64KB / 130ms ≈ 490KB/s

而开盘高峰期需要数十 MB/s 的吞吐量，64KB 的接收窗口成为致命瓶颈。

根因与解决方案

根因：Kafka 客户端默认接收缓冲区 64KB 太小，叠加跨机房 130ms 的 RTT，导致 TCP 吞吐量被严重限制。

解决方案：

1
2
3
4
5
6
7
8
9

# Kafka Consumer 配置
receive.buffer.bytes = 2097152    # 从 64KB 调整到 2MB（或设为 -1 让 OS 自动调优）

# Kafka Broker 配置
socket.send.buffer.bytes = -1     # 去掉 100KB 限制，让 OS 自动调优
socket.receive.buffer.bytes = -1

# Linux 内核参数（3.10 内核）
net.ipv4.tcp_early_retrans = 0    # 关闭有 bug 的 early retrans

效果：传输延迟从 10-60 分钟降低到 1-4 秒，性能提升约 1000 倍。

调整前后的 Wireshark 抓包对比：

1
2

调整前：485KB 数据需要 8 个 RTT（8 × 130ms = 1040ms）分批传输
调整后：485KB 数据在 3ms 内一次性传输完毕

案例二：同机房 TCP 订阅客户端异常缓慢

问题描述

同机房 4 台机器部署了相同的行情订阅服务，其中 1 台拉取行情数据异常缓慢。

排查过程

第一步：抓包发现 TCP Zero Window

在客户端抓包，发现大量 TCP Zero Window 通告——客户端在告诉服务端”我的接收缓冲区满了，别再发了”。

第二步：确认 Recv Buffer 堆满

1
2

netstat -ant | grep <server_port>
# 发现 Recv-Q 持续满载

第三步：发现 CPU 异常

1
2

top -Hp <java_pid>
# 发现一个线程 CPU 持续接近 100%，像死循环

第四步：定位代码问题

1
2
3
4
5

# 用 top 看到的线程 ID（十进制）转十六进制
printf '%x\n' <thread_id>

# 在 jstack 中查找对应线程堆栈
jstack <java_pid> | grep -A 30 <hex_thread_id>

找到问题代码：一个 for 循环中调用 read()，每次只读很少的数据（参数配置过小），导致：

1. 应用层读取速度跟不上网络数据到达速度
2. OS TCP Recv Buffer 被填满
3. TCP 通告 Zero Window，服务端停止发送
4. 该线程 CPU 100%（不停地循环读取微量数据）

根因与解决方案

根因：业务代码中 read() 的缓冲区参数配置过小，导致应用层消费速度远低于网络数据到达速度，TCP Recv Buffer 堆满触发 Zero Window。

解决方案：修复代码，增大 read() 的缓冲区大小。

效果：

• 网络吞吐量恢复正常（流量曲线从”平台”变为正常波动）
• CPU 使用率从 40% 降到 20%

两个案例的关联与对比

两个案例本质上都是 TCP 接收端处理能力不足 导致发送端被限速：

1
2

案例一：接收窗口太小 → 发送端每个 RTT 只能发 64KB → 跨机房 RTT 大放大了问题
案例二：应用层读取太慢 → Recv Buffer 堆满 → Zero Window → 发送端完全停止

TCP 缓冲区与窗口的核心原理

1
2
3
4
5
6
7
8
9
10
11

发送方应用 write()
       ↓
  Send Buffer (sk_sndbuf)
       ↓  受发送窗口限制
  发送窗口 = min(拥塞窗口 cwnd, 接收窗口 rwnd)
       ↓
  网络传输 (in-flight data)
       ↓
  Receive Buffer (sk_rcvbuf)
       ↓  通告 rwnd = buffer_size - 已占用空间
  接收方应用 read()

关键关系：

• 接收窗口 rwnd：由接收端 Recv Buffer 剩余空间决定，通过 ACK 通告给发送端
• 拥塞窗口 cwnd：由发送端拥塞控制算法（如 CUBIC）动态调整
• 发送窗口：取 rwnd 和 cwnd 的较小值
• 最大吞吐量：min(rwnd, cwnd) / RTT

为什么 RTT 大时 Buffer 小的问题会被放大？

1
2

同机房 (RTT=1ms):   吞吐量 = 64KB / 1ms   = 64MB/s   ← 够用
跨机房 (RTT=130ms): 吞吐量 = 64KB / 130ms  = 490KB/s  ← 严重不足

这就是案例一中”同机房正常、跨机房延迟”的根本原因。

关键排查命令速查

TCP 连接状态分析

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

# 查看 TCP 连接详细信息（拥塞窗口、RTT、重传等）
ss -itmpn dst "x.x.x.x"

# 关键字段解读
# cwnd:10        拥塞窗口（MSS 数量）
# ssthresh:2     慢启动阈值
# rtt:130/0.5    RTT 均值/方差（ms）
# rto:330        重传超时（ms）
# send 850Kbps   当前发送速率
# unacked:38     未确认的包数量
# retrans:0/3    当前重传/累计重传

# 查看 TCP 缓存指标
ip tcp_metrics show | grep <ip>

# 查看连接队列
netstat -ant | grep <port>
# Recv-Q: 接收队列（应用未读取的数据）
# Send-Q: 发送队列（已发送未确认的数据）

网络重传监控

1
2
3
4
5

# 实时观察 TCP 重传
watch -n 1 'nstat -az | grep TcpRetransSegs'

# 检查 early retrans 参数（3.10 内核）
sysctl net.ipv4.tcp_early_retrans

抓包分析

1
2
3
4
5
6
7

# 抓取指定端口的包
tcpdump -i eth0 port 9092 -w capture.pcap

# Wireshark 中关键过滤器
tcp.analysis.zero_window          # Zero Window 事件
tcp.analysis.retransmission       # 重传包
tcp.analysis.bytes_in_flight      # 在途字节数

Java 应用排查

1
2
3
4
5
6
7
8

# 查看 Java 进程中各线程 CPU 使用
top -Hp <java_pid>

# 线程 ID 转十六进制
printf '%x\n' <thread_id>

# 导出线程堆栈并查找
jstack <java_pid> | grep -A 30 <hex_thread_id>

经验教训

1. 不要信任中间件的默认配置

Kafka 客户端默认 receive.buffer.bytes=64KB、Broker 默认 socket.send.buffer.bytes=100KB，这些值在同机房低延迟环境下够用，但在跨机房高 RTT 场景下会成为致命瓶颈。

建议：跨机房部署时，将 buffer 相关配置设为 -1（让 OS 自动调优），或根据 BDP = 带宽 × RTT 计算合理值。

2. 内核参数可能是隐藏的定时炸弹

Linux 3.10 内核的 tcp_early_retrans=3 导致大量虚假重传，拉高全网重传率到万分之 5，掩盖了真实的网络问题。这种问题平时不显现，只在高负载时爆发。

建议：关注内核版本差异，定期检查 TCP 重传率是否异常。

3. 学会用 Wireshark 做对比分析

排查网络问题最有效的方法是：抓一份有问题的包、一份正常的包，在 Wireshark 中对比分析。关注：

• Bytes in flight 的变化曲线
• ACK 之间的间隔（是否有等待平台）
• 是否有异常重传

4. 应用层的 Bug 也会表现为网络问题

案例二中，业务代码 read() 缓冲区配置过小导致 TCP Zero Window，表面看是”网络问题”，实际是应用层 Bug。排查时不要只盯着网络层，要结合 top -Hp + jstack 看应用层行为。

5. 理解 BDP（带宽延迟积）

1

BDP = 带宽 × RTT

这是网络管道中能容纳的最大数据量。TCP Buffer 至少要等于 BDP 才能充分利用带宽。例如：

1
2
3
4
5

带宽 100Mbps, RTT 130ms:
BDP = 100Mbps × 0.13s = 13Mb = 1.6MB

→ TCP Buffer 至少需要 1.6MB 才能跑满带宽
→ 64KB 的 Buffer 只能利用 64KB/1.6MB ≈ 4% 的带宽

6. 排查要有层次感

1
2
3
4
5
6
7
8
9

应用层 → 是否有代码 Bug、配置错误
   ↓
中间件层 → Kafka/MySQL 等的 Buffer 配置是否合理
   ↓
TCP 层 → 拥塞窗口、接收窗口、重传情况
   ↓
内核层 → tcp_early_retrans 等内核参数
   ↓
网络层 → 带宽、丢包、RTT

从上到下逐层排查，每一层都可能是瓶颈。

网络知识学习方法与技巧

一、学习路径：从理论到实战

1. 系统化学习框架

plantegg 博客提供了三大核心系列，构建完整的网络知识体系：

• Understanding TCP 系列 - TCP 协议全方位解析
• Understanding Network 系列 - 网络基础概念深入
• Understanding Load Balancing 系列 - 负载均衡策略与实践

学习建议：不要孤立学习理论，而是将理论与生产案例结合。plantegg 的内容强调从实际问题出发，通过案例理解原理。

2. 问题驱动的学习方法

plantegg 博客的核心特点是问题导向：

• 从生产环境的真实故障入手
• 通过排查过程学习工具使用
• 在解决问题中理解底层原理
• 积累可复用的诊断方法论

实践路径：

1. 遇到问题 → 2. 抓包分析 → 3. 定位根因 → 4. 理解原理 → 5. 总结方法

二、核心知识领域

1. TCP 连接管理

连接队列监控

理解 TCP 连接的两个关键队列：

• SYN 队列（半连接队列）：存储 SYN_RECV 状态的连接
• Accept 队列（全连接队列）：存储 ESTABLISHED 但未被 accept() 的连接

实时监控工具：

1
2

# 使用 bpftrace 工具包中的 tcpaccept
tcpaccept

输出示例解读：

• PID/COMM：接受连接的进程信息
• RADDR/RPORT：远程地址和端口
• LADDR/LPORT：本地地址和端口
• Accept Queue：当前队列大小/最大队列大小

关键洞察：

• 队列满时会导致连接被丢弃（SYN 丢弃或 ACK 丢弃）
• 通过监控队列状态可以提前发现性能瓶颈
• 队列大小受 somaxconn 和应用层 backlog 参数影响

Socket 选项优化

SO_REUSEPORT - 多进程负载均衡：

1
2
3
4

int listenfd;
int reuse = 1;
setsockopt(listenfd, SOL_SOCKET, SO_REUSEPORT, 
           (const void *)&reuse, sizeof(int));

核心价值：

• 允许多个进程绑定同一 IP:Port
• 内核通过哈希分发连接，实现负载均衡
• 解决”惊群效应”（thundering herd）
• 提升多核 CPU 利用率

适用场景：

• Nginx 多 worker 进程同时监听
• 高并发服务器提升连接接收能力
• 避免单一监听 socket 成为瓶颈

SO_REUSEADDR vs SO_REUSEPORT：

• SO_REUSEADDR：允许 TIME_WAIT 状态下快速重启服务
• SO_REUSEPORT：多进程负载均衡，性能优化

2. Buffer 与内存管理

Socket 内存信息解读

使用 ss -m 查看 socket 内存状态：

1

ss -m

输出字段含义：

• r：接收缓冲区已分配内存
• rb：接收缓冲区大小（sk_rcvbuf）
• t：发送缓冲区已分配内存
• tb：发送缓冲区大小（sk_sndbuf）
• f：forward allocation（预分配内存）
• w：发送队列中的数据
• o：选项内存（如 TCP options）
• bl：backlog 队列长度
• d：丢弃的包数量

内核实现（参考）：

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

void sk_get_meminfo(const struct sock *sk, u32 *mem)
{
    mem[SK_MEMINFO_RMEM_ALLOC] = sk_rmem_alloc_get(sk);
    mem[SK_MEMINFO_RCVBUF] = sk->sk_rcvbuf;
    mem[SK_MEMINFO_WMEM_ALLOC] = sk_wmem_alloc_get(sk);
    mem[SK_MEMINFO_SNDBUF] = sk->sk_sndbuf;
    mem[SK_MEMINFO_FWD_ALLOC] = sk->sk_forward_alloc;
    mem[SK_MEMINFO_WMEM_QUEUED] = sk->sk_wmem_queued;
    mem[SK_MEMINFO_OPTMEM] = atomic_read(&sk->sk_omem_alloc);
    mem[SK_MEMINFO_BACKLOG] = sk->sk_backlog.len;
    mem[SK_MEMINFO_DROPS] = atomic_read(&sk->sk_drops);
}

诊断技巧：

• r 接近 rb：接收缓冲区快满，应用层消费慢
• t 接近 tb：发送缓冲区快满，网络发送慢或对端接收慢
• d 持续增长：socket 丢包，需检查缓冲区大小和应用处理速度
• bl 持续非零：backlog 队列有积压，应用 accept() 速度慢

内核参数调优

关键参数：

1
2
3
4
5

# 查看网络软中断预算
sysctl -a | grep net.core.netdev_budget

# 临时调整（重启失效）
sysctl -w net.core.netdev_budget=400

常见调优参数：

• net.core.netdev_budget：单次软中断处理的最大包数
• net.core.somaxconn：listen() 的最大 backlog
• net.ipv4.tcp_rmem：TCP 接收缓冲区（min/default/max）
• net.ipv4.tcp_wmem：TCP 发送缓冲区（min/default/max）
• net.ipv4.tcp_max_syn_backlog：SYN 队列最大长度

调优原则：

• 先监控，后调优（避免盲目调整）
• 理解参数含义和影响范围
• 在测试环境验证效果
• 记录调优前后的性能指标

3. TCP 性能指标

关键性能指标

RTT（Round-Trip Time）：

• 衡量网络延迟的核心指标
• 影响 TCP 吞吐量：Throughput ≈ Window Size / RTT
• 通过 tcp.analysis.ack_rtt 字段分析

重传率：

• 反映网络质量和拥塞情况
• 类型：超时重传、快速重传
• 高重传率可能原因：网络丢包、接收端处理慢、拥塞

窗口大小：

• 接收窗口（rwnd）：接收端通告的可用缓冲区
• 拥塞窗口（cwnd）：发送端的拥塞控制窗口
• 实际窗口 = min(rwnd, cwnd)

丢包与重传分析：

• tcp.analysis.retransmission：重传包
• tcp.analysis.fast_retransmission：快速重传
• tcp.analysis.duplicate_ack：重复 ACK
• tcp.analysis.lost_segment：丢失的段

TCP 选项优化

TCP_CORK：

1
2
3

当设置 TCP_CORK 时，会将非满帧排队，直到清除该选项。
适用场景：先发送 HTTP 头部，再用 sendfile() 发送数据体。
TCP_CORK 可与 TCP_NODELAY 同时设置，且优先级更高。

应用场景：

• 减少小包发送，提升网络效率
• 适合批量数据传输
• 与 sendfile() 配合使用

4. 负载均衡与高可用

SO_REUSEPORT 实现负载均衡

工作原理：

• 内核通过哈希算法分发连接到不同进程
• 每个进程独立 listen() 和 accept()
• 避免进程间锁竞争

性能提升：

• 多核 CPU 并行处理连接
• 消除单一监听 socket 瓶颈
• 提升高并发场景下的吞吐量

Nginx 配置示例：

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

worker_processes 4;
worker_cpu_affinity 00000000000000000000000000001111;

events {
    use epoll;
    accept_mutex off;  # 关闭 accept 互斥锁
    worker_connections 102400;
}

http {
    access_log off;
    sendfile on;
    sendfile_max_chunk 512k;
    tcp_nopush on;
    keepalive_timeout 60;
    keepalive_requests 100000000000;
    
    # 短连接 RPS 优化
    open_file_cache max=10240000 inactive=60s;
    open_file_cache_valid 80s;
    open_file_cache_min_uses 1;
}

优化要点：

• accept_mutex off：配合 SO_REUSEPORT 使用
• sendfile：零拷贝技术，减少 CPU 消耗
• tcp_nopush：与 TCP_CORK 类似，批量发送
• open_file_cache：缓存文件描述符，提升短连接性能

三、实战诊断方法论

1. 性能问题排查流程

第一步：确定问题现象

• 延迟高？吞吐量低？连接失败？
• 收集监控数据：CPU、内存、网络流量、连接数

第二步：抓包分析

• 使用 tcpdump 捕获流量
• 用 tshark/Wireshark 分析关键指标

第三步：定位瓶颈

• 网络层：RTT、丢包率、重传率
• 传输层：窗口大小、队列状态
• 应用层：响应时间、处理速度

第四步：验证假设

• 调整参数或代码
• 对比调整前后的性能数据
• 确认问题是否解决

2. 常见问题模式

模式 1：高延迟

可能原因：

• 网络 RTT 高（物理距离、路由跳数）
• 应用层处理慢（数据库查询、计算密集）
• 队列积压（accept 队列、backlog 队列）

诊断方法：

• 分析 tcp.analysis.ack_rtt 确定网络延迟
• 分析应用层响应时间（如 MySQL query time）
• 检查队列状态（tcpaccept、ss -l）

模式 2：高重传率

可能原因：

• 网络丢包（链路质量差、拥塞）
• 接收端处理慢（窗口满、应用消费慢）
• 发送端突发流量（超过网络容量）

诊断方法：

• 统计重传类型（超时 vs 快速重传）
• 检查窗口大小变化
• 分析丢包位置（发送端、中间网络、接收端）

模式 3：连接失败

可能原因：

• SYN 队列满（半连接队列溢出）
• Accept 队列满（全连接队列溢出）
• 防火墙/安全组规则
• 端口耗尽

诊断方法：

• 检查 netstat -s | grep -i listen
• 监控队列状态（tcpaccept）
• 检查可用端口范围

3. 分层诊断策略

应用层：

• 响应时间分布（P50/P95/P99）
• 慢查询分析
• 业务逻辑性能

传输层（TCP）：

• 连接建立时间
• 数据传输效率
• 连接关闭状态（TIME_WAIT 数量）

网络层（IP）：

• 路由路径
• MTU 设置
• 分片情况

链路层：

• 网卡队列
• 软中断分布
• 丢包统计

四、工具链与技能树

1. 必备工具

抓包与分析：

• tcpdump：流量捕获
• tshark：命令行分析
• Wireshark：图形化深度分析

连接监控：

• ss：socket 统计（替代 netstat）
• tcpaccept：连接队列监控（bpftrace）
• netstat：传统网络统计

性能分析：

• perf：CPU 性能分析
• sar：系统活动报告
• iftop：实时流量监控

内核调试：

• sysctl：内核参数查看/设置
• bpftrace/eBPF：内核动态追踪
• SystemTap：内核探测

2. 技能进阶路径

初级（理解基础）：

• TCP 三次握手、四次挥手
• 常见状态（ESTABLISHED、TIME_WAIT、CLOSE_WAIT）
• 基本抓包和过滤

中级（诊断问题）：

• 重传、丢包、窗口分析
• 内核参数调优
• 应用层协议解析（HTTP、MySQL）

高级（性能优化）：

• 拥塞控制算法
• 零拷贝技术（sendfile、splice）
• 内核网络栈优化
• eBPF 自定义追踪

专家级（架构设计）：

• 高性能网络架构设计
• 负载均衡策略
• 容错与降级方案
• 大规模分布式系统网络优化

五、学习资源与实践建议

1. plantegg 博客特色

理论与实践结合：

• 每个概念都有生产案例支撑
• 提供完整的命令和代码示例
• 强调可复现的实验方法

问题驱动：

• 从真实故障出发
• 展示完整的排查过程
• 总结可复用的方法论

工具导向：

• 详细的工具使用指南
• 参数含义和适用场景
• 输出结果的解读方法

2. 实践建议

搭建实验环境：

• 使用虚拟机或容器模拟网络场景
• 用 tc（traffic control）模拟延迟、丢包
• 搭建简单的客户端-服务器程序

动手实验：

• 复现博客中的案例
• 修改参数观察效果
• 记录实验结果和心得

建立知识库：

• 整理常用命令和参数
• 记录典型问题的排查步骤
• 积累自己的案例库

持续学习：

• 关注内核版本更新（新特性、新参数）
• 学习新工具（eBPF、XDP）
• 阅读内核源码（理解实现细节）

3. 避免的误区

误区 1：只学理论不实践

• 网络知识必须通过实验验证
• 理论与实际环境可能有差异

误区 2：盲目调优参数

• 先理解参数含义和影响
• 在测试环境验证效果
• 记录调优前后的对比数据

误区 3：忽视应用层

• 很多”网络问题”实际是应用层问题
• 要结合应用日志和业务逻辑分析

误区 4：过度依赖工具

• 工具是手段，理解原理才是目的
• 学会从工具输出推导底层行为

六、总结

plantegg 博客的核心价值在于：

1. 系统化：完整的知识体系，从基础到高级
2. 实战化：真实案例，可复现的实验
3. 工具化：详细的工具使用指南
4. 方法论：可复用的问题排查流程

学习网络知识的最佳路径：

• 理论学习 → 动手实验 → 问题排查 → 性能优化 → 架构设计

持续提升的关键：

• 保持好奇心，深入理解原理
• 多动手实践，积累经验
• 建立自己的知识体系和工具链
• 关注技术演进，学习新技术

文档生成时间：2026-01-18
来源：plantegg.github.io (Context7 库)
适用对象：系统工程师、SRE、后端开发、网络工程师

MySQL PreparedStatement Performance Issue Reproduction Report

1. Executive Summary

1.1 Issue Description

A severe performance issue was reported when MySQL processes PreparedStatement IN queries with a large number of parameters (50,000) using useServerPrepStmts=true. According to the original report, server-side prepared statements were 190-207 times slower than client-side prepared statements.

1.2 Issue Source

• GitHub Repository: https://github.com/plantegg/MySQLPrepared
• Original Discovery Version: MySQL 5.7.29
• JDBC Driver: mysql-connector-j-8.0.33

1.3 Root Cause (Original Report)

When MySQL server processes PreparedStatement with large number of parameters:

1. Excessive memory reallocation: 50,000 parameter replacement operations
2. String operation complexity: O(SQL length) × number of parameters
3. Memory fragmentation: Frequent large memory block allocation and deallocation

2. Test Environment

2.1 AWS Resource Information

2.2 RDS MySQL 8.0 Instance

2.3 RDS MySQL 5.7 Instance

2.4 EC2 Test Client

3. Test Methodology

3.1 Test Code

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 Test Parameters

3.3 AWS CLI Commands

Create RDS MySQL 8.0 Instance

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 '<password>' \
    --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

Create RDS MySQL 5.7 Instance

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 '<password>' \
    --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

Create EC2 Test Instance

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. Test Results

4.1 MySQL 8.0.43 Test Results

Compact Format (spaces=0, SQL length ~100KB)

With Spaces Format (spaces=128, SQL length ~6.5MB)

4.2 MySQL 5.7.44 Test Results

With Spaces Format (spaces=128, SQL length ~6.5MB)

4.3 Comparison with Original Report

5. Conclusions

5.1 Reproduction Results

The performance issue described in the original report could NOT be reproduced on MySQL 5.7.44 and 8.0.43.

Test results show:

• On both versions, useServerPrepStmts=true is actually faster than false
• MySQL 5.7.44: Server-side prepared statements are 6.7x faster
• MySQL 8.0.43: Server-side prepared statements are 4.0x faster

5.2 Possible Explanations

1. MySQL Version Differences

   • Original issue was discovered on MySQL 5.7.29
   • This test used MySQL 5.7.44 and 8.0.43
   • The issue may have been fixed in versions after 5.7.29

2. AWS RDS Optimizations

   • AWS RDS may include specific performance optimizations
   • Behavior may differ from native MySQL installations

3. JDBC Driver Version

   • Test used mysql-connector-j-8.0.33
   • Driver may have optimized parameter handling logic

5.3 Recommendations

1. To Reproduce the Original Issue

   • Use MySQL 5.7.29 or earlier versions
   • Use native MySQL instead of AWS RDS

2. Production Environment Recommendations

   • On newer MySQL versions, useServerPrepStmts=true performs better
   • Conduct performance testing with actual business scenarios
   • For IN queries with large parameter counts, consider batch queries or temporary table approaches

6. Appendix

6.1 Test Logs

MySQL 8.0.43 Complete Output

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 Performance Comparison Test ===
Connection: mysql-prepared-test.cfsoq6muu0jv.ap-southeast-1.rds.amazonaws.com:3306/test
Parameter count: 50000
Test rounds: 3

Configuration: useServerPrepStmts=false
Parameter spaces: 128
SQL length: 6500023 characters
Executing query 1...
Query 1: 571ms (0 records returned)
Executing query 2...
Query 2: 317ms (0 records returned)
Executing query 3...
Query 3: 314ms (0 records returned)

=== useServerPrepStmts=false Test Results ===
Total execution time: 1202ms
Average execution time: 400.7ms
Records returned: 0
Com_stmt_prepare: 0 -> 0

Configuration: useServerPrepStmts=true
Parameter spaces: 128
SQL length: 6500023 characters
Executing query 1...
Query 1: 138ms (0 records returned)
Executing query 2...
Query 2: 92ms (0 records returned)
Executing query 3...
Query 3: 73ms (0 records returned)

=== useServerPrepStmts=true Test Results ===
Total execution time: 303ms
Average execution time: 101.0ms
Records returned: 0
Com_stmt_prepare: 0 -> 1

MySQL 5.7.44 Complete Output

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 Performance Comparison Test ===
Connection: mysql57-prepared-test.cfsoq6muu0jv.ap-southeast-1.rds.amazonaws.com:3306/test
Parameter count: 50000
Test rounds: 3

Configuration: useServerPrepStmts=false
Parameter spaces: 128
SQL length: 6500023 characters
Executing query 1...
Query 1: 639ms (0 records returned)
Executing query 2...
Query 2: 681ms (0 records returned)
Executing query 3...
Query 3: 480ms (0 records returned)

=== useServerPrepStmts=false Test Results ===
Total execution time: 1800ms
Average execution time: 600.0ms
Records returned: 0
Com_stmt_prepare: 0 -> 0

Configuration: useServerPrepStmts=true
Parameter spaces: 128
SQL length: 6500023 characters
Executing query 1...
Query 1: 117ms (0 records returned)
Executing query 2...
Query 2: 77ms (0 records returned)
Executing query 3...
Query 3: 76ms (0 records returned)

=== useServerPrepStmts=true Test Results ===
Total execution time: 270ms
Average execution time: 90.0ms
Records returned: 0
Com_stmt_prepare: 0 -> 1

6.2 Original Issue Stack Trace (from original report)

The original report included a pstack analysis showing the server spending excessive time in string replacement operations:

1
2
3
4
5
6
7
8
9
10
11

Thread 1 (Thread 0x7feeb8043640 (LWP 2508284)):
#0 __memmove_avx512_unaligned_erms () from /lib64/libc.so.6
#1 my_realloc () at mysys/my_malloc.c:112
#2 String::mem_realloc () at sql-common/sql_string.cc:128
#3 String::replace () at sql-common/sql_string.cc:804
#4 String::replace () at sql-common/sql_string.cc:783
#5 Prepared_statement::insert_params () at sql/sql_prepare.cc:924
#6 Prepared_statement::set_parameters () at sql/sql_prepare.cc:3496
#7 Prepared_statement::execute_loop () at sql/sql_prepare.cc:3559
#8 mysqld_stmt_execute () at sql/sql_prepare.cc:2582
...

This stack trace indicates the server was performing extensive memory reallocation and string manipulation operations during parameter substitution.

6.3 References

• MySQL PreparedStatement Performance Issue Reproduction Project
• MySQL Connector/J Documentation
• MySQL Bug Database

7. Submission Notes for MySQL Community

7.1 Summary for Bug Report

Title: Performance regression with useServerPrepStmts=true for large IN queries appears to be fixed in MySQL 5.7.44+

Description:
A previously reported performance issue where server-side prepared statements (useServerPrepStmts=true) were significantly slower than client-side prepared statements for IN queries with 50,000 parameters could not be reproduced on MySQL 5.7.44 and 8.0.43.

Original Behavior (MySQL 5.7.29):

• useServerPrepStmts=true: ~27,839ms average
• useServerPrepStmts=false: ~52ms average
• Performance difference: 535x slower with server-side

Current Behavior (MySQL 5.7.44 / 8.0.43):

• useServerPrepStmts=true: ~90-101ms average
• useServerPrepStmts=false: ~400-600ms average
• Performance difference: 4-6.7x faster with server-side

Request:
Could the MySQL team confirm if this issue was intentionally fixed in a specific version? If so, please document the fix in the release notes for user awareness.

Report Generated: 2026-01-12
Test Executor: Kiro CLI
AWS Account: 872515255872

MySQL Sysbench 性能测试综合报告

测试代码开源：https://github.com/plantegg/sysbench_report ，包含自动生成下面的测试报告，对每个测试场景自动列出压测当时的 CPU/磁盘负载

📊 执行摘要

本报告汇总了10 多个不同环境下的MySQL性能测试结果，涵盖了IDC自建机房、华为云/阿里云ECS/AWS EC2，自建 MySQL(非云实例)。测试使用sysbench工具进行标准化性能评估，包含点查询、只读、读写混合、只写四种典型业务场景。

点评

• 测试场景故意用 16*1000 万行50G 数据，MySQL 配置 16Gbuffer，考验磁盘性能
• 警惕 AWS 云盘，即使换成很贵的 io1/io2 云盘，性能较其他家有很大的差距，尤其是在没有压力的时延上是阿里云的 5 倍，是 IDC 的 10 倍，
• 相对来说 aliyun 的表现很优秀，云盘有很大的 iops 弹性，可以买更便宜的，关键时刻享受自动弹性
• 不管怎么样，云盘还是非常昂贵，一个实例上云盘的价格会是机器的一半到一倍
• CPU 计算性能大差不差，其中 aliyun 买的是今年最新一代，占点优势

测试环境概览

说明：

1. trx1 表示innodb_flush_log_at_trx_commit 为 1；默认配置的 2；表示刷盘频率
2. gp3/io1/io2 表示 aws 的三款不同性能的云盘(io2 最好最贵)(2T 云盘的价格是 8C32G 机器的 8 倍)
3. trx1.repl 的 repl 表示开启半同步复制，看看网络 replication 带来的时延
4. ali.repl.rtt0.7 的 repl 表示开启半同步复制，rtt0.7ms 表示网络延时，模拟跨可用区
5. idc 表示在我们自己的机房搭建 MySQL(测试默认不含主从复制，repl 除外)
6. 云厂商都是购买 ECS 搭建 MySQL
7. 超过 8 核的机器，通过绑核的形式限制只能用 8 核

测试配置

• 测试工具: sysbench + tsar
• 测试数据集: 16表 × 1000万行
• 测试时长: 每场景30秒
• 测试场景: 点查询、只读、读写混合、只写
• 并发级别: 1, 8, 16, 32, 64, 128 线程

🏆 性能排名

点查询性能对比 (oltp_point_select)

只写性能对比 (oltp_write_only)

读写混合性能对比 (oltp_read_write)

只读性能对比 (oltp_read_only)

📈 延迟分析

点查询延迟对比 (95%分位, ms)

读写混合延迟对比 (95%分位, ms)

只写延迟对比 (95%分位, ms)

💡 关键发现

性能特点

1. CPU架构影响

   • 不同CPU架构在各场景下表现差异明显
   • 单核性能对点查询场景影响显著

2. 事务持久化设置

   • innodb_flush_log_at_trx_commit=1 vs 2 对写入性能影响明显
   • 建议根据业务对数据安全性要求选择合适配置

3. 并发扩展性

   • 各环境在不同并发级别下的扩展性表现不同
   • 需要根据实际业务并发选择合适的硬件配置

4. 延迟控制

   • 高并发下延迟控制能力体现系统稳定性
   • 95%分位延迟是衡量用户体验的重要指标

环境推荐

• 查询密集型业务: 推荐 aliyun.trx1 环境
• 写入密集型业务: 推荐 aliyun 环境
• 混合负载: 需要综合考虑QPS、延迟和成本

📊 64线程性能对比

第一章：idc 环境详细报告

测试时间: 2025-11-27 10:28:39
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 51706 条记录

测试配置信息

1
2
3
4
5
6
7

=== 测试配置信息 ===
MYSQL_HOST: 10.9.10.145
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

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

=== CPU 信息 ===
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    12
座：                 2
NUMA 节点：         2
厂商 ID：           GenuineIntel
CPU 系列：          6
型号：              143
型号名称：        INTEL(R) XEON(R) SILVER 4510
步进：              8
CPU MHz：             2400.000
BogoMIPS：            4800.00
虚拟化：           VT-x
L1d 缓存：          48K
L1i 缓存：          32K
L2 缓存：           2048K
L3 缓存：           30720K
NUMA 节点0 CPU：    0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
NUMA 节点1 CPU：    1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cat_l2 cdp_l3 invpcid_single intel_pt cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq cldemote movdiri movdir64b md_clear pconfig spec_ctrl intel_stibp flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           376G         47G        257G        1.7G         71G        326G
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

第二章：idc.trx1 环境详细报告

测试时间: 2025-11-27 10:29:01
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 50627 条记录

测试配置信息

1
2
3
4
5
6
7

=== 测试配置信息 ===
MYSQL_HOST: 10.9.10.145
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	1

压测服务器配置

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

=== CPU 信息 ===
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    12
座：                 2
NUMA 节点：         2
厂商 ID：           GenuineIntel
CPU 系列：          6
型号：              143
型号名称：        INTEL(R) XEON(R) SILVER 4510
步进：              8
CPU MHz：             2400.000
BogoMIPS：            4800.00
虚拟化：           VT-x
L1d 缓存：          48K
L1i 缓存：          32K
L2 缓存：           2048K
L3 缓存：           30720K
NUMA 节点0 CPU：    0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
NUMA 节点1 CPU：    1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cat_l2 cdp_l3 invpcid_single intel_pt cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq cldemote movdiri movdir64b md_clear pconfig spec_ctrl intel_stibp flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           376G         47G        257G        1.7G         71G        326G
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

第三章：huawei 环境详细报告

测试时间: 2025-11-27 10:29:08
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 60059 条记录

测试配置信息

1
2
3
4
5
6
7

=== 测试配置信息 ===
MYSQL_HOST: 10.16.104.124
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

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

=== CPU 信息 ===
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                64
On-line CPU(s) list:   0-63
Thread(s) per core:    2
Core(s) per socket:    16
座：                 2
NUMA 节点：         2
厂商 ID：           GenuineIntel
CPU 系列：          6
型号：              106
型号名称：        Intel(R) Xeon(R) Gold 6348 CPU @ 2.60GHz
步进：              6
CPU MHz：             2600.000
BogoMIPS：            5200.00
超管理器厂商：  KVM
虚拟化类型：     完全
L1d 缓存：          48K
L1i 缓存：          32K
L2 缓存：           1280K
L3 缓存：           43008K
NUMA 节点0 CPU：    0-31
NUMA 节点1 CPU：    32-63
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd rsb_ctxsw ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 arat avx512vbmi umip avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq md_clear spec_ctrl intel_stibp arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           251G         21G        127G        944K        102G        229G
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

第四章：aliyun 环境详细报告

测试时间: 2025-11-27 10:28:27
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 811 条记录

测试配置信息

1
2
3
4
5
6
7

=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

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

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Alibaba Cloud
CPU 系列：       6
型号：           173
型号名称：       Intel(R) Xeon(R) 6982P-C
BIOS Model name: pc-i440fx-2.1
步进：           1
CPU MHz：        3600.000
CPU 最大 MHz：   3900.0000
CPU 最小 MHz：   800.0000
BogoMIPS：       5600.00
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       64K
L2 缓存：        2048K
L3 缓存：        516096K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm uintr md_clear serialize tsxldtrk arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        20Gi       1.2Gi       2.0Mi       9.1Gi       9.6Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

第五章：aliyun.trx1 环境详细报告

测试时间: 2025-11-27 10:27:05
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 791 条记录

测试配置信息

1
2
3
4
5
6
7

=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	1

压测服务器配置

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

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Alibaba Cloud
CPU 系列：       6
型号：           173
型号名称：       Intel(R) Xeon(R) 6982P-C
BIOS Model name: pc-i440fx-2.1
步进：           1
CPU MHz：        3600.000
CPU 最大 MHz：   3900.0000
CPU 最小 MHz：   800.0000
BogoMIPS：       5600.00
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       64K
L2 缓存：        2048K
L3 缓存：        516096K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm uintr md_clear serialize tsxldtrk arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        20Gi       1.2Gi       2.0Mi       9.1Gi       9.6Gi
Swap:            0B          0B          0B