@老虎会游泳，噢，我想起你之前提到过的：

老虎会游泳：如果索引只有两个键，就是遍历两个键，对其值的数量进行求和。

无名啊：你是说，一百行的表，对其中一个值域大小为2的字段建索引，该索引只有两条记录？每条记录指向50个主键ID？（假设均匀分布）

老虎会游泳：对呀，难道不是吗，B+树的一个节点不是能存很多指针吗？除非一个节点存不下，才会需要存储在相邻节点吧。

我后面找到的答案是：不是

下面这张图出自这个博客。可以看到：

1. 表格前 7 行是 Record Header，无论是聚集/非聚集的叶子/非叶子页上的每个记录，都会有这个 5+ 字节的记录头，先不管。
2. 表格后 2 行，表明二级索引的叶子页上，只会存着 索引键 和 主键，没有你说的【合并相同的索引键为一行记录】的结构

@TabKey9，离线版的啥？tinyjpg 吗？为啥不试试 Quality = 70 的 MozJPEG 呢？

@老虎会游泳，加过 explain 了，就是我说的这些情况

这个索引，基本就变成 1170W 的表了。。

@无名啊，或许他真的需要离线版（18🈲）@HongKongDoll，

@无名啊，我会这样创建索引：

CREATE TABLE 闭包表 (
    祖先节点ID INT,
    后代节点ID INT,
    这俩节点距离 INT,
    PRIMARY KEY (祖先节点ID, 后代节点ID),
    KEY (这俩节点距离, 祖先节点),
    KEY (这俩节点距离, 后代节点)
);

@无名啊，在SQL语句前加explain可以看到它是如何执行的。

@罐子，大概是白天喝茶多，困意姗姗来迟吧

还
没睡啊
一加8Pro

@TabKey9，
一加8Pro

我的blog开源斑马缘，要不要拿去玩玩源代码@凡焰，链接在主页底部。

太久没维护了，搞得我自己都无从下手！应该是tp5+某个前端页面模板渲染引擎+mysql。


有个简陋的友情链接，一些基本的博客功能，有个md编辑器，有个富文本编辑器，还有文章审核功能，估计也就这些而已

先 @ 万能的 @老虎会游泳

md

@罐子，感谢 我去试试

@凡焰，CMS或者typecho
或者zblog
,emlog
一加8Pro

@罐子，另外，大量图片批量转也不建议使用 squoosh

因为我和本地的 avifenc 对比，参数相同的情况下，前者的耗时大概是后者的 5~6 倍

感觉 wasm 还不能像 Native 应用那样利用好 CPU 性能

@罐子，不是 squoosh，是 tinyjpg

但 6 楼的测试，感觉 tinyjpg 吸引力不是很大：

1. 没有甩其他工具几条街（比如 squoosh 上 avif 默认参数压缩浣熊图，肉眼质量轻微损失情况下，能减少 90% 体积）
2. jpg 式微了，webp、heif、avif 是更好的选择

有没有离线版本，不重要了。。

@无名啊，https://github.com/GoogleChromeLabs/squoosh
一加8Pro

@MINE，@罐子，我拿 https://squoosh.app/ 首页的浣熊图试了试，

差不多大小的情况下（原图 2.66 MB，tinyjpg 768 KB，squoosh.app 的 Quality 调成 70 后 742 KB），感觉 tinyjpg 和 MozJPEG 没啥区别。。

@MINE，@罐子，这个有离线版吗？和 MozJPEG、webp 对比效果咋样？

@MINE，https://tinify.cn/
一加8Pro