Comments 15
Вы что прикалываетесь 0,15 секунд искать IP юзера? :)
Вот советую почитать, зря вы убрали вложенный запрос, оно то хоть и выглядит сложнее, но работает намного быстрее. Ну и по сравнению с бинарными базами Maxmind или Sypex Geo MySQL слишком медленный.
Кроме того у Вас база мягко говоря не оптимальная.
Зачем для IP использовать тип BIGINT? Чтобы таблицы и индексы были в 2 раза больше? Или зачем INT для индекса стран и городов?
Вот советую почитать, зря вы убрали вложенный запрос, оно то хоть и выглядит сложнее, но работает намного быстрее. Ну и по сравнению с бинарными базами Maxmind или Sypex Geo MySQL слишком медленный.
Кроме того у Вас база мягко говоря не оптимальная.
Зачем для IP использовать тип BIGINT? Чтобы таблицы и индексы были в 2 раза больше? Или зачем INT для индекса стран и городов?
Выше я описал, что использую не собственную базу. А из статьи habrahabr.ru/post/193024/. Спасибо за ссылки, обязательно посмотрю)
Просто в таком случае вообще непонятно, чему вы хотели научить новичков. Структура таблиц далеко не оптимальна (не обращаете внимание на важность выбора типов данных, особенно для индексируемых полей), никакого разбора запросов с помощью EXPLAIN, запросы меняете, чтобы они были «читабельнее и короче», а не чтобы быстрее работали.
Что бы научить новичка оптимизировать запросы, ему нужно объяснить, что такое индексы, как они подхватываются при разных запросах и научить пользоваться командой EXPLAIN. А то, что вы описали, бесполезно для новичка.
А зачем вы в примерах кода на PHP используете mysql_* функции? Они давно уже deprecated.
> Данная Geo-IP база очень старая
В базе данных есть скрипт обновления. Можете обновлять хоть каждый день.
> Избавимся от подзапроса
Можете объяснить логику такого решения?
Скажу честно. я офигел. В статье «Оптимизация SQL запроса» нет ни слова про EXPLAIN. Вместо 4 быстрых запросов сделан 1 медленный. Зачем, какой в этом смысл?
В базе данных есть скрипт обновления. Можете обновлять хоть каждый день.
> Избавимся от подзапроса
Можете объяснить логику такого решения?
Скажу честно. я офигел. В статье «Оптимизация SQL запроса» нет ни слова про EXPLAIN. Вместо 4 быстрых запросов сделан 1 медленный. Зачем, какой в этом смысл?
В базе данных есть скрипт обновления. Можете обновлять хоть каждый день.
Согласен, архив net_update не смотрел.
Можете объяснить логику такого решения?
В моей задаче нужно было определить город и страну одновременно. Если города не определён нет, то и выводить страну мне, по задаче, не нужно. И да, это я забыл написать в статье.
Я замерял скорость выполнения PHP + SQL примера из example.php. Скорость выполнения примерно ~0.2997 ms (средне арифметически). С данным запросом, в статье он обозначен #8, код выполняется за ~0.1713 ms (средне арифметически) на моей машине, на VPS сервере разница более мелкая, но ощутимая.
В статье «Оптимизация SQL запроса» нет ни слова про EXPLAIN.
EXPLAIN сначала планировал добавить. Но потом просто не было времени подготовить материал. Возможно, если будет время, я опишу принципы анализа и оптимизации SQL запроса с реальными примерами из кода и добавлю в статью или напишу новую.
Спасибо за критику. Первая статья и не все описал подробно и доходчиво. В будущем планирую исправляться и делать более полные статьи.
Тайминг — миллисекунды или все же секунды? ~0.1713 ms и ~0.1713 s совсем разные вещи. На скринах у вас, как я понимаю, все же секунды.
> В моей задаче нужно было определить город и страну одновременно
Вы не разобрались, зачем нужен подзапрос. Попробуйте разобраться сейчас. Сделайте EXPLAIN для моего запроса и для вашего запроса.
Вы не разобрались, зачем нужен подзапрос. Попробуйте разобраться сейчас. Сделайте EXPLAIN для моего запроса и для вашего запроса.
А можете мне объяснить зачем вообще хранить IP пользователя или его страну/город в базе? Берете тот же самый sypex geo или GeoIP maxmind и налету определяете по его IP его город или страну. Зачем вообще использовать базу там где это не нужно? По поводу explain то же верно, наугад делать оптимизацию запросов это как минимум странно, а если это не указывать в статье то как новичок вообще поймет как вы оптимизировали запрос? Это уже не говоря о том что можно вообще использовать nginx + geoip
Самое интересное в данной задаче то, что нельзя просто так взять и построить индекс для быстрой выборки по двум столбцам, которые являются границами диапазона.
Если мы делаем индекс по (begin_ip, end_ip), то при запросе BETWEEN сперва поиском по дереву индекса найдется первая строка, у которой begin_ip >= LONG_IP_ADDRESS. А затем начнется последовательное сканирование всех последующих строк с проверкой end_ip <= LONG_IP_ADDRESS. И это медленно.
Если мы делаем индекс по (begin_ip, end_ip), то при запросе BETWEEN сперва поиском по дереву индекса найдется первая строка, у которой begin_ip >= LONG_IP_ADDRESS. А затем начнется последовательное сканирование всех последующих строк с проверкой end_ip <= LONG_IP_ADDRESS. И это медленно.
Sign up to leave a comment.
IP-Geo. Оптимизация SQL запроса