@老虎会游泳，那个博主给出新的解决方案了，速度上确实应该会很快，但空间占用也很恐怖。。
更改表结构和建立索引
那个博主新的表结构为：
CREATE TABLE 闭包表 (
祖先 INT,
后代 INT,
距离 INT,
PRIMARY KEY (后代, 距离),
KEY (祖先, 距离)
);
使得有如下两种索引：
- 聚集索引：
(后代, 距离, 祖先)
- 二级索引：
(祖先, 距离, 后代)
就能高效应对下列查询了：
- (孙)子/后代节点：走二级索引
(✔查询节点, ✔1 或 2 或 任意, ❓<要获取的后代节点>)
- (祖)父/祖先节点：走聚集索引
(✔查询节点, ✔1 或 2 或 任意, ❓<要获取的祖先节点>)
下列查询会小范围扫表，但问题不大：
-
某后代节点与某祖先节点的距离：走聚集索引 (✔查询后代节点, ❓<要获取的距离>, ❌查询祖先节点)
只要 查询后代节点 层级没有深到离谱，扫表范围也就连续的几行几十行而已。
占的空间太大了，怀疑性价比
一个 66W 的 5 级地区表，就要配套一个相当于 780W 的闭包表，快接近 12 倍于主表的辅助表了。。
如此恐怖的空间换时间方案，到底能快多少呢？真的值得投入这么多空间来提速吗？
。后面要用了就直接调用数组了
只是很不熟,太菜了
之前看到过这个不过我在termux终端测试输入没有高亮我以为不支持🤣🤣
无名啊
