[Обзор конференции Юань Чуан] 1024 День программиста (за два дня до этого), встретимся в китайском офисе Open Source, поговорим об искусственном интеллекте! >>>

Описание вытаптывания:

При написании интерфейса постраничного запроса, когда порядок и лимит смешиваются, возникает путаница с сортировкой: при запросе N-й страницы появляется та же запись, что и данные на первой предыдущей странице.

вопрос

В страничных запросах в MySQL мы часто используем лимит.Например: лимит(0,20) означает запрос 20 данных на первой странице, а лимит(20,20) означает запрос данных на второй странице. В бизнесе мы обычно добавляем порядок при пейджинге;

Но при совместном использовании лимита и порядка по могут появиться данные на странице N, которые дублируются данными на предыдущем номере страницы.

Например:

SELECT a,b FROM table WHERE c=1 ORDER BY d desc LIMIT 0,20

При использовании приведенного выше SQL-запроса весьма вероятно, что будет найден тот же фрагмент данных, что и LIMIT 20,20. Чтобы решить эту проблему, мы добавили сортировку по идентификатору (уникальная индексная страница) после ORDER BY, чтобы избежать этого.

следующее:

SELECT a,b FROM table WHERE c=1 ORDER BY d desc，id desc LIMIT 0,20

Теоретически, сортировка MySQL использует идентификатор первичного ключа в качестве условия сортировки по умолчанию.То есть, если условия d равны, идентификатор первичного ключа будет использоваться в качестве условия сортировки по умолчанию, и нам не нужно добавлять идентификатор по возрастанию. . Но дело в том, что в MySQL возникает путаница с сортировкой, когда одновременно используются порядок и предел .

анализировать

В версии MySQL 5.6, когда оптимизатор встречает оператор order by+limit, он выполняет оптимизацию и использует очередь приоритетов .

Цель использования приоритетной очереди заключается в том, что, когда порядок индексов не может быть использован, если вы хотите сортировать и использовать ограничение n, вам нужно сохранить только n записей во время процесса сортировки. Хотя это не может решить проблему всех записей, требуются накладные расходы на сортировку . , но для завершения сортировки требуется лишь небольшой объем памяти в буфере сортировки .

Причина, по которой MySQL 5.6 имеет проблему дублирования данных на второй странице, заключается в том, что приоритетная очередь использует метод сортировки кучей, а сортировка кучей является нестабильным методом сортировки , то есть одно и то же значение может быть отсортировано и считано. порядок противоречивый.

MySQL 5.5 не имеет такой оптимизации, поэтому этой проблемы не возникнет.

Другими словами, в MySQL 5.5 нет описанных в этой статье проблем, такая ситуация появилась только после версии 5.6.

(1)     SELECT 
(2)     DISTINCT <select_list>
(3)     FROM <left_table>
(4)     <join_type> JOIN <right_table>
(5)     ON <join_condition>
(6)     WHERE <where_condition>
(7)     GROUP BY <group_by_list>
(8)     HAVING <having_condition>
(9)     ORDER BY <order_by_condition>
(10)    LIMIT <limit_number>

Порядок выполнения следующий: где... выбрать... упорядочить по... пределу.... Из-за указанной выше очереди приоритетов после завершения выбора все записи упорядочиваются методом сортировки кучи. в порядке, только наибольшее значение d перемещается вперед. Однако из-за предельного фактора во время процесса сортировки необходимо сохранить только 20 записей.D не имеет индексного порядка, поэтому, когда должна отображаться вторая страница данных, MySQL возьмет любую запись, которую увидит. значения сортировки одинаковые, первая сортировка произвольная, при втором выполнении SQL результат должен быть таким же, как и первый результат.

Решение

1. Попробуйте использовать уникальные значения для сортировки

Если к полю добавлен индекс, он будет прочитан и выгружен по страницам непосредственно в соответствии с порядком индекса (если это поле имеет повторяющиеся значения, страница может повторяться).

В конце можно добавить сортировку по идентификаторам и на бизнес это не повлияет.

2. Правильно понимать пейджинг

Пейджинг основан на сортировке и разбит на диапазоны количества. Сортировка — это функция, предоставляемая базой данных, а разбиение на страницы — производное требование приложения. Официальные документы MySQL и Oracle предоставляют методы limit n и rownum < n, но концепция подкачки четко не определена. Еще одним важным моментом является то, что, хотя приведенное выше решение может облегчить эту проблему для пользователей, согласно пониманию пользователя, проблемы все еще существуют: например, эта таблица вставляется чаще, и когда пользователь запрашивает, на уровне изоляции с фиксированием чтения. , первая и вторая страницы по-прежнему будут перекрываться, этого можно избежать, используя идентификатор. Поэтому при подкачке данных всегда возникала эта проблема, и в различных сценариях не предъявляются очень высокие требования к точности подкачки данных.

3. Некоторые распространенные проблемы с сортировкой базы данных

Проблема с сортировкой, когда порядок по не добавлен

Когда пользователи используют Oracle или MySQL, они обнаруживают, что MySQL всегда в порядке, но Oracle очень хаотичен, главным образом потому, что Oracle представляет собой таблицу кучи, а MySQL — таблицу с кластеризацией индексов. Таким образом, при отсутствии порядка база данных не гарантирует порядок возврата записей и не гарантирует согласованность каждого возврата. Проблема подкачки - проблема дублирования подкачки Как описано ранее, подкачка - это требование приложения, полученное из функции сортировки, предоставляемой базой данных.База данных не гарантирует дублирование проблемы подкачки. Проблемы со значениями NULL и пустыми строками. Различные базы данных понимают и обрабатывают значения NULL и пустые строки по-разному. Например, значения Oracle NULL и NULL несопоставимы, ни равны, ни неравны, и неизвестны. Для пустой строки при вставке MySQL представляет собой пустую строку с длиной строки 0, тогда как Oracle напрямую обрабатывает значения NULL.

Глубокая проблема с подкачкой

Иногда, когда нам нужно сместить определенный объем данных для получения определенных данных, легко подумать об использовании ограничения. Однако, если смещение велико, вы обнаружите, что выполнение SQL из-за смещения очень и очень медленное. Он будет считываться в буферный пул страницами.Если объем данных большой, занимаемое пространство буферного пула будет большим, а размер этого пространства настраивается и обычно не очень велик;

Во-вторых, данные необходимо сканировать с самого начала. Наконец, большой объем данных необходимо отбросить и сохранить только несколько необходимых фрагментов данных. Кроме того, процесс может также потребовать операций возврата таблицы, что приводит к медленному SQL.

Для оптимизации этой проблемы рекомендуется написать условие фильтра (например: автоматически увеличивающийся идентификатор первичного ключа или упорядоченное поле), а затем объединить его с ограничением для его реализации.

Автор: JD Retail Ма Чэнлун

Источник: Сообщество разработчиков JD Cloud. При перепечатке указывайте источник.

Ежедневные ошибки в исследованиях и разработках: дублирование данных подкачки Mysql | Техническая команда JD Cloud