@sudosu #43 微软不要它口碑了吗？

驱动都是要微软认证，才能运行的呀？

怎么系统设计，就不经微软允许了呢？

难道这只是驱动签名收费的一个由头借口？

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

@ComplexPug #7 关于第二个问题：

1. 直观上说，每个字符串都只出现一次，最后取哪 100 个字符串呢？

2. 假如说，题目保证肯定有 100 个字符串，出现次数最多。

那如果，我这样构造原始文件呢：

你分割的前 2047 个小文件里，所有字符串都只出现一次，
在第 2048 个文件里，100 个字符串出现两次。

你在构造哈希表，甚至每个分组统计 TopK 时，会不会要在内存里，保留几乎整个原始文件的字符串了？

那内存会不会爆炸了。。

Excel 不是默认不运行宏的吗？ https://i.imgur.com/F29pmQ6.png

@sudosu #2 驱动都要微软认证才能用，怎么系统就能任由某团队放飞自我了呢？

@h3xz 不知道你是怎么存的。我写个示例，你按情况改了后，执行看看？


1. 准备 SQLite 环境

原因：
① 不想在这儿写 C/C++，太冗长。
② 后文的脚本，需要用到 dll 没有的，仅命令行版本才有的 readfile 函数。

步骤：
① 打开 https://sqlite.org/download.html
② 找到 sqlite-tools-win-x64-3450200.zip （当前版本）并下载（若 Linux/MacOS 找对应平台的）
③ 解压，得到 sqlite3.exe


2. 准备（存数据的） SQL 文件

参考以下内容，按你自己情况更改后，用 UTF-8 编码，保存为 test.sql 。

```sql
-- 把默认页大小 4KB 改为 64KB 。因为你大部分数据都很大，一次读取便加载更多数据，能提速
PRAGMA page_size = 65536;

CREATE TABLE image (
id INTEGER PRIMARY KEY,
-- 假设你通过名字来定位图片及其他数据。UNIQUE 既创建了索引，也保证名字唯一
name TEXT NOT NULL UNIQUE,
-- 注意，默认生成的时间，是 UTC 时间，比中国慢 8 个小时
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
extra_data JSON,
data BLOB NOT NULL
);

BEGIN;
-- 省略 id ，SQLite 则会自动填写为最大 ID + 1 。
-- 单引号内的 \ 不用转义。若要表示 '，双写即可。如 'Kai''Sa.jpg'。
-- 文件路径不要包含中文，因为 SQLite 会把 UTF8 字符串，原样调用系统 API ，然而 Windows 会以为是 GBK 编码。。
-- 如果文件路径一定包含中文，请保证其它字符串（如 name 列）没有中文，然后 SQL 文件转为 GBK 编码。
INSERT INTO image (name, data) VALUES ('aaa.jpg', readfile('C:\aaa.jpg'));
INSERT INTO image (name, data) VALUES ('bbb.jpg', readfile('C:\bbb.jpg'));
INSERT INTO image (name, extra_data, data) VALUES ('ccc.jpg', '{"width": 123, "height": 456}', readfile('C:\ccc.jpg'));
COMMIT;

-- 可选：碎片整理数据库文件，并去除冗余空间，达到瘦身紧实的效果。
-- VACUUM;

SELECT printf('写入了 %d 个文件，共 %d 字节。', COUNT(*), SUM(LENGTH(data))) FROM image;
```


3. 执行

```shell
sqlite3.exe images.db < test.sql
```

你放一下表结构，和你当前怎么查数据的 SQL 呗。。

11W 数据。。感觉 SQLite 单线程都能很快啊。。至于 8 线程么。。

@drymonfidelia 噢，漏了一些东西。

你的 record_query_IDX 索引，没有 type 。。

那就建个 (query, record_id, type) 的索引？

然后 SQL 是 select record_id, type FROM qcs.records x WHERE `query` = "DEMOQUERY1111" ORDER BY record_id DESC;

后续参考上一楼。

@drymonfidelia 你 type IN (...) 少的时候，是不是能快些？

若是，我猜是 MySQL 去匹配不同范围的次数太多了。

如果你要的数据，都比较集中在最新添加的几天内，那么只使用一个范围，应该能提速很多。


假设你的 record_id 越大，created_at 也越大。

则可以：select record_id FROM qcs.records x WHERE `query` = "DEMOQUERY1111" ORDER BY record_id DESC;

这会使用你的 record_query_IDX 索引。

接着，你在程序内，一条条读取，直到 (1,2,4,7,2510,27442,440097,800022) 的 type 全部有数据为止。

最后，再根据得到的 record_id 集合，去主表拿整行数据。

@ComplexPug 有些极端情况，咋办呢？

1. 只有俩 500GB 的不同的字符串，但它们 hash 相同。
2. 所有字符串，都只出现一次。

@h3xz 那就存 SQLite 数据库呗。。

优点：

- 单文件
- 可随机读写
- 依赖库只有几百 KB
- 有原生 C/C++ 接口
- 可存一系列数据（编号、日期、数据、图片文件本身、……），单个数据最大 2GB


写了 10GB 共 2500 条数据（每条包含 4MB 图片及数据），
再测试下，随机读取图片速度（测试前，已用 RamMap 清空系统文件缓存）：

- 机械盘：27 条数据/秒（ 150 MB/s 顺序读取，0.65 MB/s 随机 4K 读取）
- 内存盘：323 条数据/秒（ 6754 MB/s 顺序读取，310 MB/s 随机 4K 读取，感觉明显没吃满 IO ）

手机上的播放器，能播放吗？

比如 PowerAMP 啥的？

MP3 随身听之类的呢？

@nodejsexpress SQLite 数据库文件就算大到 1TB ，也没事啊？又不是启动就要读完它？

楼主，放下你的 表结构 和 SQL 出来看看？

@leonshaw #16 用哈希应该更快些？

@ccadb #32 你发个数量留空的《本月商品清单.xlsx 》模板文件，然后让大家在对应商品旁边填上想要的数量，再把这 100 多份 Excel 文件收集回来，写条 SQL 统计，不就好了。。

@ccadb #20 换成收集电子表格的形式呗，肯定比纸质表容易处理数据呀？

我还是认为，如果你已有上百个 Excel 文件，写条 SQL 语句，就能输出你要的统计表了。

再写个批处理，就能自动打印啥的了。

@ccadb #11 如果你已经收集了上百个 Excel 文件，那之后写一条 SQL 就能统计出你要的数据了呀？