关于csdn 帖子最后更新时间排序问题

2015-08-17 10:31:35 148 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

seqwait 墨衍会员 · AI 创作全网分发关注 + 加入社区

软工第二次个人作业——软件案例分析 2023级北航软工第二次作业——软件案例分析阅读详情

csdn 帖子都是海量数据,按照最后更新时间进行排序,但是如果按照limit x,x 的话当数据量非常大的时候就显得非常慢了,但是如果按照 lastUpdateTime>= 的话分页可能有重复数据,这个该怎么破?

...全文

DumbDetector：用社区信号构建AI工具问题追踪与验证平台人工智能工具的快速迭代让质量问题变得难以追踪，官方文档与实测表现常常脱节，而真实使用中的故障信息分散在社交媒体、论坛和Issue列表中，难以形成有效参考。社区信号机制通过采集、验证和聚合用户反馈，能够构建一份可追溯的“翻车记录”。其核心原理是将零散吐槽转化为结构化情报，辅以投票、复现记录和验证者角色，形成社区共识。相比纯自动化检测，人工验证在语境判断上更具优势，同时爬虫可作为信号增强的辅助手段。该模式适用于AI工具评测、风险预警、技术选型参考以及产品质量的众包监督等场景，帮助团队在升级或采购前识别潜在风险。阅读详情

seqwait

Web 开发 81,108 成员 341,721 内容

+ 关注 + 加入社区

切换为时间正序

HinanaiTenshi 2015-08-17

打赏
举报

一般是做了冷热分离、数据结转或者时间分区之类的处理吧，论坛的常用数据量远远小于历史数据。 mysql时间分区如果做的好，1亿数据的简单查询大概几百毫秒。

Defonds 2015-08-17

打赏
举报

引用 7 楼 oZhiMing12 的回复:

[quote=引用 5 楼 defonds 的回复:] 都在同一张表里的话，肯定慢的不行。分表、分库。而且应该还有前端、后端缓存。

引用那采取哪一种分页比较好呢? 直接 limit ?,? 但是假如有上千万条数据呢?[/quote]一般 limit 就可以了。其他的不是那么精确的。 sql、索引写的好，而且表结构组织的好的话，单表千万也不是问题

执笔记忆的空白 2015-08-17

打赏
举报

引用 6 楼 oZhiMing12 的回复:

[quote=引用 3 楼 shijing266 的回复:] 还有这个

我用的是mysql 最后更新时间,不是ID 最后更新时间是实时变化的不能根据ID[/quote] 你要问的是分页吧？排序不就直接order by XXX desc了？

seqwait 2015-08-17

打赏
举报

引用 5 楼 defonds 的回复:

都在同一张表里的话，肯定慢的不行。分表、分库。而且应该还有前端、后端缓存。

引用那采取哪一种分页比较好呢? 直接 limit ?,? 但是假如有上千万条数据呢?

seqwait 2015-08-17

打赏
举报

引用 3 楼 shijing266 的回复:

还有这个

我用的是mysql 最后更新时间,不是ID 最后更新时间是实时变化的不能根据ID

Defonds 2015-08-17

打赏
举报

都在同一张表里的话，肯定慢的不行。分表、分库。而且应该还有前端、后端缓存。

gukuitian 2015-08-17

打赏
举报

CSDN的数据量真不大, 你看看这java版的帖子,才13W出头,加个索引直接查都完全没问题

执笔记忆的空白 2015-08-17

打赏
举报

还有这个

执笔记忆的空白 2015-08-17

打赏
举报

可以看看这个

执笔记忆的空白 2015-08-17

打赏
举报

这个就看csdn用的是什么数据库了...

关于csdn 帖子最后更新时间排序问题

相关推荐