С недавнего времени, на почту стали приходить письма с уведомлением об ошибке на форуме, в админке которого на мое «несчастье» стоял мой почтовый ящик. Письма были примерно такого содержания.

Database error in vBulletin 4.x.xx:

 Invalid SQL:

        INSERT INTO taggregate_temp_1338177360
                SELECT threadid, COUNT(*) AS views
                FROM threadviews
                GROUP BY threadid;

 MySQL Error   : Incorrect file format 'threadviews'
 Error Number  : 130
 Request Date  : Monday, May 28th 2012 @ 04:29:17 AM
 Error Date    : Monday, May 28th 2012 @ 04:29:17 AM
 Script        : http://forum.xxxxxxx.ru/cron.php?rand=1338179327
 Referrer      :
 IP Address    : xxx.xxx.xxx.xxx
 Username      : Незарегистрированный
 Classname     : vB_Database
 MySQL Version :

или еще вариант:

Database error in vBulletin 4.2.0:

 Invalid SQL:

         INSERT INTO aaggregate_temp_1345493400
                 SELECT attachmentid, COUNT(*) AS views
                 FROM attachmentviews
                 GROUP BY attachmentid;

 MySQL Error   : Incorrect file format 'attachmentviews'
 Error Number  : 130
 Request Date  : Tuesday, August 21st 2012 @ 04:48:17 AM
 Error Date    : Tuesday, August 21st 2012 @ 04:48:17 AM
 Script        : http://forum.xxxxxxx.ru/cron.php?rand=1338179327
 Referrer      : http://forum.xxxxxxx.ru/activity.php
 IP Address    :  xxx.xxx.xxx.xxx
 Username      : Незарегистрированный
 Classname     : vB_Database
 MySQL Version :

Зайдя phpmyadmin я ужаснулся кол-ву созданных таблиц с названиями типа taggregate_temp_1338177360, которых было не просто много, а очень и очень много и каждая создавалась каждый раз, когда на форум кто-то заходил и пытался смотреть тему. И в момент пересчета счетчика просмотров и вываливалась эта ошибка, одновременно с этим в базе появлялась новая пустая таблица.

Из найденных советов было и проверить есть ли переменная $cronimage в файле шаблона, не потерт ли запрос к картинке активирующий крон. Все было в полном порядке, ошибка как и следовало из логов, заключалась конкретно в поврежденной таблице threadviews и только в ней!

Попытка просто сделать оптимизацию и восстановление таблиц базы данных, особого успеха не принесла, причем ни как средствами самого форума, так ни средствами phpmyadmin. Так же провальной оказалась и попытка воспользоваться исправлением уникальных индексов, используя файл mysql-schema.php который так настоятельно предлагает применить сам форум.

Решение оказалось простым. Скачав с личного кабинета дистрибутив форума и взяв из него папку INSTALL со всем ее содержимым, мне понадобился лишь один файл mysql-schema.php, чуть ранее оказавшийся бесполезным, где и был взят запрос создающий поврежденную таблицу.

Предварительно удалив поврежденную таблицу threadviews через phpmyadmin, далее в нем же, переключившись на вкладку выполнения SQL запросов, ввел команду на создание нужной мне таблицы.

CREATE TABLE prefixname_threadviews (
	threadid INT UNSIGNED NOT NULL DEFAULT '0',
	KEY threadid (threadid)
)

В моем случае префикс был не нужен, поэтому все лишнее из запроса было убрано.

CREATE TABLE threadviews (
	threadid INT UNSIGNED NOT NULL DEFAULT '0',
	KEY threadid (threadid)
)

а для attachmentviews запрос такой:

CREATE TABLE attachmentviews ( 
        attachmentid INT UNSIGNED NOT NULL DEFAULT '0', 
        KEY postid (attachmentid) 
); 

Вставляем в поле Выполнить SQL-запрос(ы) к базе данных: и жмем ок. Дождавшись сообщения об успешном выполнении запроса, можно переключаться на вкладку структуры базы и выделив все таблицы, для профилактики сделать оптимизацию и восстановление таблиц.

Вуаля, и все работает как надо. Теперь каждый посетитель форума не вызывает кучу ошибок и не происходит захламление сервера логами ошибок, а в базе не плодятся ошибочные таблицы taggregate_temp_1338177360 и прочие. Все на все занимает ну минут 5 не больше.

З.Ы
Как я рад, что в свое время так и не воспользовался vBulletin 4.x.x, а остался на vBulletin 3.x.x =)