Оптимизиция запросов к БД Sape

[slar]

Давно работаю с тяжелыми БД и хорошо знаю, что если запросы неоптимизированы, то возникает дополнительная нагрузка на сервер баз данных, что очень часто приводит к ошибке 504.
Примеры неоптимизированных запросов Sape для ВМ (для О то же самое)
1. Работая, к примеру, со страницей №5, после разбора ссылок система возвращает тебя не на стр. №5, а на первую. Причина - не используются закладки.
2. Разбирая ссылки на странице одновременно можно выбрать только одну причину отказа. Это значит, что придется снова возвращаться к той же странице чтобы обработать другие ссылки на предмет другой причины отказа. Также легко решается.
3. Список страниц выдается как 1,2,3,4,5,6.... последняя. Вопрос - сколько нужно телодвижений (запросов к БД) чтобы попасть на стр. 16 ? Три.

В итоге: чтобы обработать ссылки на стр. 16 по трем критериям, мне приходится вместо одного запроса сделать девять! А это и есть источник дополнительной нагрузки на сервер баз данных со всеми вытекающими последствиями.
Примечание: увеличение числа выдаваемых строк со 100 стандартных до скажем 500, не только не решает проблему, но и усугубляет ее, т.к. нагрузка на сервер БД возрастает нелинейно от количества строк в выборке.

[Последний Герой]

Сообщение от slar

В итоге: чтобы обработать ссылки на стр. 16 по трем критериям, мне приходится вместо одного запроса сделать девять!

Вы не правы. 1 ссылка - 1 запрос. Независимо подтверждение, отказ или ГБЛ.
И разницы нет по 1 ссылке или все сразу.

Добавлено через 1 минуту
Что касается удобства возможности помечать ссылки разными метками (ОК, ГБЛ, ОТКАЗ) и нажимать кнопку 1 раз - полностью с вами согласен.

Добавлено через 31 секунду
Что касается страниц - так выводите больше ссылок на странице

[slar]

Сообщение от Последний Герой

Вы не правы. 1 ссылка - 1 запрос. Независимо подтверждение, отказ или ГБЛ.
И разницы нет по 1 ссылке или все сразу.

Естественно речь идет о блоке ссылок, а одна там ссылка или 10, конечно это один запрос. Так что все остается в силе.

[Последний Герой]

Сообщение от slar

Естественно речь идет о блоке ссылок, а одна там ссылка или 10, конечно это один запрос. Так что все остается в силе.

Не вижу разницы
UPDATE что-то WHERE id=чему-то LIMIT 1
делать блоком или поотдельности
запросов столько же

[slar]

Сообщение от Последний Герой

Не вижу разницы
UPDATE что-то WHERE id=чему-то LIMIT 1
делать блоком или поотдельности
запросов столько же

Если Вы не видите разницы, тогда попробуйте в одном запросе откажите 3-м ссылкам
по причине не подходит текст и 10 ссылкам откажите с занесением в GBL. И сообщите как это Вам удалось сделать. А заодно, может покажете как за один прием попасть на стр. №16 из ссылок, помеченых, например OK.

Добавлено через 11 минут
Увеличивая число ссылок на странице в выводе Вы увеличиваете вероятность ошибки 504, как я говорил зависимость здесь нелинейная. Эту особенность баз данных обойти невозможно.

[Последний Герой]

про удобство я уже говорил, что с вами согласен

про нагрузку на сервера сапы - она не снизится

Сообщение от slar

Увеличивая число ссылок на странице в выводе Вы увеличиваете вероятность ошибки 504

не верно

[slar]

За ошибкой 504 могу предположить чаще всего скрывается превышение лимита времени на обработку запроса, что зависит в свою очередь как от самого запроса, так и количества других одновременно обрабатываемых запросов. И чем меньше ненужных дополнительных запросов, тем реже Вы будете видеть 504 ошибку. Конечно это только один из факторов, но это один из самых важных факторов. Пусть админы поправят, если это не так.

Добавлено через 1 минуту

Сообщение от Последний Герой

не верно

Аргументируйте!