地理空間データのテーブル構造

ジオメトリデータ型 として保存します 。 MySQLは、Geometry（generic）、およびPoint、Linestring、Polygonデータ型をサポートしています。空間データ型の作成 。スクリーンショットにあるように、単一の経度または緯度の値をそれ自体でジオメトリにすることはできません。

ジオメトリタイプを使用するルートを使用する場合、緯度と経度のフィールドを個別に設定するよりも2つの利点があります。空間インデックス また、MySQLの空間の一部を使用できるようになります。演算子関数 さらに分析を行うためのST_Buffer、ST_Intersects、ST_Distanceなど。空間インデックスはRツリーに基づいており、緯度と経度の非空間列で2つのBツリーインデックスよりもはるかに優れたパフォーマンスを発揮します。このパフォーマンスの違いは、テーブルのサイズが大きくなるにつれて大きくなります。

XおよびYポイント関数 したがって、データをポイントとして保存しても何も失われません。

すでに2つの別々のlat/lon列にデータがあり、ジオメトリ/ポイントデータ型ルートに移動する場合は、Point関数を使用してPointデータ型を作成できます。

alter table mytable add column pt POINT;
update mytable set pt=Point(longitude, latitude);
alter table mytable modify pt POINT NOT NULL;
create spatial index ix_spatial_mytable_pt ON mytable(pt);

Point関数はMySQL5.1.xでのみ導入されたことに注意してください（十分に文書化されていないため、正確なバージョンはわかりません）。その前に、GeomFromText関数でconcatを使用する必要がありました。 lat/lonテキスト列を「ポイント」タイプの列 これに関するいくつかの詳細については、Quassnoiの答えにはlonとlatが間違った方向にあることに注意してください。これは非常に一般的な間違いですが、Point（lon、lat）です。

注： 最近まで、MyISAMエンジンを使用している場合にのみ、空間列にインデックスを付けることができました。

編集： 今後のリリースでは、 MySQL 5.7 .5 、InnoDBは、最終的に空間データ型のインデックスをサポートします（インデックスなしで空間型を格納するだけでなく、かなり有用性が低くなります）。これは、外部キー、ACID保証、空間インデックスをすべて1つのエンジンに含めることができることを意味します。これは、長い間待ち望まれていました。