さまざまな空間データベースの機能を比較する質問があります。
MySQLとPostgisのどちらを使用する場合でも、可能であれば、緯度と経度の値をジオメトリ/地理（ポイント）として保存し、近くのものを見つけるために使用できる関数として、 ST_Distance 、 ST_Distance_Sphere そして、よりあいまいな<->演算子 、 （使用法など）ジオメトリ/地理列を直接操作します。さらに重要なのは、空間インデックスを追加できることです。 、これらの関数が適切に機能する必要があります。これは、個別にインデックス付けされた緯度と経度の列の検索を大幅に上回ります（これはテーブルのサイズによって異なりますが、テーブルのサイズが大きくなるにつれて大きくなります）。
Postgisでは、latとlonを次のようにジオメトリに変換できます：
alter table mytable add column geom (Geometry, 4326);
update mytable set geom = ST_SetSRID(ST_MakePoint(lon, lat), 4326)
create index ix_spatial_mytable_geom on mytable using gist(geom);
この時点で、上記のリンクの例のいずれかを使用して、他のポイントの近くのポイントを見つけるための非常に効率的なクエリを実行できるようになります。
MySQLでも同様のことができますが、空間参照系、つまりlat / lonを意味する上記の4326はサポートされておらず、ST_MakePoint関数がないため、STGeomFromTextを使用してlat/を連結する必要があります。一緒にポイントを作るためにロン。 Claudioや他の人が述べているように、それは平面座標ですべてを行いますが、これはPostgisの問題ではありません。
長くてやや接線の答えをお詫びしますが、大量のデータ（MySQL、SQL Server、Postgres / GIS）でデータベース間でさまざまな移行を行い、途中で多くの間違いを犯したので、正しい方向（そして、Postigsがスペードで持っている他の空間機能の使用を開始したい場合は、将来の校正を少し追加してください）。