Оптимизация очереди в mysql

Question

Я создаю скрипт, который пересекает twitterusers, анализирует язык их твитов и, если правильный язык найден, все друзья и последователи добавляются в очередь. Эти пользователи, в свою очередь, выбраны из очереди, и процесс выполняется снова и снова. Чтобы быстро сохранить db, я использую одну и ту же таблицу для всех разных состояний, которые пользователь может иметь в очереди («для анализа для языка» = 1, «для получения» = 2, «in progress» = 9, «done» = 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 

Я тогда делать все волшебство, и, наконец, изменить queuetype к новому типу queuetype (сделано, заблокировано и т. д.).

Может ли решение быть дополнительно оптимизировано? «SELECT tid» работает очень медленно и занимает несколько секунд. Если я добавлю индекс в k, выбор станет быстрее, но обновление сильно изменится, и результат будет хуже.

Как оптимизировать этот тип очередей? Должен ли я рассмотреть другой дизайн? Другая база данных? Все решения приветствуются :)

[EDIT]

Двигатель MYISAM

EXPLAIN очередь

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

Answer 1

Я хотел бы предложить, что если вы хотите быстро INSERT производительности и только хотите, чтобы произвести поиск по точному совпадений, тогда вам нужен хешированный индекс. Но просматривая документацию here, я узнаю, что хэшированные индексы доступны только для механизма хранения NDB.

Я ничего не знаю об этом двигателе хранения, поэтому не стесняйтесь рекомендовать его, но, возможно, стоит попробовать, если он не слишком неудобен.

См. Также here.