ダーティリードしてもいいじゃん！
エンタープライズアプリケーションは正確に動いてナンボであり、パフォーマンスがいくら良くても正確に動いていなければ失格だ。だが、もちろんパフォーマンスも蔑ろにしてはいけない。ユーザにしてみれば、アプリケーションが正確に動くのは当たり前。「速い」「軽い」ソフトウェアを開発するのもプロの仕事と言える。 エンタープライズアプリケーションにおけるパフォーマンスチューニングの肝はいくつもあると思うが、データベース周り(※1)に絞って話をする。 SQL Server のチューニングとして、インデックスを作成する事を筆頭に挙げる人もいると思う。非クラスタ化インデックスを利用した検索は、非クラスタ化インデックスのスキャンとクラスタ化インデックスのスキャンの都合 2 度のスキャンが行われる。この 2 度のスキャンを避けるために、インデックスとなる列を増やすか「付加列インデックス」というワザを使い、クエリの列を
クエリの実行プランを強制する。 - レベルエンター山本大のブログ
いま、クエリのパフォチュをしている。 その中でちょっとした問題にぶつかった。 本番サーバー（高スペック）で実行すると劇的に遅く（5分）、 ハードウェアスペックのみが異なる開発環境では、予期している速度（5秒）という現象だ。 詳しく調べていると、本番サーバーでのクエリ実行プランが開発環境とは、まったく異なることに気づく。 実行プランは、SQLServerのオプティマイザ機能が、インデックスや統計情報、CPUやメモリ状態など あらゆる点を考慮して自動的に作成するが、今回はオプティマイザがちょっとおばかだったらしい。 この対応としては、「Option(HASH JOIN)」というクエリヒントをつけることで、 ある程度、こちらの想定する実行プランに強制することで対処した。 ただ、非常に危ない機能なので、利用を躊躇していたけど、 クエリの内容を検討して、確実にHash Joinであるほうが早いと踏ん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
