innodb - это с ним всегда так??

Конвертнул обратно в myisam за 4 минуты. И место сразу вернулось, и скрипт залетал... Думаю, не скоро снова на эксперименты с innodb решусь :D

>Конвертнул обратно в myisam за 4 минуты. И место сразу вернулось, и скрипт залетал... Думаю, не скоро снова на эксперименты с innodb решусь :D

Юзай постгрес ;) А какая версия была?

мда... не нужны транзакции - то и смысла в ней нет. Но всё равно как-то печально. Может знающие люди что подскажут. Может подтюнинговать настройками можно...
А с другими движками МуСКуля не экспериментировал ?

>Юзай постгрес ;)

Сомневаюсь, что постгрес будет быстрее, чем myisam у MySQL

никогда не было таких проблем. Размер не сильно вырастал. Подозреваю очень древний мускул. Но даже с древним мусклом у меня ничего сильно не росло.

Покажи show create table

>Юзай постгрес ;)

Под него нет нормального web-админа :) phpPgSql - ужасен :)

>А какая версия была?

5.0.70-r1

>мда... не нужны транзакции - то и смысла в ней нет

Знающие люди говорили, что innodb выезжает и без транзакциях там, где в одной таблице много пишут и много читают - на блокировках. Но в моём случае до БД сейчас запросы доходят обычно, когда ничего другое не помогло (сперва статический кеш, потом сериализованные объекты в memcached, часто - сериализованные кеши в БД и т.п.), так что блокировок уже с год, как в процессах обычно не наблюдаю. Так что и проверить как-то не вышло. А вот на простых запросах проседает прилично. Ну и распухание базы - совершенно ужасное. Ладно, индексы. Но объём только данных с 55Мбайт до 125Мб вырос! :)

>Может подтюнинговать настройками можно...

Думаю, можно, но не на простых ненагруженных запросах. myisam-то на простых с любыми настройками хорошо работает.

>А с другими движками МуСКуля не экспериментировал ?

А их сегодня и осталось-то (современных) всего ничего и все специфичные. MERGE, MEMORY, ARCHIVE (названия по памяти) - универсальные и производительные только myisam и innodb.

Покажи show create table

CREATE TABLE `bors_pictures_thumbs` (
  `id` varchar(20) NOT NULL,
  `title` varchar(255) NOT NULL,
  `alt` varchar(255) NOT NULL,
  `description` text NOT NULL,
  `author_name` varchar(255) NOT NULL,
  `picture_type` varchar(32) NOT NULL,
  `create_time` int(10) unsigned NOT NULL,
  `modify_time` int(10) unsigned NOT NULL,
  `full_file_name` varchar(255) character set latin1 collate latin1_general_ci default NULL,
  `full_url` varchar(255) character set latin1 collate latin1_bin default NULL,
  `relative_path` varchar(255) NOT NULL,
  `file_name` varchar(255) NOT NULL,
  `original_filename` varchar(255) NOT NULL,
  `width` int(10) unsigned NOT NULL,
  `height` int(10) unsigned NOT NULL,
  `size` int(10) unsigned NOT NULL,
  `extension` varchar(6) NOT NULL,
  `mime_type` varchar(255) NOT NULL,
  `created_from` varchar(255) default NULL,
  `moderated` int(10) unsigned default NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `full_file_name` (`full_file_name`),
  UNIQUE KEY `full_url` (`full_url`),
  KEY `create_time` (`create_time`),
  KEY `modify_time` (`modify_time`),
  KEY `relative_path` (`relative_path`),
  KEY `file_name` (`file_name`),
  KEY `width` (`width`),
  KEY `height` (`height`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Ничего не могу сказать. Видимо тот самый случай когда innodb сосёт.

у постгре базу можно сплитить, скорость запроса у меня в 4 раза возросла (в базе куча статистики с оборудования: 440 мегабайт, 2746000 строк).

Но еще больше скорость возросла после перенесения на 10й рейд (4 рабочих + 1 спер). Запрос вообще сократился по времени более чем в 10 раз. А оставшиеся 2 секунды уже и не парят :)

> у постгре базу можно сплитить

в мускле table partitioning тоже поддерживаетя. И примерно с теми же ограничениями.