По второму немного не так опять же)
Но первый можно объединить с другим запросом в эту же таблицу, но хочется более быстрый вариант в плане скорости...
MrTNTminer, На крайняк "перелей" в новую таблицу с trim в PHP...костылёк...но если это всего лишь раз сделать и дальше пользоваться новой таблицей + новые поступающие данные обрабатывать на входе по одному принципу, то, чем не вариант...чем несколько часов биться с такой проблемой...=)
И как выше писали...возможно одинаковые русские буквы с английскими перепутаны в данных...их тоже можно "пофиксить" заодно, если использовать костыль выше...
Допустим так:
При масштабе 10 (условно) - группируй рядом лежащие точки в радиусе X (условно), как одну точку...и показывай вместо названия этой точки просто кол-во точек в ней...
При более близком масштабе начинай уменьшать радиус группировки X...
karpo518, Из вашего вопроса я думал, что LIKE не подходит... Не потому что с его помощью сделать нельзя, а потому что медленно (в таком варианте он не использует индексы) + зачем то Вы припрели MATCH, что ещё раз меня убедило про ненужность LIKE...А то, что "AND" Вам сделал погоду... Тут я улыбнулся :) Я и в своём примере "AND" не указал, т.к. это было само собой разумеющееся... Извиняйте :)
P.S.: LOCATE тоже индексы не любит...
P.S.S.: Добавил в пример "AND"... :)
Забудьте большую часть низкоуровневых конструкций сокетов и забот. Думайте выше в небе. ZeroMQ представляет собой концепцию обмена сообщениями более высокого уровня. Таким образом, у вас возникнут проблемы с большинством проблем сокета-io.
Подробнее об этих принципах ZMQ читайте в стилях дизайна Pieter Hintjens и его богатой ресурсами книге "Code Connected, Vol.1".
Тем не менее, решение полностью находится под вашим контролем.
Решение
Создайте специфический для задачи multi-zmq-socket/multi-zmq-pattern (несколько zmq-примитивов, используемых и организованных вашей логикой уровня приложения) как формальное коммуникационное общение с конкретной задачей.
Убедитесь, что добавляет его PID в сообщение.
Повторите/авторизуйте через другой регистр/auth-socket-шаблон с предварительно зарегистрированным sender со стороны receiver, чтобы избежать поддельной атаки под фальшивым/украденным PID -идентивом.
Адаптируйте свою политику контроля доступа в соответствии с вашими проблемами, используйте и внедрите любой уровень формальных протоколов квитирования безопасности для проверки подлинности или обмена ключами, чтобы повысить безопасность вашей политики контроля доступа до достаточных сильных сторон (включая MIL- STD).
Есть у кого какие опыты более менее с примерами по современному?)
Как поведёт себя при миллионах записях позже буду тестить.
Спасибо за вариант :)
Если есть ещё мысли - напишите)
Если например этот же запрос переписать с использованием JOIN вместо EXISTS...есть опыт: что будет быстрее?