一个本地NMB数据阅读器无名氏No.68758003 返回主串
2026-06-01(一)18:07:05 ID:SLDLTVR 回应
最开始只是想给大洛山的串留个档，然后
下都下了，整个本地阅读器吧( ´∀`)
整都整了，做个服务器版吧，手机就也能看了( ﾟ∀ﾟ)
做都做了，把检索也加上吧( ﾟ 3ﾟ)
加都改加了，把整个流程改完整点吧(ゝ∀･)
现在觉得整这么麻烦为啥我不直接上岛看了(*ﾟーﾟ)
总之这是个从下载数据到双端阅读的NMB阅读器|-` )
无标题无名氏No.68810181
2026-06-09(二)00:17:27 ID: SLDLTVR (PO主)
>>No.68810159
(*ﾟ∇ﾟ)bbbbb
行，白天上工位看看GPT还有啥建议没，我感觉也没啥别的了
无标题无名氏No.68811494
2026-06-09(二)09:47:11 ID: SLDLTVR (PO主)
给了一堆建议但好多是咱昨天说过的
需要关注一下的就下面几个
1.content用TEXT
2.created_at存INT，UNIX时间戳
3.PRI(id, tag_id),KEY(tag_id, id)这两个应该PRI(thread_id, tag_id),KEY(tag_id, thread_id)
4.installment用NUMERIC这种精确的格式
5.类型、系列那堆加回thread，要不还得验证tag里这些东西是否唯一
无标题无名氏No.68811857
2026-06-09(二)11:00:19 ID: SLDLTVR (PO主)
要不你直接问AI吧，你们俩的细节解释的我都不太懂(;´ヮ`)7
后端我真不会啊(つд⊂)
不过我是觉得你直接定就好了( ﾟ 3ﾟ)
无标题无名氏No.68811900
2026-06-09(二)11:07:18 ID: SLDLTVR (PO主)
>>No.68811867
别的没了，对TEXT这块AI原文是
TEXT 不会因为类型叫 TEXT，就天然变成“大量随机 IO”。真正决定 IO 的是：
你怎么查
一次查多少行
数据库怎么存储长字段
这些正文是不是被频繁读
先说结论
如果你的页面是“先按索引找一页 post_no，再把这一页对应的 content 读出来”，TEXT 完全正常
真正容易带来 IO 压力的，不是 TEXT 这个类型本身，而是“正文很大、读得很频繁、而且每次查很多不需要的正文”
你的场景里要点是
目录页不要扫正文
目录页只查 thread / tag / status / installment / count 这些轻字段，不碰 content，IO 就很轻。
阅读页按页取少量帖子正文
比如一次只取 20/50 条，这也没问题。
你本来就是要把正文显示出来，这部分 IO 无论 VARCHAR(8192) 还是 TEXT 都躲不掉。
不要在大范围筛选里直接扫 content
如果你以后做全文搜索，别用普通 LIKE '%xxx%' 去硬扫大表。
那才是真的 IO 杀手。要么上全文索引，要么单独做搜索方案。
为什么 VARCHAR(8192) 也不能避免这个问题
就算你把列定义成 VARCHAR(8192)：
里面存的还是长正文
读正文时照样要把正文拿出来
所以 IO 压力本质没变
也就是说：
TEXT 不是问题来源
“频繁扫描大正文”才是问题来源
如果你担心 IO，可以这样设计
post 表只放轻字段和定位字段
post_content 单独放 content
列表、筛选、分页尽量先走轻表
只有真正打开阅读页时，才按当前页 post_id 去取正文
其实你现在这个“索引表 + 正文表”思路，本身就是在避免不必要的正文 IO，这个方向是对的。
一句话
TEXT 不会天然导致大量随机 IO；
真正导致大量 IO 的，是把正文当索引字段去大范围扫描。
你这种阅读器场景，只要“目录查轻字段、阅读页按页取正文”，TEXT 是合适的。
无标题无名氏No.68812635
2026-06-09(二)13:07:21 ID: SLDLTVR (PO主)
>>No.68812311
是要从写数据库开始就屏蔽某些cookie吗
感觉在前端留给用户自己填屏蔽的饼就行
然后冗余的字段如果只是没必要而不是有负面影响的话，我觉得就先保留。删掉某一字段应该比之后想追加的时候，重新加数据容易吧( ﾟ 3ﾟ)
无标题无名氏No.68812736
2026-06-09(二)13:27:46 ID: SLDLTVR (PO主)
>>No.68812678
结构没啥了，不过这个图片地址存一下原本的图床链接如何
我现在程序里下载的时候是把图片名改成串号的，默认串号全局唯一的情况下，图片地址只要确定哪个串需要图片就能知道
保存原图床链接是想着，万一下载的时候retry次数都用完了也没下下来图片，之后有人再用的时候可以再试着访问一次