Размеры файла данных InnoDB

[MIl]

IPB 2.1.7.

Часто падала таблица ibf_posts. Таблица с 2,2 миллиона записей и занимала на диске чуть больше 1ГБ не считая фултекст индекса.

 

Перевёл её из MyISAM в InnoDB. Фуллтекст индекс конечно удалил.

 

Как я писал выше раньше таблица ibf_posts занимала на диске примерно 1 гиг, не считая индексов. Исходя из этой цифры для InnoDB решил указать три файла по 500 метров, последний с авторасширением, типа с запасом и не сильно большие файлы. И что я вижу после конвертирования - все три файла по 500 метров заполнены и последний авторасширился почти до 1,4 гига!

524288000 - ibdata0

524288000 - ibdata1

1488977920 - ibdata2

 

Это же в 2,5 раза больше, чем было с MyISAM! Нет я читал, что InnoDB занимает больше места, но я не предполагал что настолько!

 

Пришлось добавить ещё один файл данных размером с уже авторасширевшийся файл (1420М) и того у меня сейчас уже 4 файла данных:

524288000 - ibdata0

524288000 - ibdata1

1488977920 - ibdata2

524288000 - ibdata3

 

 

Это нормально? Как у вас?

Изменено 10 Июня 2007 пользователем MIl

[MIl]

Да, похоже придётся перейти обратно на MyISAM.

Ступор базы стабильно случается как минимум 2 раза в сутки. Во всех случаях замеченная мной причина ступора - один запрос с count(*) к таблице ibf_posts, которую я и конвертнул в InnoDB.

 

Был проведён нехитрый тест (на другой машине) - запрос "SELECT COUNT(*) from ibf_posts;".

 

Тип таблицы InnoDB (разные уровни изоляции на скорости никак не отразились):

 

mysql> SELECT COUNT(*) from ibf_posts;

+----------+

| COUNT(*) |

+----------+

| 2198861 |

+----------+

1 row in set (52.06 sec)

 

 

Теперь конвертим ту же таблицу обратно в MyISAM:

 

mysql> alter table ibf_posts type=myisam;

Query OK, 2198861 rows affected, 1 warning (4 min 44.89 sec)

Records: 2198861 Duplicates: 0 Warnings: 0

 

 

И запускаем тот же запрос:

 

mysql> SELECT COUNT(*) from ibf_posts;

+----------+

| COUNT(*) |

+----------+

| 2198861 |

+----------+

1 row in set (0.01 sec)

 

 

Разница между временем выполнения запроса просто поразительная - 52 секунды для InnoDB и 0.01 секунды для MyISAM.

 

 

Впечатления от медленной работы базы в InnoDB повторяют впечатления о большем объёме занимаемого базой места на диске - везде сказано что больше, но не настолько же! И если использование диска большее в 2,5 раза ещё можно терпеть, то медлительность большую на несколько порядков терпеть никак не получается.

 

 

Дополнение.

 

Кажется виновный в ступоре запрос найден и найдена функция, использующая этот запрос.

Запрос из файла sources/sql/mysql_queries.php:

function buddy_posts_last_visit( $a )
{
	return "SELECT COUNT(*) as posts
			FROM ".SQL_PREFIX."posts p USE INDEX (topic_id)
			LEFT JOIN ".SQL_PREFIX."topics t ON (p.topic_id=t.tid)
			WHERE t.forum_id IN({$a['forum_string']})
			AND p.queued=0 AND p.post_date > {$a['last_visit']}";
}

 

Функция function buddy_posts_last_visit используется при открытии "Помощника".

 

 

Я не нашёл ответа можно ли как-то переделать этот запрос, чтобы он работал с InnoDB таблицей быстрее, так что я просто удалил использование этой функции и всё, т.к. не считаю её необходимой. Закомментировал строчки вызова функции в файле sources/action_public/browsebuddy.php и отображение количества новых сообщений в шаблонах.

 

Надеюсь это позволит избежать ступоров базы.

Изменено 12 Июня 2007 пользователем MIl