Разбиение на страницы MySQL без двойных запросов?
Речь не идет об Оптимистической блокировке. Это исключение выдается при удалении / обновлении записи по Id, который вообще не существует. Поэтому убедитесь, что запись, которую вы обновляете / удаляете, действительно существует в БД.
Однако, чтобы лучше понять причину проблемы, вы можете:
1) Установить show_sql как true 2) Установить уровни журналов для Spring и Hibernate на DEBUG
Это поможет вам разобраться в проблеме и исправить ее.
4 ответа
Нет, вот сколько приложений, которые хотят разбить на страницы, должны это сделать. Это надежный и пуленепробиваемый, хотя он делает запрос дважды. Но вы можете кэшировать счет на несколько секунд, и это очень поможет.
Другой способ - использовать предложение SQL_CALC_FOUND_ROWS , а затем вызвать SELECT FOUND_ROWS () . Помимо того факта, что вы должны поместить вызов FOUND_ROWS () впоследствии, есть проблема с этим: в MySQL есть ошибка, из-за которой это срабатывает, что влияет на ORDER BY запросов, что делает его намного медленнее в больших таблицах, чем наивный подход двух запросов.
query = SELECT col, col2, (SELECT COUNT(*) FROM `table`) AS total FROM `table` WHERE `some_condition` LIMIT 0, 10
В большинстве ситуаций гораздо быстрее и менее ресурсоемко делать это в двух отдельных запросах, чем в одном, даже если это кажется нелогичным.
Если вы используете SQL_CALC_FOUND_ROWS, то для больших таблиц это делает ваш запрос намного медленнее, значительно медленнее, чем выполнение двух запросов: первый с COUNT (*), а второй с LIMIT. Причина этого заключается в том, что SQL_CALC_FOUND_ROWS вызывает применение предложения LIMIT после выборки строк вместо ранее, поэтому он выбирает всю строку для всех возможных результатов перед применением ограничений. Это не может быть удовлетворено индексом, потому что он фактически выбирает данные.
Если вы используете подход с двумя запросами, первый только выбирает COUNT (*), а не фактически выбирает и фактические данные, это может быть выполнено намного быстрее, потому что он обычно использует индексы и не должен извлекать фактические данные строки для каждой строки, которую он просматривает. Затем второму запросу нужно только просмотреть первые строки $ offset + $ limit и затем вернуться.
Этот пост из блога производительности MySQL объясняет это далее:
Для получения дополнительной информации об оптимизации разбивки на страницы, проверьте этот пост и этот пост .
Я почти никогда не делаю два запроса.
Просто верните на одну строку больше, чем необходимо, отобразите на странице только 10, а если их больше, чем отображается, отобразите кнопку «Далее».
SELECT x, y, z FROM `table` WHERE `some_condition` LIMIT 0, 11
// iterate through and display 10 rows.
// if there were 11 rows, display a "Next" button.
Ваш запрос должен возвращаться в порядке наиболее релевантного. Скорее всего, большинство людей не будет заботиться о переходе на страницу 236 из 412.
Когда вы выполняете поиск в Google, а ваши результаты не на первой странице, вы, скорее всего, перейдете на вторую страницу, а не на девятую. .