AGvin

В данном случае, зачем сразу к БД лезть? Ведь есть такая вещь как кеши. В качестве ключа использовать "префикс" + CRC32(URL).

www.fromdual.com/tools + Zabbix
А вообще, ранее был такой вопрос (http://habrahabr.ru/qa/10967/ )

Если для процесса, который Вы назвали «дефрагменацией» использовался «OPTIMIZE TABLE», то с размером таблицы ничего не будет. Как я видел, везде рекомендуют дамп таблицы, ее удаление и заливку сдампленной версии.

На одном из форумов, нашел

Запросы висят в очереди: waiting in InnoDB queue. Это означает, что они ждут, когда
InnoDB освободится от работы с другими запросами (которые работают и не ждут).
Количество одновременно работающих в InnoDB запросов настраивается параметром
innodb_thread_concurrency. Но сильно повышать этот параметр не стоит — снизите
общую производительность системы, а проблему не решите. Надо смотреть, что за
запросы работают, и что с ними делать.

Думаю, Вам это будет полезно =)

В дополнение к вышеуказанному:

Aldorr скинул ссылку на описание JOIN-ов, но, что бы легче было понять, что это и с чем его едят, советую посмотреть: www.codinghorror.com/blog/2007/10/a-visual-explanation-of-sql-joins.html

Akint описал рабочий запрос, но, он не будет выводить пользователей без «девайсов», для выводов таковых, лучше использовать:

SELECT a.id,a.phone,b.device,b.address FROM users AS a LEFT JOIN devices AS b ON a.id = b.user_id;

Вы используете DISTINCT, что само по себе плохо.

«Если LIMIT # указывается совместно с DISTINCT, MySQL остановится, как только найдет # уникальных строк.»

Советую прочитать про то, как MySQL оптимизирует DISTINCT:

• happy.kiev.ua/mysql/manual.ru_MySQL_Optimisation.html#DISTINCT_optimisation
  
• habrahabr.ru/post/125428/
  

Все зависит от масштабов проекта. При таком варианте переключений между типами БД, у Вас будут сложности с оптимизацией вытяжки/изменении данных.

Сделайте пожалуйста «SHOW CREATE TABLE <table_name>;» и скиньте вывод в дополнение к вопросу, так будет нагляднее.

Насчет REPAIR, я как бы не в курсе, какая у тебя таблица MyISAM или InnoDB… Просто с InnoDB REPAIR тебе не поможет ( Если InnoDB — то лучше, почитай документацию.

Так же, в случае если к таблице привязаны ТРИГГЕРЫ, то скорей всего проблема может быть не с таблицей на которой валятся ошибки, а с таблицей в которую данный триггер вносит изменения.

Что тут сказать, у меня была схожая ситуация, причиной была сборка mysql. После обновления полегчало.
Но в данном случае, может еще быть проблема и с дисковой системой. Лучше проверь ее на целостность.

Так же, в принципе, если таблицу полностью чистишь командой «DELETE FROM table_name», то более оптимальным способом, будет использование «TRUNCATE TABLE table_name».

Тут вариантов много, по крайней мере, опиши хоть как бэкапишь свою БД. (если простым copy/past то могут возникнуть проблемы)
Также было бы не плохо описать сервер БД (какой софт стоит обычный mysql или percona?) Еще было бы очень не плохо узнать как возросла на нее нагрузка.