SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
DynamoDBのキー・インデックスについてまとめてみた - Qiita
DynamoDBには以下の単語が登場します。 パーティションキー ソートキー プライマリキー ローカルセカンダリインデックス グローバルセカンダリインデックス これらのキー・インデックスについて改めて整理してみました。 まず「パーティション」「データの読み書きを行うAPIの種類」について整理します。その後、キーの種類について整理します。 パーティション DynamoDBのデータは複数のパーティションに分散して保存されます。このときデータがどのパーティションに保存されるかは パーティションキー を元に決定されます。 また ソートキー が設定されている場合、データはパーティション内でソートキーを元に並べ替えられて物理的に近くに配置されます。 例として、AnimalType（パーティションキー）とName（ソートキー）で構成されるPetsテーブルのデータは以下のように分散して保存されます。 （図
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
