無料PHPプログラム

MySQL 5.1 リファレンスマニュアル :: 6 最適化 :: 6.4 データベース構造の最適化 :: 6.4.1 設計上の選択
« 6.4 データベース構造の最適化

6.4.2 データの小型化 »
Section Navigation      [Toggle]
  • 6.4 データベース構造の最適化
  • 6.4.1 設計上の選択
  • 6.4.2 データの小型化
  • 6.4.3 カラムインデックス
  • 6.4.4 複合インデックス
  • 6.4.5 MySQLにおけるインデックスの使用
  • 6.4.6 MyISAMキーキャッシュ
  • 6.4.7 MyISAMインデックス統計コレクション
  • 6.4.8 MySQL でのテーブルのオープンとクローズの方法
  • 6.4.9 1 つのデータベースに大量のテーブルを作成した場合の欠点

6.4.1. 設計上の選択

MySQLはローデータとインデックスデータを別のファイルに格納します。その他のデータベースの多く(ほとんど)は、ローデータとインデックスデータが同じファイルに混在しています。現在の非常に多くのシステムで MySQL の選択のほうが優れていると確信しています。

行データの格納方法には、各カラムの情報を独立した領域に格納する方法もあります(例: SDBM、Focus など)。これは、複数のカラムにアクセスするすべてのクエリでパフォーマンスに影響を及ぼします。パフォーマンスは複数のコラムへのアクセスを開始するとただちに低速化するため、このようなモデルは汎用データベースには適さないと確信しています。

一般的にインデックスとデータが一緒に格納されている場合も多くあります(Oracle、Sybase などの場合)。この場合は、レコード情報をインデックスのリーフページで検索します。このレイアウトで優れている点は、多くの場合インデックスのキャッシュ方法次第でディスクの読み取りを節約できることにあります。このレイアウトの欠点は以下のとおりです。

  • データの取得時にインデックス全体を読み取る必要があるため、テーブルスキャンの速度が大幅に下がる。

  • クエリでデータを取り出す際にインデックステーブルのみの使用ができない。

  • ノードからインデックスを複製する必要があるため(レコードはノードに格納できないことによる)、大量の領域が消費される。

  • 削除があるとテーブルの速度が次第に低下する(通常、削除ではノードのインデックスが更新されないため)。

  • インデックスデータのみのキャッシュが困難である。

Copyright c 1997, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices
Top / Previous / Next / Up / Table of Contents
© 2010, Oracle Corporation and/or its affiliates

無料CGI PHPスクリプト | 新着情報スクリプト | 営業日カレンダー | PHPマニュアル | MySQLマニュアル | PEARマニュアル

Copyright (c) 2010 jmcodex.com All rights reserved.