@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 就能统计出你要的数据了呀？

感觉直接在 t_article 加字段比较可行。

大家也常说，回表查询，速度会变慢嘛。搞个中间表，不就相当于回表查询了。。

但应该也有限度。如果设立的区域过多，还不如直接去有索引的表查了？

怎么我感觉，你想写的是：select sum(a > b) from t ？

这个备份文件怪怪的。。感觉像 SQLite 数据库事务没提交，进程就被结束了的样子。。

@Jammar #63 基本的计算机知识得要有吧。。哪有一个 4GB 文件，分成 18W 份临时文件的。。

@thinkm #65 提升用户体验，是说好看吗？

@star7th #71 不一定。天翼云盘那个可能是程序员的问题，就算不用 Electron ，换其他工具也一样。

但夸克网盘那个，可能真的是 Electron 封装得太好，导致开发者以为，预先分片任务到 IndexedDB 没啥代价了。。（结果搞了 几 TB 写入出来。。）

我的意思是，就是因为简单，所以什么人都能胜任，但深入的细节可能由于自身没有知识储备，处理不好，所以质量可能比 QT 等软件的差。。

会 QT 之类的，应该就暗含对计算机比较熟悉的前提条件了吧？那开发出来的软件质量高，也是大概率的事情？