これは他の多くの人が投稿した問題のように聞こえますが、理解できないニュアンスがあります。最も近いXデータポイントを要求するときに境界を制限したくないので、クエリを高速にする必要があります。 。
現在、SQLを次のように使用しています。
SELECT * FROM myTable WHERE col1 = 'String' AND col2 = 1
ORDER BY (latCol - <suppliedLat>) + (longCol - <suppliedLong>)
LIMIT X; //X is usually lower than 100
LatとLongがdoubleとして格納され、テーブルに約100万行が含まれている場合、このクエリはサーバー上で最大6秒かかりますが、十分な速度ではありません。EXPLAIN SELECTは、インデックスを使用しておらず(予想どおり、インデックスは1つだけで、場所に関連していません)、ファイルソートを実行し、最大100万行すべてにヒットしていることを示しています。
2つのWHERE句を削除してもパフォーマンスはまったく向上しません。また、col1、col2、および3番目のcolに適用した1つのインデックスは、他の句の速度を大幅に向上させたにもかかわらず、実際にはこのクエリのパフォーマンスを低下させました。
これを解決する方法を読んだことで、空間インデックスが進むべき道であると信じるようになりましたが、ポリゴンや円形境界などのより高度な空間機能を使用するつもりはなく、速度が必要です。上記のクエリの速度を向上させるために、既存の小数度テーブルに空間(または他の種類の)インデックスを適用する簡単な方法はありますか?クエリをより効率的にするためのより良い方法はありますか?
大きなキラーは、MySQLでの空間インデックスの実装について読んだほとんどのことは、データのINSERT方法を変更する必要があるようですが、地理/空間データ型を使用するようにINSERTステートメントを変更すると、開発サイクルが大幅に増加することです。