Кто работал c ними, мускул с каких вообще размеров таблиц начинает оптимайзером дёргать индекс на spatial-поле? В таблице ~40к записей, и spatial-index на тип Point. И при стандартной задаче нахождения точек внутри многогранника не хочет эта волшебная субд дёргать индекс. Верить ему, что мол записей мало и потому дольше будет индекс в память считывать чем без него все строки таблицы проверять? Код (Text): EXPLAIN SELECT id, AsText(geopoint) FROM tbl_name WHERE contains(GeomFromText('Polygon((40 40, 60 40, 60 60, 40 60, 40 40))'),geopoint); select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE tbl_name ALL geopoint NULL NULL NULL 35891 Using where На force index строк 18000, хотя в результатах их ~500... .
Интересно. В версиях младше 5.6.1 функции заявленные в OpenGIS-спецификации (работа с геоданными, индексами R-tree и проч.) в Mysql реализованы не верно или ограниченно, если говорить корректнее. Это в частности выражается в том, что функции CONTAINS или WITHIN могут возвращать координаты объектов которые ниразу не "contains" и не "within" относительно искомого геообъекта. Это связано с тем, что мускул этими функциями ищет не в границах передаваемых координат (к примеру треугольника), а в границах ограничиваеющего этот объект прямоугольника (bounding box). Чтобы в выборку перестали попадать объекты никак не относящиеся к искомой области придётся обновить субд до версии 5.6.1 или выше и использовать функции с прификсом ST_ . ST_CONTAINS в частности. Возможно кому-то окажется полезным и сэкономите время на изучении документации.
Поработав плотно определённое время с геоданными, могу добавить к топику, что если стоит выбор системы управления реляционной бд, как хранилища этих данных, то лучше начинать с PostgreSQL (с расширением PostGIS, особенно если приложение строится на стандартах OpenGIS). Велика вероятность, что на этой субд и остановитесь. Обладателям лицензии на Oracle c расширениями Oracle Locator и Oracle Spatial будет ещё приятнее ибо с вероятностью 99% все необходимые вам функции для работы с данными уже реализованы в расширениях. Минус этого выбора только в платности. Марию или Мускул стоит выбирать только в том случае если ваши сборки поддерживают необходимые вам функции для работы с данными (поэтому читаем документацию и проверяем в боевых условиях). К самим типам данных к мускулу претензий нет: все необходимые поддерживаются.