Async Insert：异步写入如何合并小请求

做的事：同样100条单行INSERT，真实跑三种模式对比

代码-- 模式1：普通同步 INSERT INTO demo.asynctest VALUES (i, 'xi'); -- 模式2：async_insert=1 + wait_for_async_insert=1（等确认） INSERT INTO demo.asynctest2 SETTINGS async_insert=1, wait_for_async_insert=1 VALUES (i, 'xi'); -- 模式3：async_insert=1 + wait_for_async_insert=0（不等确认，fire-and-forget） INSERT INTO demo.asynctest3 SETTINGS async_insert=1, wait_for_async_insert=0 VALUES (i, 'xi');

验证：wait_for_async_insert=0真实快了约98倍

模式1（普通同步）           ：真实耗时 6.542 秒，结束后真实5个active part
模式2（async, wait=1）      ：真实耗时 6.599 秒，结束后真实5个active part  ← 真实没有变快
模式3（async, wait=0）      ：真实耗时 0.067 秒，结束后真实1个active part  ← 真实快约98倍
                              SELECT count() 真实确认100行全部写入成功

模式2（等待确认）真实几乎没有比同步模式快——因为每条INSERT语句发出后客户端依然要等服务端真实把这一批数据flush确认才返回，在本文这种单client顺序发送的场景下，服务端来不及把多条连续到达的请求真实攒到同一个缓冲区里就已经被要求flush了。真正体现出async_insert价值的是模式3：客户端把数据交给服务端的缓冲队列之后立刻返回，不等确认，服务端在后台按async_insert_busy_timeout_ms（默认200ms）这个时间窗口，把这个窗口内到达的所有INSERT请求真实合并成一次写入——本文100条请求全部落进了同一个200ms窗口，真实只产生了1个part，而不是100个。

async_insert真实解决的是什么问题

分步演示：三种模式，真实98倍的差距

每一步都是本文上面用真实计时跑出来的原始结果。