Привет, коллеги!
Кидаю запрос:
SELECT * FROM product LIMIT 10000
- выполняется 0.02с
SELECT * FROM product WHERE product_id > 0 LIMIT 10000
- 0.16c
Как это так-то!? При том что product_id - PK AI. Ожидалось как минимум такое же время выполнения.
Есть у кого-нибудь возможность чекнуть подобные два запроса на более или менее большой БД? Чего по времени получится?
PrimaryKey негативный тоже может быть.
Сравнивается все значение ключа с условием > 0,после этого все складывается в таблицу отдельную с лимитом.
Я протестировал на 3000000 строчек и разници не заметил без использования кэша
T1grOK
23.09.2016 - 14:43
Вполне возможно такое поведение.
В первом случае, вполне возможно, дисковых операций гораздо меньше, в последнем же случае сначала пробежим по индексу, а потом по каждому id начнем читать данные с диска.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
S.Chushkin
23.09.2016 - 15:59
Цитата (Ron @ 23.09.2016 - 14:12) |
Есть у кого-нибудь возможность чекнуть подобные два запроса на более или менее большой БД? Чего по времени получится? |
mySQL, ~10 млн. записей, размер таблицы с индексами ~2Г
Вариант 1:
10000 row(s) returned
Execution Time : 0.002 sec
Transfer Time : 0.058 sec
Total Time : 0.060 sec
Вариант 2:
10000 row(s) returned
Execution Time : 0.002 sec
Transfer Time : 0.055 sec
Total Time : 0.058 sec
Одинаково. Т.е. в пределах стат.погрешности. Хотя запросы выполняются немного по разному.
В общем, хочешь конкретной помощи, показывай структуру таблицы и результаты EXPLAIN.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
sergeiss
23.09.2016 - 16:35
Цитата (Ron @ 23.09.2016 - 14:12) |
Ожидалось как минимум такое же время выполнения. |
С чего бы вдруг одинаковое? Во втором случае проверка делается для каждой строки, а на это нужно сколько-то времени.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
S.Chushkin
23.09.2016 - 16:46
Цитата (sergeiss @ 23.09.2016 - 16:35) |
Во втором случае проверка делается для каждой строки, а на это нужно сколько-то времени. |
Ничтожно малое, - много меньше флуктуации общего времени. В данном случае.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
Valick
23.09.2016 - 16:52
Цитата (sergeiss @ 23.09.2016 - 15:35) |
Во втором случае проверка делается для каждой строки |
T1grOK
23.09.2016 - 17:00
Цитата (Valick @ 23.09.2016 - 12:52) |
нет, там индекс |
Индекс тоже нужно обойти, к тому же индекс тоже читается с диска, и как правило не весь сразу а поблочно(кроме тех случаев когда он уже находится в памяти, объем которой позволяет спокойно там жить индексу).
При большом размере результата, во многих случаях, выборка без индекса будет работать быстрее, т-к вытаскиваются все данные, а по индексу тащатся отдельные записи насилуя дисковую подсистему
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
T1grOK
23.09.2016 - 17:10
Цитата (S.Chushkin @ 23.09.2016 - 11:59) |
Вариант 1: 10000 row(s) returned
Execution Time : 0.002 sec Transfer Time : 0.058 sec Total Time : 0.060 sec
Вариант 2: 10000 row(s) returned
Execution Time : 0.002 sec Transfer Time : 0.055 sec Total Time : 0.058 sec |
Похоже на результат с SSD или высокоскоростными "вениками"
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
S.Chushkin
23.09.2016 - 18:11
Цитата (T1grOK @ 23.09.2016 - 17:10) |
Похоже на результат с SSD или высокоскоростными "вениками" |
Нет, обычный двиг. Даже хуже - версия 5.6 под виндой.
Другое дело, что движок нормально настроен. И, естественно, искомая инфа в буфере, как и положено. Поэтому не важно SSD, HD или перфокарты, - мы же не диск тестируем, а запрос.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
Oyeme, S.Chushkin спасибо, за результаты запроса!
Цитата (sergeiss @ 23.09.2016 - 16:35) |
С чего бы вдруг одинаковое? Во втором случае проверка делается для каждой строки, а на это нужно сколько-то времени. |
Я мыслил следующим образом. MySQL найдет почти мгновенно стартовый product_id, поскольку он PK и начнет набирать с этого места указанное кол-во строк.
Цитата (S.Chushkin @ 23.09.2016 - 15:59) |
В общем, хочешь конкретной помощи, показывай структуру таблицы и результаты EXPLAIN. |
Так а чего там структуру, самая простая, PK AI и еще несколько полей. Как остальные поля могут повлиять, по ним условий никаких?
Цитата (T1grOK @ 23.09.2016 - 17:00) |
При большом размере результата, во многих случаях, выборка без индекса будет работать быстрее, т-к вытаскиваются все данные, а по индексу тащатся отдельные записи насилуя дисковую подсистему |
Получается что так, потому что LIMIT 100 дает мгновенный результат. Значит дело не в способе поиска, а именно в механизме набора данных, то есть в диске, в конечном счете. Но у меня же SSD!
S.Chushkin
24.09.2016 - 17:06
Цитата (Ron @ 24.09.2016 - 04:25) |
Значит дело не в способе поиска, а именно в механизме набора данных, то есть в диске, в конечном счете. |
По правильному, надо сделать 2-3 попытки, чтобы данные попали в буфер.
Иначе, действительно будешь мерить не скорость запроса, а скорость чтения с диска.
SSD тоже медленнее, чем RAM, на порядок. Хотя и быстрее обычного HD на порядок.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
S.Chushkin
24.09.2016 - 17:23
Цитата (Ron @ 24.09.2016 - 04:25) |
Так а чего там ... |
Нормально. У меня такой же Explain.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
S.Chushkin, спасибо!
И всем откликнувшимся спасибо! )
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.