10 000 000 записей и скорость работы.

[NightFlash]

10 000 000 записей и скорость работы.

есть сайт турфирмы, есть таблица с турами(привожу в вольной форме элементами пхп массива):

"id INT AUTO_INCREMENT primary key",
"hotel_id INT(5) NOT NULL",
"tgroup_id INT(5) NOT NULL",
"date DATE",
"ftype VARCHAR(80)",
"rtype VARCHAR(80)",
"city VARCHAR(80)",
"ttype VARCHAR(80)",
"days INT(5)",
"nights INT(5)",
"price REAL",
"com REAL",
"exc_id INT(5)",
"source VARCHAR(90)",
"UNIQUE KEY travel(hotel_id, tgroup_id, date, days, nights, ftype, rtype, city, exc_id)"

сейчас в базе 300 000 записей, работает уже очень туго, всего планируется коло 10 млн. записей, есть какие-то советы по оптимизации?

ясное дело что под это все надо ставить выделенный сервер, ну а кроме этого? чисто по mysql реализации есть еще какие-то советы? в факи прошу не посылать.

 

[tony2001]

http://dev.mysql.com/doc/refman/5.0/en/optimizing-database-structure.html

 

[voituk]

На каких запросах работает туго?
Может это у тебя вывод, а не БД работает туго.

Посмотри по каким полям происходят выборки и связывания таблиц.
Построй по ним индексы.
Если используется LIMIT - ищи по форуму методы решения "медленного LIMIT"

 

[vg2k]

работает уже очень туго

Какие именно запросы "туго" работают ?

Сомневаюсь, что SELECT * FROM `table` WHERE `id` = X тормозит.

Тут уж сами запросы, имхо, именно смотреть...

 

[NightFlash]

запросы там очень сложные в которых естественное есть и лимит и куча условий и конструкции вида WHERE id IN(SELECT id from ... WHERE id IN(....))

 

[voituk]

NightFlash
Тогда что ты ожидаешь тут услышать?

Если дело действительно идет о 10 млн турах то могу поспорить что бОльшая часть из них уже не актуальна, - их можно перенести в другую таблицу дабы уменьшить количество обрабатываемых записей в операционной таблице.

-~{}~ 14.05.07 19:44:

и не надо под это все выделенных серверов - это не данные - это крошки.

 

[Trianon]

"ftype VARCHAR(80)",
"rtype VARCHAR(80)",
"city VARCHAR(80)",
вот эти три поля, вероятно, можно привести в порядок.

WHERE id IN(SELECT id from ... WHERE id IN(....))
кошмар.
наверняка, рефакторить нужно не только структуру базы, но и реализацию логики запросов.

 

[Hi-Man]

"ftype VARCHAR(80)",
"rtype VARCHAR(80)",
"city VARCHAR(80)",
"ttype VARCHAR(80)",

Эти поля лучше вынести в другие таблицы и заменить их на INT
тогда в таблице будут только числа.
В этом случаи поиск города по id будет быстрее чем по названию города.

 

[Krishna]

В этом случаи поиск города по id будет быстрее чем по названию города.

Ой ли?

 

[MajestiC]

Krishna
А почему нет? Если убрать все VARCHAR, то длина каждой записи будет известна.

 

[Hi-Man]

Автор оригинала: Krishna
Ой ли?

Всмысле?

Я из опыта говорю. Даже с базой в 80000 записей разница на лицо.

 

[Фанат]

Hi-Man
индексы использовать не пробовали? ;-)

-~{}~ 15.05.07 17:38:

Собственно, никто не ставит под сомнение необходимость заменить названия городов индексами. Наоборот - это надо сделать обязательно.
Но на скорости выборки будет сказываться именно наличие индекса. а не формат поля

 

[Hi-Man]

индексы, а что это 8)

Но Всеравно на мой взгляд можно улучшить скорость выборки например если в запросе используеться LIKE. Ведь города в основном повторяються и искать в таблице где он всего один быстрее чем в таблице где его бог знает сколько, так как база меньше. И в этом случаи останеться найти только четкое совпадение ид города в большой таблице нерибегая к использованию LIKE.

-~{}~ 15.05.07 18:01:

Увеличение скорости путем упращения запроса

 

[NightFlash]

Фанат
VARCHAR используется в силу того, что городов всего 2, а ftype и rtype тоже всего в нескольких вариациях, но может и увеличиться... надо попробовать перенести в другие таблицы, но уж больно плодить их не хочется...

Кстати, да. Индексы сократили время выполнения скриптов раз в 6 =)

 

[voituk]

NightFlash
А книжка с базовым описанием теории баз данных раз в 6 сократит твое время , проведенное на форумах в гпупых топиках.

 

[NightFlash]

спасибо приму к сведению. не нравится топик можешь не читать и не смотреть его.

 

[Фанат]

Тема закрыта.

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