拿去问了 GPT-4-0612
得到的回答：

Flink 支持多表 join 的查询结果同步到新的一张表里。你可以使用 Flink SQL 或者 DataStream API 来实现这个需求。

以下是一个使用 Flink SQL 实现的例子：

```java
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);

// 注册 a, b, c 三个表
tableEnv.registerTableSource("a", ...);
tableEnv.registerTableSource("b", ...);
tableEnv.registerTableSource("c", ...);

// 执行 join 操作并将结果插入到新的表
tableEnv.sqlUpdate(
"INSERT INTO new_table " +
"SELECT * " +
"FROM a " +
"JOIN b ON a.order_id = b.order_id " +
"JOIN c ON a.order_id = c.order_id"
);

env.execute();
```

这个例子中，我们首先创建了一个 `StreamExecutionEnvironment` 和一个 `StreamTableEnvironment`。然后，我们注册了 a, b, c 三个表。接着，我们执行了一个 join 操作，并将结果插入到新的表中。

需要注意的是，这个例子中的 join 操作是基于事件时间的，并且假设 a, b, c 三个表中的数据都是按照订单号排序的。如果实际情况不是这样，你可能需要使用其他类型的 join 操作，例如 interval join 或者 window join 。

另外，你提到了使用 ES 来加速查询。这确实是一个可行的方案。你可以使用 Flink 的 Elasticsearch connector 将数据写入到 ES 中。然后，你可以使用 ES 的强大的搜索和分析功能来加速查询。

最后，关于优化查询性能，还有一些其他的方案可以考虑：

1. 对关联字段建立索引：如果 abc 三个表都是根据订单号关联的，那么可以考虑对订单号字段建立索引。这样可以大大提高 join 查询的性能。

2. 分区和分桶：如果 abc 三个表的数据量非常大，那么可以考虑对表进行分区和分桶。这样可以将大表切分成多个小表，从而提高查询性能。

3. 使用更快的存储引擎：如果你正在使用 MySQL ，那么可以考虑切换到更快的存储引擎，例如 InnoDB 或者 MyRocks 。

4. 使用列式存储：如果你的查询主要是聚合操作，那么可以考虑使用列式存储，例如 Apache Parquet 或者 ORC 。列式存储可以大大提高聚合查询的性能。

5. 使用缓存：如果你的查询主要是点查操作，那么可以考虑使用缓存，例如 Redis 或者 Memcached 。缓存可以大大提高点查查询的性能。

我以前也用一加
自从几年前被曝光在氧 OS 里发现了检测剪贴板是否包含敏感词，检测到就会自动上传剪贴板数据之后
然后官方的解释还是“反而是系统识别出这些文件，是为了过滤掉这部分些数据不上传”
那问题反而更严重了……
之后我就不用了

有没有办法在中国也用上

今天可能够用，明天不一定够

其实支持 27W PD 也够用了，至少这个论坛里几乎所有的 iPhone 用户都觉得 12W / 18W / 22W 够用。
线材和充电头是私有的也无所谓，关键在于使用标准 PD 充电器+标准 C to C 充电线的功率是多少。

我用的私有协议也不过是 33W （或者标更高功率，实际充电时间相当于 33W ）。

我自己测的：
2019 年买了个 OPPO ，5W 。当时跟一位一加用户说了这个事情，他说他不关心，反正官方的头+线充电很快。
去年买的红米，27W 。

每天都在用，自己整理了特定需求的 prompt ，和通用 prompt 不一样，有很多背景信息和专有名词解释，以及模板代码。

然后只需要输入几个字就可以生成各种东西。

我每天都在用右 Alt 和右 Ctrl
前者用来在微信里换行
后者用来在 QQ 里发送消息

对于这种问题我有两种办法：
1. 用 MIUI 的声音助手打开“允许多声音”
2. 用可以设置音频焦点级别的播放器，更改到 1 级，只有通话才能暂停它播放

@littiefish 其实传感器可以禁……
https://i.imgur.com/xOoMCkJ.png

iOS 的话确实不能

@Eagleyes
区别：安装路径不一样，而且被 homebrew 管理，如果原本没有 homebrew ，也用不着 homebrew 的话，其实还额外浪费了一点硬盘空间
优势：安装步骤少……没了

@1commonlangford 是这样，但我没有试过

刚才吃饭的时候突然想起一篇楼主找遍各种电脑（应该包括云服务）都觉得内存不够用的帖子……

是这篇：
https://www.reddit.com/r/LocalLLaMA/comments/14sdskp/my_largest_ever_quants_gpt_3_sized_bloomz_176b/

有个叫 TheBloke 的网友一直在做各种大型语言模型的量化，然后发到 huggingface 上给大家用。
其实很多人的电脑能跑得起量化后的模型，但是量化过程所需要的硬盘和内存却负担不起。

他花了一个月的时间，尝试了各种硬件，要么内存不够用，要么 CPU 太慢耗时太长。始终没办法量化最大规格的 BLOOM 模型。

直到有人借给他搭载 750GB 内存的 AMD EPYC 9354 服务器，终于能做到了。

1. 安装 Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. 安装 adb
brew install android-platform-tools

我最近在玩 LLaMa 2 模型

偶尔会做格式转换或者量化。很多项目的代码写得不好，加载 70B 的模型就要 140GB 内存，程序只有加载全部权重之后才会开始操作。
量化/转换完毕才开始保存，这样内存使用量轻轻松松达到 200GB 甚至 300GB 以上……因为内存里同时装着操作之前和操作之后的模型。
然而我的电脑只有 128GB 内存，感觉不太够用。

https://i.imgur.com/oYn49tA.png

96GB 更不够用了……

上面的链接给出的例子还是比较复杂，那是并行更新进度的例子