@sunmoon1983 你要多少秒内出结果呢？

@7911364440 比如，100W 数据里，只有 1 个城市户籍、1 个男性、1 个 2022 的，那算式是 1 - (100W - 1) - (100W - 1) ？还是咋算的？

@jones2000 我也感觉是，就算一行需要 1KB ，全部放进内存也才不到 1GB ，for 一百万次实际就连 Python 都不会很慢

如果只挑可能用到的字段出来，一百万行可能也只用到几十 MB 内存即可

@yasea @agui2200 能不能抽出可能用到的字段，建个小小的覆盖索引呢？

比如，（行政编码, 性别, 年份, 年龄, 项目 ID ），看起来一行只需 5+10+1+2+1+4+8 = 31 字节，100W 行索引只需 30 MB

如果不指定『当前地区』，扫全部索引也能满足各种查询需求。
如果指定了『当前地区』，可能只需扫几百上千行，几百 KB 的索引即可统计出来。

@sunmoon1983 你查询的 SQL 是怎么写的呢？

如果取值范围是 0 ~ 100 ，一个三维坐标可以映射到一个 0 ~ (101^3-1) 的整数，后面就是生成不重复的随机整数就好

如果换成 bitmap 存储，大概只需 16 KB 内存即可？

这种 `shs=(`find ./core* `)` 方式，文件名有空格就出错了。。

你可能想用的是 `removesuffix`

上一个犯过类似错误的帖子：/t/880251

@lslqtz 为啥不能应用于普通音频文件应用呢？

@jim9606 和 AAC 相比咋样？可以代替它用于一般音频上吗？（比如视频中的音频流、平时音乐 /人声存储啥的）

@msg7086 @Slurp 其实我觉得，即使是 32K 时，AAC he_v2 的质量也比 OPUS 高（但专门转码人声的话，确实 OPUS 强）

@lslqtz 不会吧。。难道现在各种视频、应用等，都用的 FLAC 吗？

@SbloodyS 那 8 楼的 SQL ，应该没有哪款数据库能运行了。因为：

```sql
SELECT ... LAG(start_date) ... AS start_date
...
```

@SbloodyS 是说，没法在 `... AS a` 内使用 `a`，是吧？

但可以 `... AS a, (a + 1) AS b`？

@SbloodyS 突然很好奇，如果 Clickhouse 支持直接用别名的话，下面这种 SQL 会计算成什么？

```sql
SELECT IF(id % 2, LEAD(a) OVER (...), LAG(a) OVER (...)) AS a
FROM ...
```

大意：若 id 为奇数，则取下一行的值，否则取上一行的值

@Gav1nw 新人问一下，问底层实现是啥意思？

要阅读 /调试 MySQL 源码才能掌握？还是八股文？

@ruidoBlanco @julyclyde `join` 和 `comm` 命令都要求 a.txt 和 b.txt 排好序了吧。。

如果俩文件都排好序了的话，反而没必要遍历 b.txt 了。如 @Tanix2 #16 所说，用二分查找更快

@8355 所以感觉 6 楼像一本正经的胡说八道。。


@RedisMasterNode 业务量大，一般至少会用 `bigint` 吧？`bigint` 不会这么容易用完吧。。

@8355 我主要是没理解，为何『自增不连续 ID 』会出现 @cloverzrg2 说的『`ORDER BY` 失效』、『查询麻烦』、『出现重复 ID 』问题。。

俩文件有多大呢？

文件 a 较小的话（内存存得下），如 8 楼所说，一两行 awk 应该就行了


@winglight2016 就 2 亿数据，感觉一个几百 KB 的 SQLite 都能很好应对，不必要上大数据平台吧