ここ2日はパフォーマンス改善に凝っている
コード上の見直しを進めていくにつれ、どんどんサーバのCPU負荷、メモリ使用量が下がり、パフォーマンスが向上していくのは気持ちが良い。SpeedMetalSymphonyである（謎）。
DB周りでもチューニングをしているのであるが、最もメモリ食いなのはビューテーブルに対する検索であると推測されるのである。
アプリケーションの設計上、異なるスキーマを持つテーブルを串刺しで検索したり、一意のIDを採番するため、またはセキュリティなどのアプリ共通の情報にアクセスするために、UNIONでテーブルを連結しまくったビューテーブルを使用している。（現在view_alldocumentというビューは42ものテーブルの11フィールドからなる巨大な仮想テーブルになっている）
・・・でここに改善のメスを入れることで、DBアクセスの全体的なパフォーマンスが向上するはずなのである。テーブル単位ではもちろんインデックスを作成しているので、良好な検索速度が得られるのであるが、ビューに対する検索はいまいちなのである。テーブルを結合したビューでは、どうしても総件数が多くなるため・・というのはあるが、「そもそもビューにインデックスは付けられないのだろうか？」というのが今回の疑問。・・・で調べたらSQLServer2000以降ではビューインデックスの強化が図られているらしい。
ソースはこことここ
クエリオプティマイザがどうだとか、エンタープライズがどうとか訳のわからんことが書かれているが、とりあえず”WITH SCHEMABINDING ”オプションを指定してビューを作成すればいいのかい？
チャレンジ1：
とりあえずテーブルにインデックスをつけたみたいに、ビューにもインデックスを作成できるかどうか試してみる。
「インデックス をビュー 'view_alldocument' に作成できません。ビューがスキーマ バインドされたビューではありません。」
うーん、ビューがWITH SCHEMABINDINGオプションで作られていないからっていうことを言ってらっしゃるんだね
チャレンジ2：
既存のビューを削除して作り直してみる。
CREATE VIEW VIEW_TEST WITH SCHEMABINDING AS SELECT a, b, c, d FROM dbo.T
一度既存のビューをリネームし、ビュー生成用のSQLを流し込むと・・「おぉ！通った」。ビューの再構築成功。
さらに、今できたビューに対してインデックスを作成してみる。
CREATE INDEX IX_idx ON view_alldocument(n_uniquedocid)
「インデックス をビュー 'view_alldocument' に作成できません。 一意なクラスタ化インデックスを持っていません。」
一意なクラスタ化インデックスってなんね？再度マイクロソフトTech-Netの情報を調べるがSETオプションだかというものの設定が必要で、その後にインデックスを作成して・・・・って、「知らんがな！んなこと」
とにかく、SQLServerの拡張機能であるクエリオプティマイザというのを通して、特殊なアクセスをするための設定が必要だということなのかいな？。
※こういうことした挙句に、発行するSQLまでDBに最適化させちゃうと、別のRDBMSとかにプログラムを対応させられなくなっちゃうなぁ。
