現在、私は100k +行のテーブルをいくつか持っています。私は次のようなデータを検索しようとしています。半径の範囲内のポイントのために大きなテーブルを検索する最も速い方法は何ですか？MySQL（緯度経度）
SELECT
*, SQRT(POW(69.1 * (latitude - '49.1044302'), 2) + POW(69.1 * ('-122.801094' - longitude) * COS(latitude/57.3), 2)) AS distance
FROM stops
HAVING distance < 5
ORDER BY distance limit 100
現在のところ、この方法は高負荷では速度が遅くなります。いくつかのクエリは完了までに20秒以上かかります。
これを最適化する方法がわかっていれば、すばらしいことになります。
まず、地理空間データがたくさんある場合は、このような計算ではなく、mysqlの地理空間拡張を使用する必要があります。 create spatial indexesこれは多くのクエリを高速化し、上記のような長い引き出しクエリを書く必要はありません。
ST_Distanceとの比較を使用するか、ST_withinと一緒に関心のある半径を持つジオメトリを作成すると、良い結果が得られ、現在よりもはるかに高速になる可能性があります。しかしこれを達成する最善の方法は、ST_Dwithinはまだmysqlに実装されていません。
空間索引を追加し、空間関数を使用して大まかな一致*を取得し、空間分析関数と共にWHERE句で現在の述語を使用しても*有効です。オプティマイザは、空間索引を使用して、大まかに正しい領域内の候補マッチを見つけ、それをさらに絞り込み、「どこで使用するか」を指定して、非空間述語と一致する行をフィルタリングし、既存のロジックの精度を維持しながらパフォーマンスを向上させることができます。 Spatialは間違いなく進路です。 –
元のクエリの式は、iirc 'ST_Distance'がhaversineではないので、ターゲット位置から距離xのバウンディングボックスを表すポリゴンを計算して返すストアド関数内で書き直すこともできます。 –
空間インデックスは、MySQLのバージョンによって異なります。私たちのサイトはlat/lonsも検索しますが、古いバージョンのMySQL（5.1-something）（空間インデックスなし）を使用しています。あなたの質問は我々のものと似ていますが、私たちはラジアンに基づいています。あなたの正確なニーズに応じて、あなたが持っているものからそれをかなり最適化することができます。ユーザへの実際の距離を表示するときにのみ終了時にそれを計算する - - 確かに、データベースクエリからドロップSQRT（）
少なくともこれが私たちのやり方です。
'49.1044302'は" int "ではありません。 「数字」があります。また、引用符は数値列を比較するときには関係ありません。 –
バウンディングボックス（＃3）は、この答えの中で最も生産的な部分です。あなたは 'INDEX（latitude）'または 'INDEX（longitude）'を持っていると仮定します。 –
Rickが正しくありません。 「浮動小数点数」は「整数」ではありませんが、数値、好ましい整数インデックスの恩恵を受けるには、緯度または経度を掛けて精度を落とす必要があります。また、引用符は重要ですが、あなたが暗示している理由ではありません。スペースが何らかの形でlatまたはlong変数の文字列に変換された場合、 "$ var"はmysqlオプティマイザによって数値にキャストされません。引用符を残すことで、誤ったスペース（おそらくユーザー入力から）がSQL自体のスペースになり、無害になります。 "馬鹿のボタン"を押すのが速すぎないでください。 – Beracah
[_scalable lat/lng searches_]（https://mariadb.com/kb/en/latitudelongitude-indexing/） –
提案されているようにmysqlの地理空間型をチェックアウトしましたか？ – e4c5