Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, Konstantin, Вы писали:
MC>>>Во-вторых, возможно стоит попробовать вертикальное партицирование таблицы, т.к. 6Гб на 800000 записей в общем случае — это много. K>>А это как ?
MC>Перенести часть столбцов в отдельную таблицу. Если поля longtext используются редко, то их как раз и вынести в отдельную таблицу.
К сожалению могу только одно поле вынести. По другому будет полнотекстовый поиск. Но это хоть что-то...
Здравствуйте, MasterZiv, Вы писали:
MZ>Anton Batenev wrote:
>> Данная "проблема" называется пэйджингом страниц. В простейших случаях >> может решаться как-то так <http://habrahabr.ru/blogs/mysql/44608/>.
MZ>"Проблема педжинга" решается только убиранием этого самого пейджинга MZ>из приложения. Нет пейджинга -- нет проблем. Есть пейджинг -- есть проблемы. MZ>Более она никак не решается.
Ну а как без пейджинга решить вопрос постраничного листания ?
Здравствуйте, MasterZiv, Вы писали:
MZ>Мало того, что запрос бессмысленный (он выдаёт MZ>произвольные, случайные записи),
Теоретически это так, практически далеко не всегда. Особенно при использовании MyISAM.
MZ>он ещё и ВСЕ ТВОИ 800 000 записей MZ>из таблицы обрабатывает. В "начале таблицы" быстро, потому что начинает MZ>читать подряд все записи, и успокаивается на первых 1000. В "конце таблицы" MZ>медленно, потому что долго-долго читает впустую почти все 800 000 записей, MZ>а потом выдаёт одну тыщу из них.
В случае MyISAM и fixed row format "он" знает, какие записи нужно прочитать и откуда. Возможно, что на это и был рассчитан такой пейджинг изначально, а потом добавились поля longtext, из-за чего сменился формат записи и доступ стал неэффективным. А может просто база не была рассчитана на такой объем данных.
Здравствуйте, MasterZiv, Вы писали:
MZ>Konstantin wrote: >> SELECT * FROM `table` LIMIT 799000 , 1000 >> (...Query took 149.6909 sec) >> >> Подскажите, как ускорить это дело ? Вроде же должно быть примерно с >> такой же скоростью ?
MZ>Да никак не ускорить. Мало того, что запрос бессмысленный (он выдаёт MZ>произвольные, случайные записи), он ещё и ВСЕ ТВОИ 800 000 записей MZ>из таблицы обрабатывает. В "начале таблицы" быстро, потому что начинает MZ>читать подряд все записи, и успокаивается на первых 1000. В "конце таблицы" MZ>медленно, потому что долго-долго читает впустую почти все 800 000 записей, MZ>а потом выдаёт одну тыщу из них.
MZ>Виной тому, безусловно, не очень продвинутый оптимизатор MySQL : я бы на MZ>месте их выдавал бы всегда на такие запросы первые 1000 записей. MZ>Пользователю всё равно, а серваку приятно. Но запрос тоже дурацкий, MZ>а на все дурацкие запросы в оптимизаторе закладок не наделаешь.
Ну оказалось, что ускорить можно с помощью WHERE id > 700000. И это весьма радует. Так что...
[skip] MZ>>а потом выдаёт одну тыщу из них.
W>В случае MyISAM и fixed row format "он" знает, какие записи нужно прочитать и откуда. Возможно, что на это и был рассчитан такой пейджинг изначально, а потом добавились поля longtext, из-за чего сменился формат записи и доступ стал неэффективным. А может просто база не была рассчитана на такой объем данных.
Ну просто я сейчас пытаюсь максимально ускорить работу базы, чтобы когда пойдет реальная работа, ничего не переделывать. И ищу вот такие узкие места.
Здравствуйте, Konstantin, Вы писали:
K>Ну просто я сейчас пытаюсь максимально ускорить работу базы, чтобы когда пойдет реальная работа, ничего не переделывать. И ищу вот такие узкие места.
А, так вы и есть разработчик? Тогда настоятельно советую изучить статью, указанную Anton Batenev.
Konstantin wrote:
> Ну а как без пейджинга решить вопрос постраничного листания ?
А никак не надо решать вопрос постраничного листания.
Постраничное листание -- это бесполезная трата машинного
времени и сил листающего человека.
Если ему что=то нужно, ему нужно дать возможность сформировтаь
набор критериев для выборки и соответственно делать выборку.
Konstantin wrote:
> SELECT * FROM `table` WHERE ID > 799000 ORDER BY ID LIMIT 1000
> MC>Так будет правильнее и должно в несколько раз ускорить выполнение > запроса. Подразумевается что ID — первичный ключ. > > (1,000 total, Query took 0.0805 sec) > > Гениально! Все гениальное просто как оказалось
Просто, да не просто.
Тебе нужно априори знать ID, от которого можно плясать, и гаратнированно
будет та страница, которая тебе нужна. Ты это знаешь ?
Я так понял, что нет.
> L>Если сначала прочитать индекс, то будет ясно, с каких конкретно > страниц читать данные, тем самым может уменьшиться объем данных, кот. > необходимо поднять с диска.
Индекс надо будет прочитать ВЕСЬ. Данные пото -- да, не все.
> А как заставить MySQL это сделать ?
Ну особенно заставлять не нужно, ORDER BY это сделает.
> ну да: > > * проблема MySQL решается убиранием MySQL. > * проблема в использовании БД решается убиранием БД.
Ирония неуместна. Сколько уже копий сломано, а всё изза
того, что не очень опытные программисты не могут понять
простую вещь: пейджинг никому не нужен. Или не могут
объяснить это своему тупому мэнеджеру проекта.
Other Sam wrote:
> Мне сейчас недосуг проверять, но почему-то я уверен, что если условия > WHERE и ORDER BY попадают под исполнение по индексу, то чтений из > таблицы должно быть только то количество какое указано в LIMIT, а OFFSET > будет пропущен.
Конечно.
Только у нас до сих пор одна проблема: нет WHERE.
Здравствуйте, MasterZiv, Вы писали:
MZ>того, что не очень опытные программисты не могут понять MZ>простую вещь: пейджинг никому не нужен. Или не могут MZ>объяснить это своему тупому мэнеджеру проекта.
Да менеджеру-то еще можно, а вот как тупым пользователям объяснить? Пробовал?
Они, понимаешь ли, ленятся "сформировтаь набор критериев", их пейджинг вполне устраивает. Темные, что тут говорить.
Здравствуйте, MasterZiv, Вы писали:
MZ>Konstantin wrote:
>> Ну оказалось, что ускорить можно с помощью WHERE id > 700000. И это >> весьма радует. Так что...
MZ>Ты знаешь априори этот id > 700000 ? вместо 700000 для другой страницы MZ>что ставить будешь ?
Как ни странно — максимальный прочитанный ID (при листании на 1 страницу вправо) или минимальный прочитанный ID (при листании на 1 страницу влево).
Здравствуйте, MasterZiv, Вы писали:
MZ> не очень опытные программисты не могут понять MZ> простую вещь: пейджинг никому не нужен.
Расскажи это, например, команде гугля, которая сделала постраничный вывод результатов поиска. Ну или команде RSDN, которая сделала пэйджинг в списках сообщений — эти ответят на чистом русском
Здравствуйте, MasterZiv, Вы писали:
>> (1,000 total, Query took 0.0805 sec) >> >> Гениально! Все гениальное просто как оказалось
MZ>Просто, да не просто.
MZ>Тебе нужно априори знать ID, от которого можно плясать, и гаратнированно MZ>будет та страница, которая тебе нужна. Ты это знаешь ? MZ>Я так понял, что нет.
Удаления будут нечастыми и можно построить значения стартовых id для каждой страницы. Причем даже с помощью хранимой процедуры прямо на сервере.
