Новая тема   Ответить

 Ailk
-

Последний раз редактировалось: Ailk (18/09/16 в 00:28), всего редактировалось 1 раз

 Pentarh
Explain своего запроса скинь

 Ailk
-

Последний раз редактировалось: Ailk (18/09/16 в 00:28), всего редактировалось 1 раз

 johndoe2
возможно у тебя не тот ключ используется.

ты говоришь "ключ data", а в explain видно, что key=date.

чтобы этот запрос работал быстро, должен существовать ключ с полями public,approve,date (ИМЕННО В ЭТОМ ПОРЯДКЕ)

попробуй where изменить: условие на a.date сделай первым.

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

 Ailk
-

Последний раз редактировалось: Ailk (18/09/16 в 00:28), всего редактировалось 1 раз

 johndoe2
индексы могут быть убитые. попробуй optimize table сделать

если что-то не работает, нужно срезать лишнее, до тех пор, пока не начнет работать. так найдешь, где затык.

начни с простого запроса select ... from album_info a where a.date < 143496969815 order by a.date desc limit 199968,32

если он тормозит, значит либо индекса по date нет, либо он неактуален. пересоздай индекс или optimize сделай.

как только этот запрос перестал тормозить, добавляй в where прочие условия по одному.

и т.д.

 Ekko
Естественно будет тормозить т.к. используется LIMIT, он загоняет всю таблицу в память, а потом считает, индексы не помещаются никуда. Советую отказаться от LIMIT в пользу BETWEEN и пересмотреть архитектуру БД (связи многие-ко-многим как я понял нет), используй реляционную модель.

 johndoe2
возможно я понял, в чем проблема с исходным запросом.

создай индекс на полях date, public, approve (в этом порядке) и в where условия поставь в том же порядке.

тогда where И order by будут оба по индексу работать

 Ailk
-

Последний раз редактировалось: Ailk (18/09/16 в 00:28), всего редактировалось 1 раз

 Ekko
Код:
считать id для пагинации отдельно

 Ailk
-

Последний раз редактировалось: Ailk (18/09/16 в 00:28), всего редактировалось 1 раз

 Vers
Выноси часть в Монго, оттуда выборку делай по хэшу, будет на порядки быстрее.

 DF™
посмотри в сторону партицирования в mysql

 Stek
Ailk писал:
Поэтому в крупных проектах число страниц кешируется и часто не соответствует реальности.

Даже у гугла такое видно, когда результатов поиска показывает 1000, а после десятой страницы цифры начинают меняться или вообще число страниц заканчивается гораздо раньше. Сейчас набрал "django" - показал "About 40,700,000 results", но на 22 странице все результаты закончились.

Как вариант, отказаться от пагинации в виде [1,2,3,4,5 ... ] Использовать next, previos переходы. А там даешь передаешь id последней или первой записи, и от этого id отсчитываешь нужный результат.

 johndoe2
Вот простой способ как практически без затрат радикально уменьшить выборку.

Упростим задачу до костяка:

Есть таблица A с уникальным полем id. При добавлении строк это поле инкрементируется. Строки впоследствии могут быть удалены, т.е. среди значений id в таблице могут быть пропуски.
Заданы номер страницы N>=0 и размер страницы s>0.
Нужно найти такое значение id0, для которого (select count(*) from A where id<id0) = N*s, т.е. id, с которого начинается страница N.

Если среди значений id нет пропусков, тогда id0 = N*s.
Если же пропуски есть, тогда id0>N*s.

В любом случае: id0 >= N*s.

Последнее означает, что можно сразу отбросить строки таблицы, у которых id<N*s.

Влобный запрос выборки страницы выглядит так
select * from A order by id desc limit N*s,s

Считаем, сколько реальных строк отбрасываем: n1 = (select count(*) from A where id<N*s) - это запрос по primary индексу. И модифицируем запрос:
select * from A where id>N*s order by id desc limit (N*s-n1),s

Чем меньше в таблице удаленных строк, тем бОльший эффект будет.

Если таблица сильно прорежена, можно делать несколько скачков по id подряд. Цена каждого - запрос по primary индексу.

 rickdeckard
Ailk писал:

сохраняй группы id в кешах или memory таблице БД и тп.
обычное дело - кешировать любые долгие по времени или сложные выборки. id редко меняются.

для пагинации это
1 | набор id от 1 до N |
2 | набор id от N до N + N |
...

по номеру страницы получаеш набор id
по нему выбираеш посты - элементарно

 rickdeckard
ну а вообще частые джойны на большом кол-ве строк - не должно быть такого.

все сложные статистики должны кешировантся чтобы выбирать без постоянных пересчетов

> Если показывать инфо о посте с указанием автора, количества картинок и количеством коментов, то надо дернуть аж с 4 таблиц в дохуя записей данные. Учитывая что постов на странице 30 штук...

такие вещи лучше переносить на документоориентированные БД
тут обычная связь по 1 ключу получается

сохранил такую структуру в кеш и все летает

пост
- коменты поста
- картинки поста
- автор
и пр.

так для каждого
потом по id поста получаюеш за раз все данные

 Ailk
-

Последний раз редактировалось: Ailk (18/09/16 в 00:28), всего редактировалось 1 раз

 polusweb
так же убедитесь, что железо не самое убитое ну и проверить оптимальность настроек mysql тоже нужно. mysqltuner.pl может в этом помочь

 Stek

мускуль тут не при чем. LIMIT from,to - вообще во многих базах отсутствует именно по причине приведенной выше. Т.е. есть только LIMIT to.

 Ailk
-