2012-02-14 14 views
1

私は1つのレコードを対象にして、そのレコードを取得し、その両側にさまざまな量のレコードを戻したいと考えています。ターゲットレコードとその周辺のnレコードを1つのクエリで取得していますか?

たとえば、2356のキーIDがあるとします。したがって、2356と2356の前後に3つのレコードがあり、注文はcreate_ts(たとえば)である必要があります。

これを1つのクエリ(mysql)で行う方法があるのでしょうか?

+0

このレコードはどういう意味ですか?いくつかのダミーレコードとあなたの希望する出力を投稿できますか?あなたのテーブルのスキーマ。ありがとう.. –

答えて

2

の表は、(mytableはそれを呼び出す)あなたは明らかに2つの必要なキーをピックアップするクエリーを必要create_tsとid

ALTER TABLE mytable ADD INDEX create_ts_id_index (create_ts,id); 

に複合インデックスを持たなければなりません。

これは7 idsです。

このクエリは、最大4つのキー(ID + 3後)

SELECT create_ts,id FROM mytable WHERE id >= 2356 ORDER BY create_ts LIMIT 4; 

このクエリは、最大4つのキー(前ID + 3)の2つのクエリの

SELECT create_ts,id FROM mytable WHERE id < 2356 ORDER BY create_ts DESC LIMIT 4; 

A UNIONをピックアップが排除すべきである選びますID 2356

の重複はのは、これらを組み合わせて、INNERが

をMYTABLEすることでJOINを実行してみましょう

サブクエリAには7つのキーしか含める必要がありません。これらの7つのキーが取得されると、INNER JOINはすばやくなります。

このクエリの前にN個のキーとN個のキーが必要な場合は、いつでもLIMIT N+1を使用してください。

私は、3つのキーbackがid-3であると仮定することができず、3つのキーがid + 3であると仮定できないので、この方法を提案します。これは、何らかの理由で表にIDにギャップがある場合に特に当てはまります。

試してみてください!

警告:私はそれを試していませんでした。これはあなたがアルゴリズム的にしたいものです。 MySQLの構文はそれを可能にするかどうかはしません。構文が正しくない、私は例を構築し、構文を修正しようとします。

場合によっては、より安定したアプローチがあります。

CREATE TABLE create_ts_ids SELECT create_ts,id FROM mytable WHERE 1=2; 
ALTER TABLE create_ts_ids ADD PRIMARY KEY (id); 
INSERT INTO create_ts_ids 
SELECT create_ts,id FROM mytable 
WHERE id >= 2356 ORDER BY create_ts LIMIT 4; 
INSERT IGNORE INTO create_ts_ids 
SELECT create_ts,id FROM mytable 
WHERE id <= 2356 ORDER BY create_ts DESC LIMIT 4; 
SELECT B.* FROM create_ts_ids A 
INNER JOIN mytable B USING (create_ts,id) 
ORDER BY A.create_ts,A.id; 
+0

ありがとうございます。私はこれを試して、戻ってきます。 – Spot

+0

これは正常に機能します(構文)。ただし、出力は最初にターゲットレコード、次に_after_レコード、_before_レコードです。同様に(_432_がターゲットです):432,482,483,484,222,221,161(_before_リストの順序にも注意してください)。どうすればこの問題を解決できますか? – Spot

+0

答えを更新しました。私は 'ORDER BY A.create_ts、A.id'を追加しました。その注文が正しくない場合は、単に「ORDER BY A.id」を試してください。 – RolandoMySQLDBA

-1

選択のためのあなたの基準は単純にIDの場合:

SELECT * 
FROM table 
WHERE key_id <= target_id + 3 
AND key_id >= target_id - 3 
ORDER BY create_ts; 

は、対象レコードの周りに必要なレコード数に3を交換してください。 IDの前に3、ID自体、3 IDの後:

+0

連続した積分列がある場合にのみ動作します。 –

+0

ここでは、key_idがプライマリオートインクリメントキーであると仮定しています。しかし、@Rolandoは、OPがより正確に望んでいたことを推測したようです。 :) – JYelton

+0

IDが一意であることだけが保証されているので、正しいです。とにかく注文が正しいという保証はありません。それでなぜORDER BY id ASCも完全に間違っています。一部の日時列でソートすると、信頼できる正しい結果が得られます。 –

関連する問題