Есть таблица Ид_ПАРАМЕТРА ИД_Продукта_К_которому_принадлежит_параметр Дата_Модификайции_параметра Цена Скидка Количество_товара_с_такими_параметрами Цвет Размер Флаг_Видимости Она растет))растет уже подошла к 100 тысячам записей и будет расти все поля этой таблицы числа а дата модиф таймстамп.. Все поля кроме цены, скидки, количества и даты индексы... Но думаю как еще можно ускорить работу?
Ускорить что? Можно убрать ненужные индексы, тогда вставка будет работать быстрее. Можно переписать алгоритм работы так, чтобы сервер БД хорошо кешировал данные выборок. Он отлично всё сам кеширует, но… Рассмотрим поле Количество_товара_с_такими_параметрами — это типа счетчик? Где-то чего-то изменилось и ты тутже правишь счетчик, да? После этого изменения все закешированные запросы с участием твоей таблицы становятся невалидными. Неважно, что поле-счетчик в них не используется. Вот такая хуйня малятки. Могу провести аудит запросов за деньги.
А вообще EAV (http://en.wikipedia.org/wiki/Entity–attribute–value_model) это по определению неэффективная структура. Такие вещи надо радикально рефакторить. Самое место для NoSQL базы в качестве кеша! Добавлено спустя 1 минуту 7 секунд: ебанутый здесь парсер bbcode. когда такая ссылка в теге [ url ] то вообще отказывается понимать тег. позорище
Сейчас завершаю) парсер базы очень большой для магаза проверююю иии.. Думаю да закажу чуть позже только дня через 2. Тоже чуть позже пока не полная база время не полное).. Изучать начну сейчас) Добавлено спустя 37 минут 34 секунды: Нет тут немного сложней.. В идеале должно быть так да.. Но это поле обновляется раз в сутки)
А причем здесь eav )) у меня не чья то готовая цмска где суть eav все подряд валяется в 1 таблице у меня в таблице с параметрами те поля как я написал типов инт каждый и это отдельная ячейка
не на это не особо)больше похоже н стандартное row вродк называется... Код (Text): SELECT DISTINCT `pid` FROM `catalog_param` WHERE `show`="1" AND `count`!="0" AND `sex`="2" AND `showrun`="0" ORDER BY `created` DESC, `pid` DESC LIMIT 0 , 20 это основной запрос.. Вообще база так строится.... Есть таблица где хранится товар его имя и вообще текстовые параметры они в таблице N1 Другая таблица catalog_param хранит вот параметры.. У одного товара может быть любое кол-во цветов размеров наличие есть или нет, цена от цвета может меняться... А pid это внешний ключ для связи 1 таблицей... После получения пидов делается такой запрос Код (Text): SELECT * FROM `catalog` WHERE `id` IN("72121","72120","72118","72117","72114","72113","72112","72110","72109","72108","72107","72106","72105","72104","72103","72102","72101","72100","72099","72098") ORDER BY `id` DESC ................. Это простая выборка при старте Потом на аяксе человек может пощелкать бренд цвет и тогда к первому запросу добавлется Код (Text): SELECT DISTINCT `pid` FROM `catalog_param` WHERE `show`="1" AND `count`!="0" AND `sex`="2" AND `showrun`="0" AND `brand` IN(1,54,2,6) AND `color` IN(1,54,2,6) ORDER BY `created` DESC, `pid` DESC LIMIT 0 , 20 Смотря что на щелкает... Добавлено спустя 1 минуту 30 секунд: Брэнд цвет размер и цену поставить диапозон ..все эти поля индексы кроме цены Добавлено спустя 50 секунд: Хаписи уже почти все в бд .. пока их 110 000.... Предполагаю к вечеру завершится парсинг и будет 150 000 - 200 000
Был дельный вопрос - покажи запросы и время их выполнения. 200к записей не должны быть проблемой для БД (при нормально составленном запросе). Вот обзорная статья на твою тему: http://habrahabr.ru/post/125428/ но там речь о миллионах записей.