2

我正在构建一个遍历 twitterusers 的脚本，分析他们的推文的语言，如果找到正确的语言，所有的朋友和追随者都会被添加到队列中。依次从队列中挑选这些用户，并一次又一次地执行该过程。为了保持数据库快速，我对用户在队列中可以拥有的所有不同状态使用同一个表（“要分析语言”= 1，“要获取”= 2，“进行中”= 9， “完成”= 99 和“阻塞”= -1）。这样我就可以将所有朋友/追随者添加到表中，而不必检查该人是否已经存在于表中（每个 Twitter 用户当然应该只分析一次）。

INSERT IGNORE INTO queue (tid,queuetype) VALUES (1,1),(2,1) ... (xxx,1);

这是相当快的。但是随着表的增长（几百万行）从队列中选择下一个用户，它变得越来越慢。

现在，我是这样做的（$uniqueid 实际上是进程号）：

UPDATE queue SET k='$uniqueid', queuetype = '9' WHERE k='0' AND queuetype = '1' LIMIT 1

其次是：

SELECT tid FROM queue WHERE k='$uniqueid' LIMIT 1

然后我做了所有的魔法，最后将队列类型更改为新的队列类型（完成、阻塞等）。

解决方案能否进一步优化？“SELECT tid”非常慢，需要几秒钟才能运行。如果我给 k 添加一个索引，选择会变得更快，但更新会变得很慢，结果更糟。

如何进一步优化这类队列？我应该考虑不同的设计吗？不同的数据库？欢迎所有解决方案:)

[编辑]

引擎是Myisam

解释队列

 tid    int(11) NO  PRI     
 queuetype  tinyint(1)  NO          
 k  mediumint(6) unsigned   NO
4

1 回答 1

0

我建议，如果您想要快速INSERT的性能并且只想搜索完全匹配的内容，那么您需要一个散列索引。但是仔细阅读此处的文档，我了解到散列索引仅适用于 NDB 存储引擎。

我对那个存储引擎一无所知，所以会犹豫推荐它，但如果不是太不方便的话，它可能值得一试。

另请参见此处。

于 2012-04-04T12:32:03.437 回答