Во-первых, использование предела
Когда мы используем операторы запроса, нам часто приходится возвращать первые несколько или средние строки данных, что нам делать в это время? Не волнуйтесь, mysql уже предоставляет нам такую возможность.
SELECT * FROM table LIMIT [offset,] rows | `rows OFFSET offset `
(LIMIT offset, `length`)
SELECT
*
FROM table
where condition1 = 0
and condition2 = 0
and condition3 = -1
and condition4 = -1
order by id asc
LIMIT 2000 OFFSET 50000Предложение LIMIT можно использовать, чтобы заставить оператор SELECT возвращать указанное количество записей. LIMIT принимает один или два числовых параметра.. Аргумент должен быть целочисленной константой. Если заданы два параметра, первый параметр задает смещение первой возвращенной строки записи, а второй параметр указывает на максимальное количество возвращаемых строк записи. Смещение начальной строки записи равно 0 (не 1): для совместимости с PostgreSQL MySQL также поддерживает синтаксис: LIMIT # OFFSET #.
mysql> SELECT * FROM table LIMIT 5,10; Чтобы получить все строки записи от смещения до конца набора записей, вы можете указать второй параметр -1:
mysql> SELECT * FROM table LIMIT 95,-1; Если указан только один аргумент, это означает, что возвращено максимальное количество строк записи:
mysql> SELECT * FROM table LIMIT 5; В
другими словами, LIMIT n эквивалентен LIMIT 0,n.
Во-вторых, анализ производительности запросов Mysql с разбивкой на страницы.
SQL-оператор MySql с разбивкой на страницы, по сравнению с синтаксисом TOP MSSQL, синтаксис LIMIT в MySQL намного элегантнее. Вполне естественно использовать его для разбиения на страницы.
Самый простой метод пагинации:
SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT ... В случае небольших и средних объемов данных такого SQL достаточно, и единственная проблема, на которую стоит обратить внимание, — это обеспечить использование индекса:
например, если фактический SQL похож на следующий оператор, то лучше построить составной индекс для двух столбцов category_id, id:
SELECT * FROM articles WHERE category_id = 123 ORDER BY id LIMIT 50, 10Как разбить подзапрос на страницы:
По мере увеличения объема данных количество страниц будет увеличиваться, и SQL для следующих нескольких страниц может быть аналогичным:
SELECT * FROM article WHERE category_id = 123 ORDER BY id LIMIT 10000, 10
Короче говоря, чем дальше назад вы просматриваете страницу, тем больше смещение оператора LIMIT и тем медленнее он будет.
В настоящее время мы можем повысить эффективность разбиения на страницы с помощью подзапросов, примерно следующим образом:
SELECT * FROM articles WHERE id >=
(SELECT id FROM articles WHERE category_id = 123 ORDER BY id LIMIT 10000, 1) LIMIT 10 ПРИСОЕДИНЯЙТЕСЬ к режиму разбиения на страницы
SELECT * FROM `content` AS t1
JOIN (SELECT id FROM `content` ORDER BY id desc LIMIT ".($page-1)*$pagesize.", 1) AS t2
WHERE t1.id <= t2.id ORDER BY t1.id desc LIMIT $pagesize; После моих тестов эффективность пейджинга соединения и пейджинга подзапросов в основном находится на одном уровне, и затраченное время в основном одинаково.
объяснить оператор SQL:
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <derived2> system NULL NULL NULL NULL 1
1 PRIMARY t1 range PRIMARY PRIMARY 4 NULL 6264 Using where
2 DERIVED content index NULL PRIMARY 4 NULL 27085 Using index
Почему это? Поскольку запрос выполняется по индексу, а обычный запрос выполняется по файлу данных, в целом файл индекса намного меньше файла данных, поэтому операция будет более эффективной.
На самом деле, вы можете использовать аналогичный шаблон политики для работы с нумерацией страниц, например, решить, что если она находится в пределах 100 страниц, используйте самый простой метод нумерации страниц, а если она больше 100 страниц, используйте метод нумерации страниц подзапросов.
В-третьих, для таблиц mysql с большими объемами данных возникают серьезные проблемы с производительностью при пейджинге USING LIMIT.
Запросить 30 записей из 1000000 после:
SELECT * FROM `cdb_posts` ORDER BY pid LIMIT 1000000 , 30
SELECT * FROM `cdb_posts` WHERE pid >= (SELECT pid FROM
`cdb_posts` ORDER BY pid LIMIT 1000000 , 1) LIMIT 30Потому что вынуть все содержимое поля, первый должен охватывать большое количество блоков данных и выводить их, а второй в основном удаляет соответствующий контент, напрямую позиционируя его в соответствии с полем индекса, и эффективность, естественно, значительно повышается. Оптимизация лимита напрямую не использует лимит, а сначала получает идентификатор предложения, а затем напрямую использует размер лимита для получения данных.
Можно видеть, что чем дальше назад страница, тем больше смещение оператора LIMIT и тем более очевидной будет разница в скорости между ними.
В практических приложениях вы можете использовать аналогичный шаблон политики для работы с разбиением на страницы, например, решить, что если он находится в пределах 100 страниц, используйте самый простой метод разбивки на страницы, а если он больше 100 страниц, используйте метод разбиения на страницы подзапросов.
Идея оптимизации: избегайте сканирования слишком большого количества записей при большом объеме данных.
Чтобы гарантировать, что столбцы индекса индекса непрерывны, вы можете добавить самоинкрементное поле в каждую таблицу и добавить индекс
В-четвертых, запрос на разбивку на страницы, общее количество страниц, как ограничить реализацию
1. Ограничьте пагинацию
ограничить пагинацию: curPage — текущая страница; PageSize — количество записей на странице.
select * from student limit (curPage-1)*pageSize , pageSize;2. Общее количество страниц
(1) Общее количество страниц: totalRecord — общее количество записей; PageSize — сколько записей делится на страницу
int totalPageNum = (totalRecord +pageSize - 1) / pageSize;2) Общее количество запросов: totalRecord — это общее количество записей.
SELECT COUNT(*) FROM courses
Оставьте комментарий