<HOME　　<お願い事項　　 <Access2002 TOP　　　<Access2000 TOP　　　<サイト内検索
MS-Access97超入門＞1万件を超えると？

■1万件を超えると処理速度が遅くなるって本当？

うーん、そういうウワサ、耳にすることありますね。
ここでは、レコード件数についてちょっと考えてみたいと思います。
正しいような、正しくないような・・・。そんな感じですね。

でも、1万件という数字に根拠はないと思います。

残念ながら、いったいどのくらいの件数に達したら処理が遅くなるのか、明確にすることはできないです。

パソコンって、同じ機種同じスペック同じ環境のパソコンを２台ならべて、まったく同じ処理をさせても、処理スピードって一定じゃないです。
特に「データベースを読み取る」なんていう処理に関しては、正確に処理速度を把握するのは難しいんです。

パソコンの「システムリソース」（ハードディスクとかメモリとか）は、皆さんが意図的に開いているアプリケーションソフト以外にも、
パソコン内部の都合により占有されている部分ってあるんじゃないかなと思います。
数値の上では劣るパソコンでも、リソースがゆったりしているのでデータの検索が速い、というケースもあるようですね。

Accessのレコード検索のしくみは、１件ずつ読まれているのとちょっと違います。
「１万レコードの処理速度は100レコードの処理速度の100倍」というわけではないのです。

処理速度ががくっと遅く感じるようになったという理由のひとつは、そのパソコンでいっぺんに面倒みきれないデータ量で、
スワップする時間が発生しているってことじゃないかなと思います。
「１万件超えると、がくっと処理速度が落ちる」という話が出たのは、ちょうど１万件くらいでスワップが発生して、
ちょっと待たされた人がいた、ということじゃないでしょうか。

ちょっとテストしてみました。
小さなテーブルを作って、いろいろな処理をさせて時間を測ってみます。

[テスト用テーブル] ばんごう（主キー） 数値型（Long) なまえ テキスト型 カナ グループ くみ かず 数値型(Long) うけつけ 日付/時刻型 フラグ Yes/No型

★テスト１：データシートビューを開く
ただ開くだけだと、最初の数十レコード分の表示はすぐに完了するので、
ウィンドウ左下のレコード数が表示されるまでの時間を測ってみました。

★テスト２：カナで並べ替えるクエリーを開く
[カナ]を昇順に並べ替えるクエリーを開き、結果がデータシートビューに表示されれるまでの時間です。
テスト１と同様、ウィンドウ下のレコード数が表示されるまでの時間を測っています。

★テスト３：クロス集計クエリー
[うけつけ]を基に、[くみ]ごとに[かず]を集計した結果を表示するまでの時間を測ります。

★テスト４：検索結果をフォームに表示
[グループ]が「たぬき」で[くみ]が「02」で[フラグ]がfalseのレコードを抽出します。

★テスト５：フォームを開く
フォームから[ばんごう]を入力し、該当するレコードを表示させるまでの時間です。
フォームのレコードソースに、forms![フォーム名]![テキストボックス名]という抽出条件をつけたクエリーを使用。
ばんごうを入力後、再クエリーしています。

★テスト６：テキストボックスにDcount関数を使ってレコード件数を計算
フォーム内のテキストボックスのコントロールソースに=Dcount("フィールド名","テーブル名")を指定し、
テーブル内のレコード件数を表示させるまでの時間。
（いちおう、基にしているテーブル内の件数を数えさせています）

COMPAQ deskproXL590(Pentium90) 32MB memory（ちょっとレトロ？現役よっ）

レコード件数	テスト１	テスト２	テスト３	テスト４	テスト５	テスト６
１） 100件	1	1	1	1	1	1
２）5000件	1	1	3	1	1	1
３） 10000件	1	3	*6	2	1	1
４） 20000件	1	5	*10	2	1	1
５） 50000件	2	*12	*17	4	1	1
６） 200000件	4	*44	*55	13	1	4

10000件を境に処理スピードが前後している・・・とも言えないですね。
テストの内容によっては、100件だろうが20万件だろうが、ほとんど変らない場合もありますよね。

Accessに限ったことではないですが、とにかくデータベースと言うものは、整列するためのキーワードがないと、仕事がのろのろです。
整列するためのキーワード＝主キーやインデックスです。

カナにインデックス（重複あり）の指定をして、レコード数の多い５）と６）だけ、テスト２をやってみます。

	テスト２
５） 50000件	1
６） 200000件	4

結論としては、

件数の多くなりそうなテーブルには主キーを設け、しかるべきフィールドにインデックスの指定をする。
そして、フィールド数が多くなりすぎないよう、できるだけコード化してコンパクトに作る。

この点を考慮するだけでも、かなりのデータ件数に耐えられるようになると思います。
こういう考え方が、正しいデータベースの扱い方である、と言ってしまってもいいのかもしれないですね。

ただし、MS-Accessはパソコンソフトです。。
ワープロの文書、1ページの文書と500ページの文書、どっちの方が安全だと思います？？
50kbのファイルと500MBのファイル、どっちの方が・・・。答えは明確ですよね。
500MBのデータベースを使うのって、10m四方のでかい布団を押し入れから出したりしまったりしてるような感じ、しません？
押し入れ破壊しそうですよね。

レコード件数が多くなるということは、それだけデータ容量も大きくなります。
ワープロ文書とちがってAccessのmdbファイルの場合は、全部開いて処理するわけではないので、ファイルサイズ自体はそんなに気にする必要はないのですが、
ひとつのファイルのサイズはできるだけコンパクトになるよう心がけた方がよいでしょう。

上記のテスト用のテーブルは、テーブルにレコードを書き出すプロシージャを作って作りました。
100件書き出すときは３秒くらいで終わりますが、200000件書き出すときは４０分くらいかかったです。
単純に適当な値を作ってAddnewしているだけ。こういう場合はレコード件数分処理をくるくる繰り返しているので・・・
、レコード数が多ければ多いほど時間がかかりますね。
アクションクエリー（追加クエリーや更新クエリー）を動かす場合も同様に、レコード数が多ければ多いほど処理時間がかかるのでしょう。
これはやむをえないかなと思いますので、処理の中身を見直して、いっぺんに数万レコード追加するような処理にならないよう、検討する方が先決かもしれません。

数万レコードのテーブルの中から、数件のレコードを検索する際は、テーブルの設計段階からインデックス等の配慮をしておけば、
ある程度はAccessの実力が発揮されて、処理速度に結びつくのではないかなと思います。
ただし、例えば「数万レコードあるテーブルのフィールドをふたつくっつけて、更新クエリーを使って新しいフィールドを作りたい」とか、
「２万レコードのテーブルに６万レコードのテーブルを追加クエリーで追加したい」とか「１０万レコードのテーブルのレコードを全部削除したい」というように、
物理的にレコードの操作をするときは、件数＝処理スピードにつながります。
これは、なるべくレコード件数が多くならないうちに累積テーブルを作るとか、処理内容を見直して負担がかからないように、処理の流れを検討すべきでしょう。