インデックスを作成して，SQLの速度をチューニングする手順 （PostgreSQLで，EXPLAIN文とCREATE INDEX文によるパフォーマンス改善） - 主に言語とシステム開発に関して
以下の５ステップで，適切なインデックスを作成し，SQLを高速化できる。 （１） パフォーマンスを改善すべきSQL（もしくはカラム）を特定 （１−１） ログを閲覧し，実行秒数の大きいものを抽出する。 （１−２） 統計テーブルを閲覧し，よく利用されるテーブルを特定する。 （２） 該当SQLのプランやコストを確認 （３） 該当カラムに対してインデックスを作成 （４） インデックスが作成されたことを確認 （５） SQLのプランやコストが改善されたことを確認 補足 ※↑ もくじジェネレータ で自動生成 DBはPostgreSQLを想定。 （１）パフォーマンスを改善すべきSQL（もしくはカラム）を特定 まず，インデックスを作成すべきカラムを見極める。 その方法は２つある。 （１−１）ログを閲覧し，実行秒数の大きいものを抽出する。 SQLの実行ログを閲覧する。 たとえば，Ruby on Railsなら，
MySQLでフラグの列でSELECTする。（複合インデックスの使用条件） – 猫型iPS細胞研究所
status=’1’とかdelete=’0’といった条件はよく使用することでしょう。 そこでフラグにはどのデータ型がベストなのでしょうか。 フラグにベストなデータ型 考えられるのは tinyint(1) smallint(1) といった数値型。 もしくは char(1) char(3) といった文字型でしょう。 char(3)としたのは、マイナスだってありうるからです。 以下100万件のデータにランダムな10件のstatus=’1’のデータを作成して select id,name,status from test where status=’1′ した結果です。 tinyint(1)の場合 DROP TABLE IF EXISTS `test`.`test`; CREATE TABLE `test`.`test` ( `id` int(10) unsigned NOT NULL AUTO_
論理削除がデータを汚している - jfluteの日記
ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 本来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、本体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か
複合インデックスの正しい列の順序
データベースは、プライマリキーに対して自動的にインデックスを作成しますが、キーが複数の列からなる時は、さらに手動で調整をする 余地があります。この場合、データベースはプライマリキーの全ての列にいわゆる 連結インデックス(あるいはマルチカラム インデックス、複合インデックス)を作成します。 複合インデックスの列の順番は、インデックスの使い勝手に大きな影響を及ぼすので、注意して決定する必要があります。 例として、企業が合併した場合を考えてみましょう。他の会社の社員が 加わったので、EMPLOYEESテーブルが10倍の大きさになったと しましょう。ここで問題が発生します。EMPLOYEE_IDが、 それぞれの会社で一意になっていなかったのです。子会社IDのような追加の識別子で、プライマリキーを拡張する必要があります。このため、プライマリ キーは、以前からのEMPLOYEE_IDに加えて、一意性を
PostgreSQLでインデックスを効率良く利用しよう | TECHSCORE BLOG | TECHSCORE BLOG
どうも、Benoîtです。 TECHSCORE Advent Calendar 2014 の 4 日目の投稿です。 PostgreSQLではいろいろなインデックス種類が存在する。使い方も様々である。インデックス種類の概要のあとに一番使われるB-treeインデックスの使い道や保守の話しを深めていく。 インデックスとは特定の項目を素早く参照できるようにするためのもの。B-treeインデックスに関してはソートに使うこともできる。 インデックスの種類 PostgreSQLはいろいろなインデックスに対応している。 B-treeインデックス、CREATE INDEX を利用するとデフォルトで選択されるインデックスである。Bの字はバランスの意味で、イメージとしてはtree（木構造）のroot（根）からleaf（最下層のノード）までの階層数がなるべく揃うようにバランスを取る。B-treeインデックスはどの
パフォーチューの中心で悲しみを叫ぶ - 肩書「シニアコンサルタント」のつぶやき
祭りじゃ！祭りじゃ！！ 今回は、今のプロジェクトであったお祭りの話でもしようかな〜と思うわけである。 なんのお祭りかというと、「パフォーマンス問題祭り」なのであった。 よくある話といえばよくある話。単体テスト・結合テストあたりまでは問題にならなかった性能が、実際のマスタデータ投入時や、トランザクションデータボリュームになった途端、とってもパフォーマンス的に悲しいものになったプログラムが出てきたわけで・・・ で、いつものように、気が付けばそのお祭り対応のど真ん中にいるハメになり、日々トレースデータと向き合うことになった。 ということで、基本的な話ばかりかと思うが、ちょっとアドオン作成時のパフォーマンス考慮ポイントを備忘として残しておこうかなあ、というのが、今回の企画である。 ざっくりポイント パフォチューのポイントとしては、大雑把に以下3点となる。 設計の方針 SQL関連 内部テーブル関連
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
