京公网安备11010502063487号用 EXPLAIN AST / EXPLAIN PLAN / EXPLAIN PIPELINE 加 system.query_log，真实拆开同一条 SQL 从解析、生成执行计划、拼成处理器流水线到真正执行的每一步。
在本机 2000 万行的真实表上，把 max_block_size 从 1 调到默认的 65505，同一条聚合查询真实耗时从 32.8 秒降到 0.09 秒，361 倍的差距全部来自一行一行处理还是一批一批处理。
用 EXPLAIN PIPELINE 加真实改 max_threads，看同一条聚合查询的处理器流水线真实是怎么随线程数从1条变成8条并行分支的，以及并行分支多了之后耗时的真实变化。
用 clickhouse-client 的 Native 格式真实导出一份原始字节流，逐字节解码出 ClickHouse 内部真正传递的最小单位——Block：一份列名、一份类型、然后每一列的值各自连续排列在一起。
真实往 MergeTree、ReplacingMergeTree、SummingMergeTree 里写入同样的重复数据，对比 OPTIMIZE FINAL 前后的真实结果，再验证 SELECT ... FINAL 和物理合并的真实区别。
真实建一张30万行、按月分区、按region+uid排序的表，用三种不同的WHERE条件真实对比read_rows，看ORDER BY前缀过滤、非索引列过滤、分区裁剪这三种情况真实读了多少数据。
真实建两张200万行的表，一张用默认的index_granularity=8192，一张调到128，用真实的marks_bytes和point query的read_rows，看稀疏索引到底稀疏在哪、代价换来了什么。
真实执行一次INSERT，直接ls磁盘上生成的part目录，逐个文件看清楚checksums.txt、columns.txt、count.txt都装了什么，再对比Compact和Wide两种part格式真实的文件差异。
本机真实起一个 MySQL 26.7 单节点，用 EXPLAIN FORMAT=TREE 真实验证二级索引的叶子节点里存的到底是什么——查主键列不用回表，查其它列才需要回表。
本机真实建一张10万行的表，联合索引idx(a,b,c)，用EXPLAIN真实对比只过滤b、只过滤a、过滤a+b、过滤a+b+c这四种情况，看索引真实是怎么按前缀一段段生效的。
本机真实用EXPLAIN ANALYZE对比约2万行范围查询在覆盖索引和非覆盖索引下的真实耗时，2ms vs 11毫秒级，看回表这一步真实要多付出多少代价。
本机真实建一张20万行、95%对5%严重倾斜的表，真实对比强制走索引和强制全表扫描的耗时，意外发现MySQL优化器的默认选择对低选择性列反而选错了。