@janus77 对于 SQLite 而言，宿主语言也可以（甚至更好地）完成相同的任务吧？

还能更好应对分库分表，利用上 ORM ，减轻数据库压力等


好吧，就算存储过程是吧。还有啥嘛？

@kkocdko 确实。拿了个 ~/.conda/pkgs/cache/e5e4a514.json （ 64.8 MB ）试了下

- lzma 极限压缩后 7.14 MB ，解压时间为 0.7 s
- zstd 极限压缩后 7.26 MB ，解压时间为 0.1 s


@Doragd 或者，考虑用 pickle 存？文件又小，速度又快

上述文件用 pickle 存后，只需 35.1 MB 了

lzma 极限压缩后 7.06 MB ，zstd 极限压缩后 7.68 MB

@janus77 请教一下，MySQL 比 SQLite ，多支持了什么实际较常用的『较复杂的表结构和查询语句』呢？

为啥不用 MySQL 8.0 呢？

这些窗口函数连 SQLite 都已经在 4 年多前支持了。连 SQLite 都不如的，我觉得应该换了

JSONPath ？

在线尝试： http://jsonpath.com/

@monkeydream 我大概算算 MySQL 单表，受限于 IO 的读并发吧：

假设：
- B+ 树 4 层 *（若 InnoDB 、Dynamic 、16 KB 每页、8 字节主键、1 KB 一条消息，可容纳 110 亿）*
- 缓存前两层 *（ 14 MB 内存代价）*
- 有 `(uid 4 字节, time 5 字节)` 索引
- 每个用户每次获取不超过 700 条消息 *（此时索引只需读一个叶节点）*
- **不缓存实际消息** *（就当所有用户都在获取历史消息吧。因为每个叶节点可能存着 15 个不同用户的消息，太散了，不会算『每次一个用户获取一堆消息时，能利用上多少缓存』，直接按最差情况算）*


设每秒有 x 人请求，平均每人有 y 条消息要获取，硬盘有 z 个 16 KB 的 IOPS ，那么：

2x （每人消耗 2 次 IO 去索引读取自某个时间以来的消息 ID 列表） + 2xy （每条消息都要 2 次 IO 去消息表读取） <= z


如，我的垃圾固态，16 KB 有 25000 IOPS （也就 400 多 MB/s ）。那么：

每秒 100 人要获取消息时，平均每人能得到（不在缓存中的） 124 条历史消息？


（数据库新手，算的不对，恳请指出）

同意 #1

1. 种类不多，你可以存成 `set[tuple[弹药, 该弹药能攻击的物体]]`：

```python
弹药能攻击的物体 = {
　(弹药 1, 物体 1),
　(弹药 1, 物体 2),
　(弹药 2, 物体 1),
　(弹药 2, 物体 3),
}
```

判断：`if (弹药 1, 物体 1) in 弹药能攻击的物体:`


2. 种类巨多，可能存成 `dict[弹药, set[该弹药能攻击的物体]]` 能省点内存？但比上面的慢

```python
弹药能攻击的物体 = {
　弹药 1: {物体 1, 物体 2},
　弹药 2: {物体 1, 物体 3},
}
```

判断：`if 物体 1 in 弹药能攻击的物体[弹药 1]:`

@monkeydream 你要并发读多少啊？

那个帖子里反馈，MySQL 单表这么多亿，单次查询也能 10- ms 啊（噢，26 楼写错了）

@b123405060 超过 500w 会怎样？ B+ 树从 3 层 变为 4 层？

然后由于内存只能完整缓存前两层（前两层代价是 20~30 MB 内存，前三层代价是 20~30 GB ），所以 3 层变为 4 层，会导致实际 IO 由 1 次 变为 2 次，即速度下降 50%？

还是怎么个逻辑？

数据库新人，求指教

