xmoonlight: нет. Проблемы поиска "до конца налево, до конца на право" я описан в начале топика. По сути требуется найти максимальное левое значение (BigMin) и минимальное правое (LitMax). Только нет такой команды :(
Fadmin: В 100 раз быстрее, но поддержка, масштабируемость, синхронизация, да просто потребление памяти - в переспективе не радуют. Как я говорил чуть ниже - у меня не IPшники - у меня просто диапазоны. Алгоритмически одного и тоже, просто данных больше.
В начале я хочу понять почему ваш вариант быстрее. Во вторых я хочу чтобы скорость приблизилась к самописным вариантам деревья, дитохомию, подсчет интервалось и тд.
Напрягает как-то что (если у нас есть таблица "точек") найти все точки во всех интервалах (потому что закрытые) чуть ли не быстрее чем найти интервал одной заданной точки.
Fadmin: конечно. В том числе проверил как на одиночном двойном, так и отдельных на начало и конец. Время работы получается в районе 0.001(минимальные ipfrom) - 0.01(максимальные ipfrom), и, к сожалению, четко зависит от позиции запроса. Те fullscan таблицы в любом случае.
Совет на удивление работает, только не совсем понимаю почему
SELECT * FROM `ipgeobase_ip` AS ip1 INNER JOIN ipgeobase_ip AS ip2 ON ip1.id = ip2.id WHERE ip1.ipfrom <3653624834 AND ip2.ipto >3653624833
В 10-100 раз быстрее чем
SELECT * FROM `ipgeobase_ip` as ip1 WHERE ip1.ipfrom<3653624834 and ip1.ipto>3653624833
Хотя первая строчка EXPLAIN у обоих одинаковая - скан всех записей до начала таблицы
FanatPHP: в отличие от Чистякова я активнее использую MySQL. И два ключа "конкатенировать" невозможно - просто попробуйте представить эту операцию. Это дерево первого ключа, которое "продолжается" деревом второго (точнее узкой нужной выборкой).
Именно по этому вторая часть не доступна без обхода первой.
Именно по этому не бывает эффективных ключей X,Y и им пришлось придумывать spatial решения и другие UB варианты.
Основной индекс снимать не надо, так как он, по правилам игры, обеспечивает уникальность ключа. Но, так как сам по себе никому не нужен - почему бы ему не побыть частью составного.
А составной - это по сути 1D ключ, где поиск в начале происходит по первой части, а потом по второй. В данном случае первая часть, по природе своей, очень быстро "сходится", а вторая содержит одну или больше записей.
PS: Я уже все понял про ваше воспитание, ведете себя как (анонимный) гопник. Жаль что мы не представлены.
Я уже понял кто из нас кто. Если не верите в локальность данных и ветвление (1 и 4 пункт) и опыта не хватает, чтобы хотя бы знать (а не понимать почему) - www.slideshare.net/alexclear/c-35881279 (29-30 слайд).
PS: ТС - не слушайте фанатика, он не конструктивен.
FanatPHP: в начале оцените размер дивана, а потом запас умных слов. Вынос части логики в хранимки - панацея в таких задачах, это в миллион раз лучше чем переносить логику на клиент. В противном случае хорошим вариантом будут асинхронные мульти-квери.
Быть можете поправите?
Дмитрий Энтелис: в систему "адресации" NS входят также хэши по Morton или Hilbert кодам, те geospatial задачки. При желании и мапинг IP можно представить в виде вложенных отрезков. В общем можно придумать мильен задач, где выборка по интервалу будет удобна, и будет работать сильно быстрее других вариантов.
Обычные AS тут вообще не подойдут, а CS резко деградирует при увеличении глубины дерева.
