0

これがすでに回答されている場合は申し訳ありません（ある場合は誰かが私にリンクを投げると確信しています）。しばらく前に同じような質問を考えましたが、今は見つかりません。

したがって、質問については、開発中のサイトのユーザー検索を作成しています。検索条件の1つは、検索ユーザーからの距離に基づいています。私はすでに米国の郵便番号とそれに対応する緯度/経度の表を持っています。また、どのジップが基準に適合するかを決定するためのバウンディングボックス（最大緯度/最小緯度-最大長/最小長）を決定する方法も理解しました（正確な半径については心配しません。地理的な正方形当面は十分です）。私の質問-速度を最適化するためにクエリをどのように構成する必要がありますか？するべきか：

  • 必要な計算を実行してバウンディングボックスを決定し、次に郵便番号を照会して潜在的な候補であるすべての郵便番号を見つけ、続いてそれらの郵便番号のいずれかを持つユーザーを検索しますか？

また

  • 緯度/経度の境界ボックスを決定し、zipテーブルをユーザーテーブルと結合して、緯度/経度がパラメーターの間にあるユーザーの結果を返しますか？

2番目の方法の方が速いと思いますが、それを示唆する裏付けとなる証拠/特定の経験はありません。私は回避するのに十分なSQLを知っていますが、それでもまだ少し慣れていないので、さまざまなタイプの操作の相対的なパフォーマンスに関しては何の手がかりもありません。

御時間ありがとうございます！

4

2 に答える 2

2

最終的なクエリは次のようになるはずです。

-- compute @minLat, @maxLat, @minLon, @maxLon

SELECT users.*
FROM users
JOIN locations ON locations.id = users.location
WHERE locations.latitude BETWEEN @minLat AND @maxLat
AND locations.longitude BETWEEN @minLon AND @maxLon

まさにこの場合、すべてが一度に起こるので、私はあなたの懸念を理解できません. 通常、クエリ オプティマイザーは、最初に実行する必要があることを人間よりもよく知っていますJOIN。

郵便番号が範囲内にあるかどうかを判断するためにより複雑な計算を実装したい場合は、最初に郵便番号のリストを作成し、次にこれらの地域に住んでいるユーザーを照合することをお勧めします。

これは、郵便番号が検索範囲内にあるかどうかの計算が、操作の中で最もコストのかかる部分であると想定しています。したがって、可能な限り最小のデータ セット (つまり、郵便番号 + ユーザーではなく、郵便番号のみ) でこの計算を実行することをお勧めします。この場合でも、クエリ オプティマイザーが適切な選択を行うことができる場合があります。

于 2012-06-28T21:35:26.687 に答える
1

あなたが説明する2つのアルゴリズムは、次のように概略的に説明できます。

A INNER JOIN B WHERE A satisfies condition

と

(A WHERE A satisfies condition) INNER JOIN B

前者は単なる結合です (条件は結合条件または WHERE 条件である可能性がありますが、INNER JOIN および MySQL では問題になりません)。

後者にはサブクエリが含まれます。あなたの説明は、サブクエリが最初に計算され、その後に結合が続くと想定しているようですが、一般的にはそうではありません。内部結合が最初に評価され、サブクエリが 2 番目に評価されるため、最初のケースと同じ実行計画が得られる可能性があります。

したがって、これら 2 つのアプローチは、パフォーマンスの観点からは異なるようには見えません。読みやすく維持しやすい方を選択することに集中し、その日が来たら、それをプロファイリングして最適化する必要があります。

于 2012-06-28T21:35:55.283 に答える