京公网安备11010502063487号kill掉一个同时兼任controller leader和数据分区leader的broker，测量三种操作(受影响分区/无关分区/创建新topic)真实的端到端恢复耗时，都约11秒，对应broker.session.timeout.ms默认9秒。
真实给3节点集群加入第4个broker，验证已有topic完全不受影响，只有新建topic才会用到它；再kill掉它，验证Replicas列表不会自动清理死亡broker id。
用kafka-reassign-partitions.sh把卡着死亡broker的分区真实迁移到健康broker上，--execute和--verify两步真实完成ISR从残缺恢复到健康。
验证broker故障恢复后leader不会自动切回preferred副本，用kafka-leader-election.sh一条命令真实修正了集群里累积的8个分区不均衡。
持续写入30万条消息制造压力，用kafka-log-dirs.sh验证leader和两个follower磁盘字节数真实完全同步，offsetLag始终为0。
对运行中的broker做jcmd线程转储，真实数出每个监听端口3个网络线程(对应num.network.threads=3)和共享的8线程请求处理池(对应num.io.threads=8)。
真实验证os.sendfile()要求目标必须是socket，用500MB数据对比sendfile和read+send两种方式，真实测得sendfile快1.29倍。
用producer-perf-test真实测batch.size=1到默认值带来51倍吞吐提升，而acks=1相对acks=all在同样批量下只快5%，揭示批量大小才是主要瓶颈。
用同样稀疏的消息到达节奏对比linger.ms=0和20，网络请求数真实从1973降到246，总耗时几乎不变，验证linger.ms近乎免费的批量收益。
用同一份重复性日志真实对比5种压缩方式的磁盘占用和吞吐量，gzip压缩率最高但较慢，zstd在压缩率和速度之间取得最好平衡。
本机用一个5万行GROUP BY的CTE验证：只引用一次时，WHERE条件被下推进CTE内部，GROUP BY退化成单个分组，整条查询在优化阶段就被常量折叠成了字面量，耗时只要0.0001秒左右；同一个CTE被自连接引用两次，优化器改为把它物化成一张临时表，耗时变成0.074秒。
本机5万行数据上验证：不加ORDER BY只需要1次排序；本以为外层ORDER BY和窗口函数的PARTITION BY+ORDER BY写成完全一样就能省掉一次排序，真实测出来并没有——窗口结果必须先落进临时表，顺序丢失，外层还是要重新排一次。