@monkeydream 3 天前的 [这个帖子]( https://www.v2ex.com/t/882773 ) 里，有很多人反映，MySQL 单表存 1~2 亿（#11 楼 #16 #18 #19 #21 #35 ）、4 亿（#27 ）、10 亿（#35 ）、20 亿（#28 ）都没问题诶，查询也很快（几十 ms ，#27 #28 ）

MySQL 真的不行吗？

我这儿复制粘贴到主编辑器里后正常

你能贴下在主编辑器里的图片不？

1. 确实，本地可构建个类似的语句来复现，不知缘由：

*（ V 站排版原因，开头有全角空格。若要复制运行，记得删除）*

```mysql
WITH
　 nums(num) AS (
　　 VALUES ROW(1), ROW(2), ROW(3)
　)

SELECT @total, @total := sum(num)
FROM nums, (SELECT @total := 0) t
GROUP BY num;
```



2. 如果你只是想要『上一行的数据』，你可以使用*（连 SQLite 都支持的）*窗口函数 `LAG`：

```sql
WITH
　 nums(num) AS (
　　 VALUES ROW(1), ROW(2), ROW(3) -- SQLite 写法：VALUES (1), (2), (3)
　)

SELECT num, LAG(num) OVER(ORDER BY num)
FROM nums;
```



3. 另外，[MySQL 官方文档]( https://dev.mysql.com/doc/refman/8.0/en/user-variables.html ) 很不推荐你图片中的用法：

- 除了 `SET` 语句外，不应在同一条语句内赋值和读取一个用户变量*（ 5.7 版本文档：As a general rule, other than in SET statements, you should never assign a value to a user variable and read the value within the same statement ）*

- 涉及用户变量的表达式的求值顺序未定义*（ 8.0 版本文档：The order of evaluation for expressions involving user variables is undefined. For example, there is no guarantee that SELECT @a, @a:=@a+1 evaluates @a first and then performs the assignment ）*

- 『在 `SELECT` 中使用 `:=` 为用户变量赋值』已被弃用，未来会移除*（ 8.0 版本文档：Previous releases of MySQL made it possible to assign a value to a user variable in statements other than SET. This functionality is supported in MySQL 8.0 for backward compatibility but is subject to removal in a future release of MySQL ）*

@mizuBai 没怎么用过。这货能利用索引，只读 几 KB ~ 几十 KB ，就能找到指定节点数据吗？

我觉得如果楼主 @LuckyPocketWatch 要换存储格式，这点很重要

另外，简单搜了搜资料，很多人都说 feather parquet pickle 等格式都比 hdf5 读写速度快、体积小

看来 csv 很不适合存大量数据了（ json xml 同理）

@shubiao 那你继续拿以前的苹果用不就行了

前排问一下，一直说的『单表超过 x 千万后，效率瞬间下降』，是因为 B+ 树层数变高（这个量级应该是 3 层变为 4 层吧），但缓存没变（比如，只缓存了前两层），导致看起来原本实际进行一次 IO ，现在需要两次，即多一倍耗时？

如果是这样，那楼主看看现在是不是已经 4 层 B+ 树了，若是就不必要分表了？（ 4 层可以容纳上百亿行了吧）

实在不行，上海鲜市场淘个旧旗舰呗。比如小米 8 骁龙 845 好像三四百就可以买到了

肯定存时间戳啊

时区问题这么复杂，你确定数据库真的都能处理好了？

万一以后中国又实行夏令时，你数据库咋处理。。

感觉 WinRAR 的恢复记录功能，会对你有帮助（如果不想压缩一遍再添加恢复记录，可用类似的独立功能软件，如 MultiPar ）

如，设定生成 3% 的恢复记录，允许你出错最多不超过 3% 的情况下，恢复原文件

既能帮你验证文件，又能修补你说的复制出错，还能一定程度预防存储出错（当然，肯定多份备份更好）

@LuckyPocketWatch Python 有个 lxml 库*（该库是对 libxml2 的包装，速度很快）*，支持你说的『不需要解析树，查询某个节点』场景（ SAX ）

文档地址： https://lxml.de/tutorial.html#event-driven-parsing


另外，不考虑转成数据库嘛？我觉得这个场景，SQLite 的速度都能吊打 XML 。。