前情摘要：https://assbbs.com/thread-36208.htm
看到NodeSeek分页限制在100页，手贱点进去还把他们网站搞到503崩了。
传统的MySQL分页模式，在offset跳过数据过大的时候，就会变慢。
因此我采用了B+树磁盘存储，把key链表顺序缓存到内存。
100万条数据测试结果：
B+树读取链表到内存，用时213ms。
按阅读权限写入两个Map列，数据合计无误。
取第888888条数据，几乎没有任何分页时间。
（不到1ms，理论上1亿数据速度也相差不大）
按此分页key中的数据，从SQLite加载行即可。
试验可行，明天就把数据融合到程序中去。
测试数据样例：
太棒了
C: cn 太棒了 昨天技术群里发了个，收到些反馈，还可以再优化。去掉中间层缓存，速度还能提升很多。
C 昨天技术群里发了个，收到些反馈，还可以再优化。去掉中间层缓存，速度还能提升很多。
技术群可以推一下吗 看看
cn: C 昨天技术群里发了个，收到些反馈，还可以再优化。去掉中间层缓存，速度还能提升很多。 技术群可以推一下吗 看看
cn 技术群可以推一下吗 看看
私信了，群主相当牛逼，全球第二的帝国理工CS科班
我实测过5000w数据，用索引分页响应速度没啥变化
袁某人: 我实测过5000w数据，用索引分页响应速度没啥变化
袁某人 我实测过5000w数据，用索引分页响应速度没啥变化
看怎么分的，如果传入参数 index>=* 这类的，那定位很快的。
因为都是B+Tree，找到其中一项时间是O(1)，后续只要通过左右数值游标找就行了。
如果你5000万数据用 OFFSET 40000000, LIMIT 10 这种方式，在 OFFSET 大的时候会很慢。
这论坛总共就几个活人 动不动几百万几千万数据用得到吗[em_37]
NeKoYun: 这论坛总共就几个活人 动不动几百万几千万数据用得到吗[em_37]
NeKoYun 这论坛总共就几个活人 动不动几百万几千万数据用得到吗[em_37]
我可以不用，但是我不能没有[em_20]
呆哥
更新复杂度多少，你这更新要遍历链表吧
链表还不能并发写
maggch
C大nb！[em_23]