Добрый день.
Как сделать лучше? Два варианта: 
1) создать одну таблицу с 500тыс записей
2)разбить таблицу на ~300 небольших таблиц, каждая таблица отдельная категория будит

Если делать делать вторым способом то надо будит сделать на один запрос больше(чтобы узнать нужную категорию). Для получения нужных данных во втором варианте таблицы соединять не нужно будит

Это сообщение отредактировал(а) Fubu_By - 5.2.2010, 16:34

Один вариант. Первый. Без вариантов.   

аргументируете?

500 тысяч записей это фигня полная, о чем тут думать вообще? Поиск по нормально спроектированной таблице будет идти со скоростью света. Второй вариант это не вариант а недоразумение.

Это сообщение отредактировал(а) azesmcar - 5.2.2010, 16:38

Отобраться по одной из 300  категорий, получится  ~0,3% от всего набора.
Это достаточно низкая селективность, чтобы отбор по индексу был эффективен.
Абсолютно не ясно чем вызваны ваши тревоги

Это сообщение отредактировал(а) Zloxa - 5.2.2010, 16:50

тревога вызвана тем что портал уже тормазит неплохо, при тестировании(а расчитаннывается посещаемость несколько десятков тысяч в сутки),  и без таких запросов если кэшировать, выбори идут из объединения таблиц по 200тыс с несколькими тысячами, вот и пытаюсь по чуть чуть каждый запрос сделать оптимизированным, это 

если есть реальная структура и реальный запрос, то почему здесь нет ни того ни другого, а лишь абстрактный и потому лишенный смысла вопрос? )

Не там ошибку ищешь, покажи структуру таблиц (с индексами) и запрос который тормозит.

Это сообщение отредактировал(а) azesmcar - 5.2.2010, 17:14

// на всякий случай
explain этого запроса тоже добавьте

или же

на крайняк - 
это ведь не PHP!   
сорри за офттоп.. не удержался.

Это самый трудо затратный по выполнению запрос у меня


а это запрос который я хочу разбить, таблицу offers разбить на пару сотен небольших таблиц которые буду подключатся в селект в зависимости от prefix



Это сообщение отредактировал(а) Fubu_By - 9.2.2010, 12:52

Сущность offers не характеризуется атрибутом prefix. Этот атрибут характеризует сущность products. Если вы денормализуете таблицу offers, наделите ее атрибутом prefix, чего вы добъетесь? Отбор из этой таблице вы производите по id_product, который индексирован. Рассував данные из этой таблицы по признаку prefix в разные таблицы, вы ни в коем случае не уменьшите количество чтений потому что вы и так для доступа используете индекс.(должны, по идее, вы не привели плана)

Единственное преимущество от этой иновации, которое я могу высосать из пальца - если вы файлы каждой из таблиц разместите на разных физических дисках, возможно вы сможете избежать ожиданий на дисковых чтениях двух конкурентных сессий, выбирающихся по продуктам с разными префиксами. Но тут же вы соединяетесь с таблицей products, доступ к которой сведет весь бенефит на нет. Если только и products разобрать на табличи и раскидать по дискам, как и offers. 



Вопрос не Вам, но знающим:
Я слышал индексы MyISAM хранят количество уникальных значений в нем. Хрянят ли они количество записей, соответствующих каждому значению?

Если это так, возможно имело бы смысл построить индекс по product.prefix, чтобы можно было бы использовать инфомрацию о количестве из это индекса.

Если это не так(что наверняка), имело бы смысл сделать сбоку табличку которая содержала бы количество продуктов по категории, вести эту табличку из триггеров на продукты и запросы делать к ней а не к табилце продуктов. Благо вы все равно используете MyISAM , вам нечего боятся избытка блокировок по модификации.

Это сообщение отредактировал(а) Zloxa - 9.2.2010, 17:27

ок теперь понял, что разбивать смысла большого нету

Добавлено через 39 секунд
а как оптимизировать можно первый запрос чтобы выполнялся быстрее?

Fubu_By, 
Поэтому даже сказать нечего.

Fortop, зачем тебе план первого запроса? Там и так видно что фулсканы неизбежны. 
Fubu_By, чем не устроило мое предложение со вспомогательной таблицей? Было ли произведено исследование на предмет наличия в индексе информации о количестве строк? Имеет ли смысл Вам отвечать в дальнейшем, если Вы не пытаетесь воспринять ответы?