-

-

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

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

-

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

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

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

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

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

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

-

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

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

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

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

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

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

и т.д.

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

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

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

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

-

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

Код:

SELECT * FROM album_info WHERE id BETWEEN 199968 AND 32

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

-

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

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

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

Ailk писал:

Я ж устану пересчитыввать этот ид при операциях с постами. Опубликовать\скрыть, удалить, например.

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

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

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

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

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

Есть таблица 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 индексу.

Ailk писал:

Походу от этого никак не избавится, только кеширование поможет. Даже с праймари индексом запрос типа Код: SELECT * FROM album_info WHERE id>0 LIMIT 199968,32 будет работать пол секунды. По сути тащит с конца таблицы, пробегая весь цикл от начала и до конца, отсюда и такие задержки. А альтернатива лимиту вообще есть? Для пагинации.

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

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

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

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

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

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

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

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

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

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

-

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

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

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

-