本稿はデータベースソフトウェア「SQL Anywhere」およびデータベース全般に関する英語ドキュメントを翻訳する形で提供しています。図など、部分的に英語のままになっていますが、製品のSQL Anywhere自体は完全に日本語化されていますのでご安心ください。
パフォーマンス分析は一筋縄ではいかないことが多いのですが、それは可変要素が非常に多く、ハードウェアの特性、ワークロード、物理的データベース設計、およびアプリケーション設計など、あらゆる要素を検討する必要があり、またこれらの要素の間にトレードオフや副作用が存在するからです。これが正解、と言えるものが見つからないのが普通です。
少し前、SQL AnywhereのコンサルタントであるBreck Carterが、「How to Make SQL Anywhere Slow（SQL Anywhereを遅くする方法）」という記事を書きました。これは今までに読んだ記事のなかでも最大のお気に入りの1つです。Breckはこの記事の中で、パフォーマンスの低下につながる38の異なるデータベース設計、アプリケーション設計、およびサーバ構成設定を列挙しています。この記事を受けて、今後しばらくは「データベースアプリケーションのパフォーマンスにおける7つの大罪」という少々生意気なタイトルの下に、特に説明する値打ちがあると思われる7つの具体的な問題について詳しく書いていこうと思います。
「データベースアプリケーションのパフォーマンスにおける7つの大罪」とは次のとおりです。
- お粗末な物理データベース設計（スキーマ設計問題、テーブルの列の順序、インデクシング、データページサイズ）
- ロックの競合（ホットロー問題または上位のANSI分離レベルでの実行による）
- 反復的なネスト構造の実行（ネストされたクエリ、ユーザー定義関数、クライアントサイド結合など多数）
- 単一クエリでの処理量が必要以上に多い（アクセス／取得するデータ量が膨大、またはクエリが複雑すぎて最適化が難しいなど）
- 効率の悪いクライアント／サーバインタラクション（フェッチ設定、ワイド挿入またはワイドフェッチ、プリペアードステートメントの使用、同一サーバからの同じ情報の再フェッチなどが要因として考えられる）
-
SELECT文の最適化目標の選択ミス -
トランザクションモデルの選択ミス（特に自動
COMMITの使用）
次回の記事では、アプリケーションのパフォーマンスにマイナス影響を与える物理データベース設計のトピックを取り上げます。
