MySQL Spatial vs PostGIS：空間數據庫擴展深度對比與選型指南

核心能力對比表

關鍵差異圖解

多邊形包含查詢：
MySQL 僅能以紅色最小外包矩形（MBR）近似判斷，會誤把藍色多邊形外但落在 MBR 內的點誤判為包含。
PostGIS 能精確計算點與任意多邊形的拓撲關係。

距離計算：
MySQL 僅能算歐幾里得平面距離。
PostGIS 可在任意投影坐標系下計算真實大地測量距離（如 WGS84 經緯度下的測地線距離）。

選型決策建議

選擇 MySQL Spatial 的場景

• 已有 MySQL 技術棧，團隊無 PostgreSQL 經驗，遷移成本高。
• 業務極簡單：僅需「經緯度範圍查詢」、「附近 N 公里 POI 搜尋」（精度要求不高）。
• 數據量中小、寫入頻率高、讀多寫少、可容忍 MBR 近似誤差。
• 不涉及三維、投影轉換、複雜拓撲分析。

選擇 PostGIS 的場景

• 專業 GIS/LBS 業務：地圖渲染、路網分析、空間統計、幾何處理。
• 需精確多邊形包含、相交、緩衝區、疊加分析等 OGC 標準操作。
• 涉及多坐標系數據融合、投影轉換、大地測量計算。
• 需要事務保證空間編輯工作流的一致性（如圖層編輯、版本管理）。
• 團隊願意投入 PostgreSQL 學習曲線，換取長期擴展性。

遷移路徑參考

1. 數據導出：ogr2ogr -f "PostgreSQL" PG:"dbname=gis" "MySQL:dbname=old"（GDAL/OGR 支援雙向遷移）。
2. SQL 改寫：MySQL MBRContains → PostGIS ST_Contains；MBRWithin → ST_Within；Distance → ST_Distance（注意單位：度 vs 米）。
3. 索引重建：PostGIS 建議 CREATE INDEX idx_geom ON tbl USING GIST(geom)。
4. 應用層適配：連接池、ORM（Hibernate Spatial、GeoDjango、SQLAlchemy-GeoAlchemy2 等均原生支援 PostGIS）。

總結

簡單 LBS/POI 查詢 → MySQL Spatial 足夠；
專業 GIS/空間分析/多坐標系/事務需求 → PostGIS 無可替代。