Оптимизировать для чего?! он медленно работает или работает не корректно? Какая цель то?
т.е. настроить форум, как например тут, не судьба?
Ну без кэша:
Отображает строки 0 - 29 ( 34,030 всего, запрос занял 0.0005 сек.)
С кэшем:
Отображает строки 0 - 29 ( 34,030 всего, запрос занял 0.0002 сек.)
Ну функция моего кэша теперь ещё быстрее будет работать :)
Составной индекс, действительно, почему не подумал раньше :(
Сейчас пока вставляется, потом тестану.
Да там проблема в другом. Как зайдут наши любимые поисковые боты на разделы + 5000 обычных юзеров... и понеслось гонять эту гиговую таблицу туда сюда. Каждый хочет её SELECT 2-а раза, а она блокируется каждый раз.
Поэтому и решил кэш именно файловый сделать с id, ну и + количество id в text не помещается, а это значит держать такие массивы смысла нет в БД.
А если укажу php, что случиться? Я могу и txt указать, а могу и вообще без расширения. Офигеть да?
Да не вопрос.
CREATE TABLE `cms` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`dec` text COLLATE utf8_unicode_ci NOT NULL,
`trans` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`data` date NOT NULL,
`pic` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`comment` int(1) NOT NULL DEFAULT '0',
`comment_static` int(1) NOT NULL,
`rating_static` int(1) NOT NULL,
`rating` int(1) NOT NULL DEFAULT '0',
`art` int(1) NOT NULL DEFAULT '0',
`nextart` int(1) NOT NULL DEFAULT '0',
`krohi` int(1) NOT NULL DEFAULT '0',
`description` text COLLATE utf8_unicode_ci NOT NULL,
`keywords` text COLLATE utf8_unicode_ci NOT NULL,
`cat` int(11) NOT NULL,
`search` text COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `trans_2` (`trans`),
KEY `data` (`data`),
KEY `cat` (`cat`)
) ENGINE=MyISAM AUTO_INCREMENT=185776 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
Выкачайте через телепорт (там многопоточность) себе весь сайт и на локалке уже выбирайте нужные данные :)
Настроил сервер, помогло, теперь хоть летает.
Конечно не могу понять иногда тормоза. Один из вариантов получается, всё упирается в диск и когда много запросов идёт, он просто ожидает. ---------- Добавлено 04.09.2012 в 23:38 ----------
Всё на 1 серваке.
Да максимум 30 000 записей id, это 30 000 * 3 (знаков в id в среднем) = 90 000 байт ---------- Добавлено 04.09.2012 в 23:39 ----------
Да куда проще то?
---------- Добавлено 04.09.2012 в 23:39 ---------- Кстати таблица 1 ГБ весит :)---------- Добавлено 05.09.2012 в 01:00 ----------Короче решил. А решил файловым кэшем. Взял да записал все эти id в файлы по категориям. И теперь мускулю не надо париться, перерывать каждый раз гигабайтную БД (которая растёт очень быстро), а берёт нужные id из файла.
Супер быстрая разбивка и хождение по страницам каталога.
Во как! :)
А в чём проблема накатать в ЯД?
