Forum Webscript.Ru
Общие => Базы данных => Тема начата: Dj Fly от 06 Октября 2004, 14:19:24
-
Есть ли возможность создать в MySQL изначально отсортированную таблицу по одному из полей..
Предположим, у нас есть два интовых поля...
id | rating
И при выборке следующим запросом :
select * from table limit 1;
результатом была бы запись с наибольшм рейтингом, то есть таблица должна сортироваться сразу при вставке...
Я понимаю, что инсерт в эту таблицу будет тяжёловатым, при большом количестве записей, но идея в том, чтобы не использовать в запросе на выборку директив типа order
-
Dj Fly:
Есть ли возможность создать в MySQL изначально отсортированную таблицу по одному из полей..
Нет возможности. Да и вообще по теории БД таблицу стоит воспринимать как неотсортированный набор строк.
Dj Fly:
идея в том, чтобы не использовать в запросе на выборку директив типа order
А почему? Некошерная?
-
Дело в том, что при размере таблицы в 500000 записей order происходит несколько секунд, а для выдачи результат в клиентском приложении таких операций выполняется несколько.
Explain подобного запроса выдаёт Using Index, Using Filesort...
То есть получается, что при любом запросе на выборку такая таблица должна быть изначально отсортированной по полю rating
-
Dj Fly:
Using Index
Так почему ты индексы не хочешь использовать?
-
Даже используя индексы, получаются тормозявки в районе секунды :(
Важна как можно более быстрая выборка, насколько тяжёл будет инсерт - в общем-то похрен...
-
Dj Fly:
Предположим, у нас есть два интовых поля... id | rating
предлагаю от теории перейти к практике и показать реальную таблицу и реальные запросы которые ты делаешь.
-
Ok, существует несколько таблиц типа:
id | rating
В каждой из них может быть до полумиллиона записей...
На id повешен индекс
Запрос на выборку - склеивающий и выглядит следующим образом:
select test.a.id,(test.a.rating+test.b.rating+
test.c.rating+test.d.rating+test.e.rating)
from test.a,test.b,test.c,test.d,test.e where
test.a.id=test.b.id and test.a.id=test.c.id
and test.a.id=test.d.id and test.a.id=test.e.id limit 1000
Таким образом, у нас склеиваются до 5 таблиц по ID с тем, чтобы получить 1000 тех ID, которые обладают наивысшим рейтингом и содержатся в каждой из таблиц
В данном запросе нет директив типа order, дающих возможность получить ID с НАИВЫСШИМ рейтингом, но если бы таблицы были отсортированы изначально - этот запрос давал бы желаемый результат.
Применение инструкции order by rating, даже с повешенным индексом на поле rating замедляет операцию простой выборки из одной из таблиц, уж не говоря о запросе такого типа, ведь от-ордерить надо будет все 5 таблиц...
А вот полное сканирование дало бы сразу быстро желаемый результат, если бы таблицы были сразу отсортированы по полю rating
-
Dj Fly
Мы по моему уже обсуждали с тобой эту проблемму... тут тебе можно посоветовать перестать высасывать из php+mysql то что они тебе дать не могут... и перейти на системы которые позволят тебе достич желаемого результата...
-
Мы обсуждали подобную, но важно ли это...
Вопрос стоит так или иначе:
Есть ли такая возвожность?
Или нет?
И есть ли какие-либо предложения, способные хотя-бы навести на мысль к решению данной проблемы?
-
создай еще одну таблицу:
id | sum_rating
Из названий полей идея ясна ?
Это конечно избіточность данных, но должно повысить скорость выборки
-
Хм, само суммирование занимает очень малое количество времени, как показали различные модификации запроса...
Но дело в том, что таких даблиц склеивается от 2 до 5 штук и таких таблиц много и какие конкретно из них будут склеены - заранее неизвестно.
Поэтому хранить где-либо сумму рейтингов для каждых сочетаний не представляется возможным...
Если таблицы будут отсортированы заранее, то их можно и программно склеить, это быстро...
Не в склейке дело!
Дело в медленной инструкции order by
-
Dj Fly:
limit 1000
А тут может быть только 1000, или что угодно?
Можно тогда в ту таблицу, которую предложил Макс, записывать не все id, а только самые рейтинговые.
-
Dj Fly
ты можешь четко описать задачу ?
А то сначало речь шла об одной таблице, потом о пяти, а теперь оказывается их может от 2-х до 5.
ЗЫ
смысл моего способа был не в том, чтобы оптимизировать суммирование, а в том, что при этом тебе надо было join-ить только одну таблицу. И именно за счет этого был бы выигрыш
-
Хм, ок:
Существует некоторое количество таблиц такого типа.
Интерфейс пользователя определяет в зависимости от его запроса - какие из них надо склеивать...
Заранее определять - какие из них самые рейтинговые - не имеет смысла, поскольку при склейке - важна уже сумма рейтингов, а не рейтинг каждой отдельной таблицы!
-
Хм, ок:
Существует некоторое количество таблиц такого типа.
Интерфейс пользователя определяет в зависимости от его запроса - какие из них надо склеивать...
Заранее определять - какие из них самые рейтинговые - не имеет смысла, поскольку при склейке - важна уже сумма рейтингов, а не рейтинг каждой отдельной таблицы!
-
Господа решение найдено...
Возможность сортировать данные в таблице по определённому полю ЕСТЬ...
Теперь таблица хранится в отсортированном виде по полю rating.
:-)
Спасибо всем, кто конструктивно пытался помочь...
Теперь требуемый запрос выполняется на более чем полумилионных массивах данных из максимальных 5 таблиц без единой инструкции типа ORDER сортируется и выводится на экран пользователю и всё это менее чем за 100 миллисекунд...
Forza, учите теорию БД :-) Таблица - далеко не бессмысленный набор строк, который упорядочивают столь "быстрые" инструкции как ORDER :-)))
-
Dj Fly
Может поделишься знаниями?
-
myisamchk -R {# index} {tablename}
Сортирит данные в таблице по указанному ключу :-)