現在、私はロケーションベースのアプリケーションを開発しています。主なアプリケーション機能の 1 つは、検索条件に基づいてポイントを配置し、1 つのポイントから指定された範囲内のポイントを配置することです。
明白な選択は、緯度/経度を浮動小数点数または整数として格納することでしたが、MySQL で空間データ型を見つけ、掘り下げ始めました。残念ながら、私が正しい場合、空間インデックスは外部キーをサポートしていない MyISAM でのみサポートされています (これが必要です)。
では、緯度/経度を通常の数値として保存するか、インデックスなしで POINT 型を使用することで、何がより良く (そしてより速く) なるでしょうか?
編集。タイトルの質問に答えるには、要するに、いくつかのハッカーなしではできません (以下を参照)。しかし、今日、MySQL 空間に関する別の質問http://mysqlserverteam.com/innodb-spatial-indexes-in-5-7-4-lab-release/に答えているときに、これに遭遇しました。いつ稼働するかはわかりませんが、それまで待つことができれば、最終的に MySQL の同じエンジンに外部キーと空間インデックスが作成されます。さらに掘り下げると、実際には空間インデックスがMySQL 5.7.5でリリースされることが示唆されています。
あなたの他の質問に関しては、これはテーブルのサイズによって異なりますが、緯度と経度の複合インデックスを浮動小数点数として保存すると、インデックスのないポイントでの完全なテーブルスキャンよりもはるかに優れたパフォーマンスが得られます。正確な数値を教えてください。しかし、前回これを数百万行で試したときは、桁違いでした。
編集:これは元の質問に答えますが、前述のように、ポイントの空間インデックスは緯度/経度の複合インデックスよりもはるかに優れており、MySQL の空間関数を使用できます。ただし、指摘したように、これは MyISAM でのみ機能するため、空間インデックス、ジオメトリ タイプ、および外部キーが一度に必要な場合は、InnoDB がパイプラインにある空間インデックスを追加するまで、スタックします。上記のリンク。
ここに提案があります: https://dba.stackexchange.com/questions/49307/spatial-index-on-an-innodb-table InnoDB と MyISAM の両方で空間データを保持し、MyISAM で空間検索を実行してから共有キーに参加し、InnoDB の属性を照会しますが、これはかなりハックで非効率的であり、2 つのエンジン間の異なるロック動作と、これがどのように大規模に実行されるかについて疑問があります.
InnoDB が最終的に空間インデックスをサポートするのは良い日になるでしょう。何年も待っていました。