Выборка int>=int1 AND int<=int2 не подхватывает ключ

Pin

Новичок
Выборка int>=int1 AND int<=int2 не подхватывает ключ

Здравствуйте.

Не подскажите, как использовать индексы при выборке по числу в промежутке составного индекса (int1,int2)?

Есть хороший геотаргетинг от maxmind.com , в т.ч. free-версии. Получается, если заносить в одну таблицу ip посетителей сайта (ip=inet_aton, конечно), то потом можно получить город или страну с использованием таблиц типа

ip1 int unsigned,
ip2 int unsigned,
geo_name varchar(64),
primary key (ip1,ip2)

Естественно, записей посещений может быть достаточно много, а таблицы по странам у них по 70-80к.

Запрос типа
SELECT countryes.name, COUNT(*) AS amnt FROM all_my_ips LEFT JOIN countryes ON (ip >= ip1 && ip <= ip2) GROUP BY countryes.name

не хочет использовать индекс, пишет его только в possible_keys. Естественно, результат ждать приходится оочень долго.

JOIN на условии ip=ip1, естественно, использует индекс и проходит в момент.
Как использовать индекс с соблюдением полного условния?
 

voituk

прозревший
Можешь попробовать FORCE INDEX (`index_name`)
Также можешь попробовать добавить индекс по полю `ip2`, хотя это только догадка - вроде должно хватить primary.
 

Pin

Новичок
он по-прежнему светит его только в possible_keys, explain меняет только IGNORE INDEX :)....
 

voituk

прозревший
Не верю (с)
Что-то ты недоговариваешь!

Утром прийду на работу - проверю.
 

Popoff

popoff.donetsk.ua
не хочет использовать индекс, пишет его только в possible_keys.
это означает, что если заставить его использовать индексы насильно, то результат придётся ждать дольше, чем
поскольку, я так понимаю, ip1 - уникальное поле, то ip2 в этом индексе излишен и никогда не будет использован.
SELECT countryes.name, COUNT(*) AS amnt FROM all_my_ips LEFT JOIN countryes ON (ip >= ip1 && ip <= ip2) GROUP BY countryes.name
Странный какой-то запрос. Что вы хотели с его помощью получить?

-~{}~ 30.01.07 22:50:

А, подождите. Понял, что делает запрос %)

SELECT countryes.name, COUNT(*) AS amnt FROM all_my_ips LEFT JOIN countryes ON (ip >= ip1 && ip <= ip2) GROUP BY countryes.name
в такой конструкции для каждой строки из первой таблицы будет производиться выбор строк из второй таблицы, причём, поскольку реальная возможность есть использовать в индексе только индексацию по полю ip1, то максимум, что Вы сможете добиться от индекса - это чтобы реально для каждой строки первой таблицы просмотривались все строки, у которых ip >= ip1. а во многих случаях это может быть больше, чем полтаблицы. думаю, именно из-за этого мускл блокирует индексы - так как одно дело перебрать всю таблицу по порядку (как записано на диске), совсем другое - перелопатить эту же практически всю таблицу, но в случайном порядке (то есть, отсортировано в порядке индекса, но случайную с точки зрения записи на диск).

предлагаю хранить в all_my_ips значение соответствующего поля countryes.name.
 

hermit_refined

Отшельник
угу, этот запрос никак не вытянуть.
о том, как вытянуть нормальный запрос (по одному ip) - в поиске по (ни за что ведь не догадаться!) - "определение страны по ip".
 

Pin

Новичок
Странно, если индекс уникален, то зачем ему молотить всю таблицу... Нашел нужное значение и прекратил поиск по данному ip.
А получается так, что он все равно смотрит ее до конца и только потом приступает к следующему.

Разделение индексов на два уникальных - лучше, но используется только первый индекс...
 

hermit_refined

Отшельник
Нашел нужное значение и прекратил поиск по данному ip.
а откуда бд, например, знает что одному ip соответствует один диапазон? не фантазируйте.
если вы не поняли, повторю за Popoff:
предлагаю хранить в all_my_ips значение соответствующего поля countryes.name.
 

Pin

Новичок
.hermit_refined
Чего тут фантизировать - 1 адрес попадает только в 1 диапазон. Иначе при нахождении в >=2 диапазонах он может быть и в стольких городах и странах одновременно.

Создавать запись сразу с определением страны / города - получается, пришел пользователь - ему сразу определять по 1 таблице страну, по другой - город... на реальном потоке как-то расточительно относительно системных ресурсов...
Друго дело, можно использовать доп. таблицу и заносить данные для новых пользователей ночью, а днем уже выводить отчеты из обработанных данных... Наиболее подходящий вариант, если не решится проблема индексов...

phprus
Весь api (и не только для С) направлен на обработку единичного ip и выдачу готового результата по одной из таблиц - страна, город и т.д. То есть никакой групповой обработки одним запросом там не предлагается.

-~{}~ 01.02.07 16:46:

Есть еще 1 обсуждение за западном форуме... тем та же.
http://forums.mysql.com/read.php?24,8775,8775#msg-8775
 

nail

Новичок
val>=field1 AND val<=field2: btree индекс (составной) тут неприменим.
Поищите и почитайте в интернете алгоритм btree (balanced tree), тогда будет понятно почему.
 
Сверху