原因の対処：

まずは簡単に前回のおさらいをしましょう。

test_table の id 列が sortkey=0 となっていることから、
id 列には現在ソートキーが存在しないことが分かりました。

【現時点の対象テーブルのソートキー有無（再掲）】

という訳で、早速 ソートキー を実際に作成してみて、
本当に性能が改善されるのか見ていきましょう！

ALTER TABLE test_table ALTER SORTKEY ("id");

　　【構文参考】ALTER TABLE – Amazon Redshift

　　※本番環境でソートキーを作成する際はご注意ください！
　　　該当テーブルに関連するクエリ性能への影響が出るため、事前にテストを行うことを推奨します。

　　　また、Redshift 上では多少の負荷や対象テーブルに対するロックが発生することが想定されます。
　　　そのため、一般ユーザーが利用する時間帯に実施することは避けた方が無難でしょう。

↑のコマンドを実行しましたら、ソートキーが追加されたか確認してみます。


SELECT tablename, "column", type, encoding, distkey, sortkey
FROM pg_table_def
WHERE tablename = 'test_table'; -- クエリプランで確認したテーブル名を指定


sortkey 列の値（前回：0）が 1 に変わったことが確認できたので、
ちゃ～んと id 列にソートキーが作成できたようです！

「対処やったから、これでおしまい（きっと改善されたでしょう）」ではありませんよ！
ちゃんと結果まで確認するのが、プロってもんです！知らんけど。

改めて、問題が発生したクエリ（select * from test_table where id =1 limit 100）を実行し、
性能が改善されているか、ちゃんと見てみましょう。

select * from test_table where id =1 limit 100;

→ Elapsed time: 7ms（クエリエディターの画面右下に表示）

一瞬にして、結果が返ってきました！
事象発生時は 6秒 程度でしたが、ソートキー作成後はなんと 7ミリ秒 に！！
（計算は苦手ですが、ざっと 800倍 以上速くなってそうです！ﾏｼﾞｶﾖ）


最後に、改善されたクエリのクエリプランも拝見しておきましょうか。
今回はリアルタイムのものが見てみたいので、EXPLAIN を使います。

EXPLAIN select * from test_table where id =1 limit 100;

【事象発生時（再掲）】

事象発生時と比較してプラン自体は変わっていなさそうですが、cost や rows が大幅に減っていますね。
=========================
・前回：cost=0.00..125000.00 rows=50000
　　　↓
・今回：cost=0.00..0.01 rows=1
=========================

状況からして、今回は ソートキー の作成による効果が絶大だったと言えそうです！
見事解決！！