100MbpsLAN Pentium3 でクエリが遅い場合の対処方法（データベース自体が遅い場合にもチェックしてみます。）

● 100MbpsLAN Pentium3 でクエリが遅い場合の対処方法（データベース自体が遅い場合にもチェックしてみます。）
※まだ書きかけです。すみません。

※関連記事
・Access2000 ファイルサーバに配置したmdbファイルへの同時アクセスにおいて、mdbファイル破損を激減させるサーバ側のレジストリ設定（Access2000昔からの既知の問題の解決）
https://euc-access-excel-db.com/tips/ct07_se/ct071701_mini_system_make/access2000-mdb-crush-avoid
　　
　　
本Tipsによって、100MbpsLAN Pentium3 でも全く問題なく速くなるので、今のマシンならクエリはもう少し速くなる気がします。数十万件のテーブルを複数同時に扱っても完全一致や前方一致なら、別に１～２秒前後で表示されるクエリのほうが多いです。何でもかんでも部分一致にしたら、多分SQL Server でも思ったより遅いと思います。
　　
　　
※2018/10/10 忘れてたことを思い出したので追記
「Access2000・mdbの動作速度をネットワーク越し利用でも速くする」といっても、mdb本来の速さに戻るだけで、それ以上に速くなるわけではありません。とはいうものの、Jetエンジンは、ローカルPC内や同フロアの小さなLAN内なら「ちゃんと作れば」、SQLServer2000などよりも速いことも少なくないと思います。
といいますか、SQLServer2000自体、意外と速くないです。ストアドプロシージャ使っても、小さなLAN内ならmdbのJETエンジンのほうが速かったりします。
SQLServer2000（あるいはストアドプロシージャ）を使って速くなるのは、VPNなどを使って、離れた拠点（町とか国とか）のmdbを見に行くときなどかもしれません。
Web上や市販書籍には「SQLServer使うと速い！ストアドプロシージャ使うと速い！」という情報が多いので、メッチャ速いのかと勘違いされるかもしれませんが、実際にご自分でも動かしてみればお分かりになると思いますが、「mdbのローカルPC使用」の速さよりも速くないです。
「ネットワーク利用時の、しかも、”mdbの速度低下を招く使い方しかしてない場合（本記事のような対策をしてない場合”、よりは速い」というだけです。後方一致や部分一致ではたしか普通に遅くなったかと思いますし。

あと、リンクテーブルの速さを「（見かけ上）劇速にする＝mdbの本来の速さに戻す」には、本記事のこと以外にも次のような方法があるようです。

(01)巻末にも書きましたが、AutoExecマクロで「プロシージャの実行」を使うなどして、DAO（OpenDatabase)などを使ってサーバ側のmdbを常時開いておく。閉じるときに一応Nothingする。

(02)本記事の方法を使わない場合、SQLの中で「IN ('\\ファイルサーバ名\共有フォルダ名\mdbファイル名')」という形で、UNCパスでその都度、ファイルサーバを指定する。

(01)はやったことありませんが、「JET データベースエンジンプログラマーズガイド」のP468・469にも書いてある方法です。巻末にも少し書きましたのでご参考にしてください。（ダメだったらごめんなさい。）

(02)は確か、少しやったことがあるのですが（うろ覚えですみません）・・・、
SELECT 列名 FROM テーブル名 INNER JOIN 結合フィールド名 IN ('\\ファイルサーバ名\共有フォルダ名\mdbファイル名')
・・・みたいな感じで書きます。
IN句でカッコと「'」（シングルクォーテーション）を使ってLAN上のmdbを指定します。
そうすると、本記事の「ダミーフォームの非表示」をさせなくても、結構速かったような気がします。
これはあらかじめ、そのテーブルのリンクテーブルを作る必要は無かったかと思います。（必要があったらごめんなさい！！）
ただ、これも、僕の勘違いで、（速度的に）もしダメだったらごめんなさい。

なお、本記事の方法、DAOを使う方法、では、以下のことを守らないと結局遅いままなので、以下のことも必ずチェックしてください。
・同一リンクテーブルへのUNCパスの統一（UNCパスを使っている場合のみ）

上記の(02)でも、(02)の方法とは関係のない場面で使うリンクテーブルを作ってあると、もしかしたらそうかもしれません。ご自分でもチェックしてみてください。

なんせ、全部うろ覚えのことを思い出しただけなので・・・。

　　
　　
＝＝＝＝＝＝＝＝＝

Accessは、「テーブル」のみならず「クエリ」をソースにフォームやレポートを作ることが多いソフトです。

ですので、クエリの動作が遅いと、そのクエリをソースにしたフォームもレポートも動作が遅くなってしまいます。ひいてはデータベースシステム全体の動作も遅くなってしまいます。

ですので、クエリの動作を低下させない、ということは、データベースシステム全体の動きも低下しない、ということにむすびつきますので、是非、ご自身でも色々と研究してください。ここでは、その基礎的なTipsをご紹介します。

中には、クエリとはそれほど関係のない項目もありますが、データベースを遅くさせない、という点では同じですので、一応、ここでご紹介させて頂いています。

また、2000でのTipsなので、2003までならあてはまることもそこそこあると思います。2007でもmdb形式のファイルを扱うなら当てはまることも多いと思います。

あとついでに、mdbファイルをファイルサーバ上で共有したときに、mdbが壊れないようにする方法もご紹介しておきます。以下です。
・Access2000 ファイルサーバに配置したmdbファイルへの同時アクセスにおいて、mdbファイル破損を激減させるサーバ側のレジストリ設定（Access2000昔からの既知の問題の解決）
https://euc-access-excel-db.com/tips/ct07_se/ct071701_mini_system_make/access2000-mdb-crush-avoid

以上は、2007以降で、ACCDBという拡張子だとそれほど当てはまらないかもしれませんが、Access2000ではこういうことで遅くなるのか、とわかれば、何らかのヒントになるかもしれません。

では以降、どうぞ、ご覧ください。
　　
　　
・名前の自動修正のOFF
名前の自動修正は便利と言えば便利なのかもしれませんが、Access2000では諸悪の根源でエラーが多発したり、いろんなところの動作が遅くなる原因になります。
また、「テーブルやフォームの名前は、できるだけ変更しないでも済むように最初からそれを見越して名付けをする」ということをある程度守れば、それほど名前の変更やそれに伴うクエリのSQL内容やVBAコードの修正なども発生しないので（発生したとしても検索や置換での修正で別に困らないので）、これと言ってメリットもありません。

ですので、この機能は切っておきます。
これはクエリだけでなくフォームやレポート、データベース全体に影響しますのでAccess2000~2003では特に理由がない限りは必ずOFFにしておきます。

ツール→オプション→全般タブ、にて下図部分の３つのチェックを全部はずして「適用」か「OK」します。

　　
　　
・ダミーテーブルの連結フォームを非表示で常時開いておく

これも最重要事項のひとつです。詳しくは以下のページをご参照ください。
● mdbの動作速度をネットワーク越し利用でも速くする方法～結構重要～：★ ダミーテーブルの連結フォームを非表示で常時開いておく
　　
　　
・同一リンクテーブルへのUNCパスの統一（UNCパスを使っている場合のみ）

「同一リンクテーブルへのUNCパスの統一」とは、まず、次のような状況であることが前提です。
(01)Accessのmdbファイルを「データ専用」と「プログラム専用」に分けている。
(02)「プログラム専用」のmdbから、「データ専用」のmdbのテーブルを「リンクテーブル」として覗きに行っている。
(03)「データ専用」のmdbはファイルサーバに格納。
(04)「プログラム専用」のmdbは複数台のクライアントパソコンに格納。
(05)ファイルサーバの「データ専用」のmdbへは複数のクライアントが同時アクセスする
(06)リンクテーブルのパスに「UNCパス」を使っている。

このようなときに、「リンクテーブルのUNCパスの指定」にミスがあると、プログラム側の動作速度（テーブルを見に行くときの速度）が極端に遅くなります。これはLANの回線の太さとは無関係です。

では「リンクテーブルのUNCパスの設定ミス」についてお話します。
大した話じゃないのですが、でもこれをミスるとすごく遅くなってしまいます。

例えば、簡易LAN・・・つまりワークグループでのLANを組んだ際、「データ専用」のmdbのテーブルが、まず、次の場所に格納されていたとします。

server01という名前のファイルサーバーの、
「D」ドライブの中の
「mdb」フォルダの中の
「data01」フォルダの中。

そしてmdbファイルの名前が「data000001.mdb」だったとします。

で、このとき、「data01」フォルダに共有設定がなされていたとします。

するとこの場合の「data000001.mdb」のリンクテーブルのUNCパスは、

\\server01\data01\data000001.mdb

となります。

でも、設定ミスか何らかの都合で、「data01」フォルダの１つ上の階層の「mdb」フォルダにも、共有フォルダの設定がなされてしまっていたとします。

このような場合、「data000001.mdb」のテーブルのリンクテーブルを作成するときに、本来なら、リンクテーブルのすべてのパスが、

\\server01\data01\data000001.mdb

に統一されるはずが、「どうせ同じmdbを見に行くんだから、多少UNCパスが変わってもいいだろう・・・」という誤判断から、

\\server01\mdb\data01\data000001.mdb

というリンクテーブルのパスの設定をしてしまうことがあります。

このようなことをすると、Access2000では、なぜか、「すべての」リンクテーブルの開く速度が、「突然」、極端に、恐ろしいほど「劇遅」になってしまいます。
「突然」「全部」のテーブルが遅くなっちゃうのでちょっとビビります。

これを解決するには、リンクテーブルのUNCパスの設定を、
\\server01\data01\data000001.mdb か、
\\server01\mdb\data01\data000001.mdb の
いずれかに統一しなければ解決できません。
（どちらかに統一してあれば大丈夫です）

リンクテーブルのUNCパスを統一すると、メッチャ速くなります。
といいますか、本来のテーブルの動作速度に戻ります。

ファイルサーバのmdbを多くのクライアントで共有している場合、また、そのmdbが複数あるような場合は、UNCパスを統一ミスしてしまいやすいので注意が必要です。

統一されているかのチェックを簡単にするには、オプション設定で隠しオブジェクトを見えるように設定して、そのうちの、「MSysObjects」テーブルの「Database」列を見ます。ここにリンクテーブルのパスが格納されています。
この「MSysObjects」テーブルをCtrl+Aして、Excelに貼り付け、「Database」列で降順に並べ替えて、同じmdbに対して複数のUNCパスが存在したら、どれかに統一します。
（ツール→データベースユーティリティ→リンクテーブルマネージャなどで。VBAで一括書きかえすることも可能ですが、特別な理由がない限りは、リンクテーブルマネージャでやるほうが早いです。）

なお、これはUNCパスの場合だけで、プログラム専用のmdbもテーブル専用のmdbも、両方とも1台の同じパソコンの中にあるときは、パスがバラバラになりようがないので大丈夫です。
　　
　　
・実テーブルとリンクテーブルのサブデータシートのOFF（VBA）

サブデータシート機能がONのままだと、クエリその他の動きが遅くなることがあります。
ですので、例えば以下の VBAプログラムを実行して、すべてのテーブルのサブデータシート機能をOFFにします。（リンクテーブルの場合はリンク先＝バックエンド＝データ専用のmdbのほうでやります。）

なお、新しく作ったテーブルは手動で[None]にしたほうが早いです。

テーブルをデザインビューで開いて適当な行で右クリックし、「サブデータシート」で「なし」を選んびます。「なし」を選ぶと、自動的に[None]になります。（バージョン2000の場合）

あと、「展開したサブデータシート（2019だとサブデータシートの展開？）」は「いいえ」にします。

'########################################################
'
'すべてのテーブルのサブデータシート機能をOFFにする
'
'########################################################
Sub TurnOffSubDataSheets()

  Dim MyDB As DAO.Database
  Dim MyProperty As DAO.Property
  
  Dim propname As String
  Dim propType As Integer
  Dim propVal As String
  
  Dim strS As String
  
  Set MyDB = CurrentDb
  
  propname = "SubDataSheetName"
  propType = 10
  propVal = "[NONE]"
  
On Error Resume Next
  
  For i = 0 To MyDB.TableDefs.Count - 1
      
  If (MyDB.TableDefs(i).Attributes And dbSystemObject) = 0 Then

      If MyDB.TableDefs(i).Properties(propname).Value <> propVal Then
             MyDB.TableDefs(i).Properties(propname).Value = propVal
             intChangedTables = intChangedTables + 1
      End If
 
      If Err.Number = 3270 Then
          Set MyProperty = MyDB.TableDefs(i).CreateProperty(propname)
          MyProperty.Type = propType
          MyProperty.Value = propVal
          MyDB.TableDefs(i).Properties.Append MyProperty
      Else
             
         If Err.Number <> 0 Then
             MsgBox "Error: " & Err.Number & " on Table " _
             & MyDB.TableDefs(i).Name & "."
             MyDB.Close
             Exit Sub
         End If
          
      End If
          
  End If
  Next i

  MsgBox "The " & propname & _
  " value for all non-system tables has been updated to " & propVal & "."

  MyDB.Close

End Sub

'＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
'＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

★一応、１つのテーブル単発をイミディエイトでも設定変更でることはできます。

? CurrentDb.TableDefs("t_9900_役職リスト").Properties("SubDataSheetName").Value
CurrentDb.TableDefs("t_9900_役職リスト").Properties("SubDataSheetName").Value = "[Auto]"

ただし、一度も変更したことがないと、このコードはエラーになります。（特に１行目）
プロパティが見つかりません、のエラー。
なのでこれは、手動変更してから。

手動変更は以下の通り。

テーブルをデザインビューで開いて適当な行で右クリックし、
「サブデータシート」で「なし」を選んでも良い。

「展開したサブデータシート（2019だとサブデータシートの展開？）」は
「いいえ」にする。

この設定がめんどくさかったら、前述のループコードを実行したほうが早いようです。

新規にテーブルを作った場合は、手動で設定変更したほうが早いです。

'########################################################

'すべてのテーブルのサブデータシート機能をOFFにする

'########################################################

Sub TurnOffSubDataSheets()

Dim MyDB As DAO.Database

Dim MyProperty As DAO.Property

Dim propname As String

Dim propType As Integer

Dim propVal As String

Dim strS As String

Set MyDB = CurrentDb

propname = "SubDataSheetName"

propType = 10

propVal = "[NONE]"

On Error Resume Next

For i = 0 To MyDB.TableDefs.Count - 1

If (MyDB.TableDefs(i).Attributes And dbSystemObject) = 0 Then

If MyDB.TableDefs(i).Properties(propname).Value <> propVal Then

MyDB.TableDefs(i).Properties(propname).Value = propVal

intChangedTables = intChangedTables + 1

End If

If Err.Number = 3270 Then

Set MyProperty = MyDB.TableDefs(i).CreateProperty(propname)

MyProperty.Type = propType

MyProperty.Value = propVal

MyDB.TableDefs(i).Properties.Append MyProperty

Else

If Err.Number <> 0 Then

MsgBox "Error: " & Err.Number & " on Table " _

& MyDB.TableDefs(i).Name & "."

MyDB.Close

Exit Sub

End If

Next i

MsgBox "The " & propname & _

" value for all non-system tables has been updated to " & propVal & "."

MyDB.Close

End Sub

'＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

★一応、１つのテーブル単発をイミディエイトでも設定変更でることはできます。

? CurrentDb.TableDefs("t_9900_役職リスト").Properties("SubDataSheetName").Value

CurrentDb.TableDefs("t_9900_役職リスト").Properties("SubDataSheetName").Value = "[Auto]"

ただし、一度も変更したことがないと、このコードはエラーになります。（特に１行目）

プロパティが見つかりません、のエラー。

なのでこれは、手動変更してから。

手動変更は以下の通り。

テーブルをデザインビューで開いて適当な行で右クリックし、

「サブデータシート」で「なし」を選んでも良い。

「展開したサブデータシート（2019だとサブデータシートの展開？）」は

「いいえ」にする。

この設定がめんどくさかったら、前述のループコードを実行したほうが早いようです。

新規にテーブルを作った場合は、手動で設定変更したほうが早いです。

よく覚えてないのですみませんが、超昔に、Access2000の、以下のようなKBを見てそのままパクったか、少し変えて作ったんだと思います。変更箇所？は汚いダメコードですみませんが、一応、使えると思います。2007で使えるかはわかりません。すみません。試すならmdbのバックアップとか作って自己責任でお願いいたします。

https://support.microsoft.com/ja-jp/help/275085/slow-performance-on-linked-tables-in-access-2002,-in-office-access-2003,-and-in-office-2007

動かし方もこのWebページから引用します。

1.バックエンドデータベース（mdb）を開きます。
2.[データベース] ウィンドウの [モジュール] をクリックし、[新規作成] をクリックします。
もしくは既存のモジュールを開きます。
3.[ツール] メニューの [参照設定] をクリックします。[Microsoft DAO 3.6 Object Library] チェックボックスがオンになっていることを確認し、[OK] をクリックします。
4.新しいモジュールに上記のコードをコピペして実行します。

なお、全部、「自動」に戻すには、「propVal = "[NONE]"」の行の「NONE」を「auto」に書き換えて実行するだけです。

リンクテーブルの場合は、プログラム側のほうでは全部リンクテーブルなら実施する必要は無かったと思います。でもチェックしてみてもし違ってたら、プログラムのmdb側のほうでも同じことをします。

また、プログラム側のほうに、一時テーブルなどでリンクテーブルじゃないローカルのテーブルがあるなら、その場合も、一応、やっておきます。

設定が完了したかどうかは、以下の方法でできます。
・リンクテーブルかバックエンドのテーブルをデザインモードで開きます。
・「フィールド名」「データ型」などの上で右クリックして「プロパティ」
・サブデータシート名のところが「NONE」になっていればOKです。
元に戻したときは「自動」になります。
　　
　　
・実テーブルとリンクテーブルの並べ替え実行プロパティ（OrderByOnプロパティ）のOFF（VBAと手動)

※これもAccess2000の例です。2002、2003でもできるかもしれません。
※2007ならmdbを使っているときはあてはまるかもしれません。

前項の「実テーブルとリンクテーブルのサブデータシートのOFF」とセットでやっておきます。

ここではすべてのテーブルの「並べ替え実行プロパティ（OrderByOnプロパティ）」をOFFにします。
ONのままだとテーブルを開くのに時間がかかることがあるからです。
これは定期的にチェックしたほうがいいと思います。
もしくは、「あれ？なんかmdb全体の動作が遅い・・・」という時にも見直します。

後述のプログラムで、すべてのテーブルの「並べ替え実行プロパティ（OrderByOnプロパティ）」を自動チェックした際に、もしそれがONになっているテーブルが出てきたら、そのテーブルに対して、次の処理をします。

(a)テーブルを開いて、いったん適当な行で降順で並べ替えをし、その後、どこでもいいので右クリックします。
(b)「フィルタ／並べ替えの解除」を押して、テーブルを閉じ、保存を求められたら「はい」でテーブルを閉じます。
　これで並べ替え実行（OrderByONプロパティ）が手動でOFFにできました。
(c)そのテーブルをデザインモードで開きます。
　フィールドの設定内容のどこか適当な位置で右クリックしてプロパティします。ダイアログがでます。
(d)「並べ替え」の欄に何か設定文字列があったら消します。空白にします。
　空白にできたら「×」でダイアログを閉じます。
(e)テーブルデザインの画面を上書き保存で閉じます。
(f)処理できたら、再度、プログラムを実行して、テーブル名が一つも出なくなったら完了です。
もし、OFFにしたはずなのに、OFFになっていないテーブルがあったら、いったん並べ替えを実行して上書き保存し、その後、再度解除して上書き保存してみます。

なお、「並べ替えプロパティ（OrderByプロパティ）」と「並べ替え実行プロパティ（OrderByOnプロパティ）」は異なります。
「並べ替えプロパティ（OrderByプロパティ）」は並べ替えの設定文字列のことで、
「並べ替え実行プロパティ（OrderByOnプロパティ）」は、その文字列通りに並べ替えを実行しちゃうよ！というプロパティです。

なので、「並べ替えプロパティ（OrderByプロパティ）」に並べ替えの設定文字列が入力されていても、並べ替え実行は、OFF設定になっていれば実行されません。
ただ、「並べ替え」の欄に降順設定の文字列（DESC）が入っていると、テーブルを開く際に何かの入力を求められて面倒くさいので、並べ替え実行プロパティをOFFにするときに、一緒に、テーブルのデザイン画面の設定で空白にしてしまいます。

以上は、念のためにリンクテーブルの実テーブルのほうでも、リンクテーブルから開いた時も、両方共でやっておきます。
つまり、テーブル専用のmdbの実テーブルと、プログラム専用のmdbのリンクテーブルと、両方でやります。並べ替えの解除設定と並べ替え設定文字列の消去とをです。
並べ替え設定文字列の消去のほうは、リンクテーブルの場合は、デザインモードにするときに「一部のプロパティは変更できません」というメッセージが出ますが、構わず、設定をします。
「並べ替えプロパティ（OrderByプロパティ）」はリンクテーブルもテーブルも別々に変更できますので。
「並べ替え実行プロパティ（OrderByOnプロパティ）」も同様に別々に設定されています。
なので、両方とも、(a)～(f)の処置をしておきます。

「並べ替え実行プロパティ（OrderByOnプロパティ）」がONになっているか、OFFになっているかは、後述のチェックプログラムを以下の手順で実行します。

1.バックエンドデータベース（mdb）を開きます。
2.[データベース] ウィンドウの [モジュール] をクリックし、[新規作成] をクリックします。
もしくは既存のモジュールを開きます。VBEditorの画面が出ます。
3.[ツール] メニューの [参照設定] をクリックします。[Microsoft DAO 3.6 Object Library] チェックボックスがオンになっていることを確認し、[OK] をクリックします。
4.表示→イミディエイトウィンドウで、イミディエイトウィンドウを表示します。
　ここに、チェックにヒットしたテーブル名が表示されます。
5.新しいモジュールか既存のモジュールに下記のチェックプログラムのコードをコピペして実行します。
6.イミディエイトウィンドウをチェックします。
　ここに　「テーブル名---True」と表示されたテーブルは、
　「並べ替え実行プロパティ（OrderByOnプロパティ）」がONになっていますので、
　開いて「フィルタ／並べ替えの解除」をOFFにして保存します。

以下、チェックプログラムです。

'########################################################
'テーブルの「並べ替え実行プロパティ（OrderByOnプロパティ）」
'がONかOFFかを調べるコード
''
'########################################################

Sub tbl_orderby_chk()

  Dim dbs As DAO.Database
  Dim tdf As TableDef

  On Error GoTo error1
  
  Set dbs = CurrentDb
  
  For Each tdf In dbs.TableDefs
    '貼り付けエラーのテーブルで「プロパティが見つかりません」エラーになるのを回避
    If tdf.Name = "貼り付けエラー" Then
    
    Else
        'システムテーブルで「プロパティが見つかりません」エラーになるのを回避
        If (tdf.Attributes And dbSystemObject) = 0 Then
            If tdf.Properties("OrderByOn") = True Then _
            Debug.Print tdf.Name & "---" & tdf.Properties("OrderByOn")
        End If
    End If
  Next tdf

error1:
'  Debug.Print tdf.Name & "---" & Err.Description

  dbs.Close
  
  MsgBox "終了しました。"

End Sub

'########################################################

'テーブルの「並べ替え実行プロパティ（OrderByOnプロパティ）」

'がONかOFFかを調べるコード

'########################################################

Sub tbl_orderby_chk()

Dim dbs As DAO.Database

Dim tdf As TableDef

On Error GoTo error1

Set dbs = CurrentDb

For Each tdf In dbs.TableDefs

'貼り付けエラーのテーブルで「プロパティが見つかりません」エラーになるのを回避

If tdf.Name = "貼り付けエラー" Then

Else

'システムテーブルで「プロパティが見つかりません」エラーになるのを回避

If (tdf.Attributes And dbSystemObject) = 0 Then

If tdf.Properties("OrderByOn") = True Then _

Debug.Print tdf.Name & "---" & tdf.Properties("OrderByOn")

End If

Next tdf

error1:

' Debug.Print tdf.Name & "---" & Err.Description

dbs.Close

MsgBox "終了しました。"

End Sub

上記のプログラムを改変して、直接、「並べ替え実行プロパティ（OrderByOnプロパティ）」をOFFにしてしまってもいいと思います。

　　
　　
・適度なデータベースの最適化
　　
　　
・テーブルデザインで「空文字の許可」をしない
　　
　　
・LANの速度をGIGABIT（1000Base-T）にする
僕の使用している環境では、100MbpsのLANで、数十万件のテーブルをもつ複数のmdbを同時に扱い、また、25台くらいのクライアントパソコンからmdb共有していても、十分な速度が出ているので特にGIGABITにする必要はないのですが、ここでのTipsを試しても速度が出ないのでしたら、試す価値があると思います。
以下のQ&Aサイトの「sttkhr123さん」のご回答によると、体感速度が2倍くらいにはなるそうです。

「・Accessでの抽出が遅いので早くする方法はないでしょうか？」
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1032948365

ちょっと前まではGIGABIT LANのHUBは値段が高かったのでなんとも微妙でしたが、最近少し安くなったのでクライアントPCの台数が少ない場合は、検討しても良いかもしれません。

なお、LANが速いとAccesssも速くなる理由は、恐らくですが、「Accessは1レコードを読み込むのでも、先に、テーブルのすべてのデータをメモリに読み込む仕様」だそうだからだと思います。
でも実際の挙動はそこまで・・・遅くない気がするんですが・・・。
何故かというと、例えばファイルサーバ上の200MB以上あるmdbファイルを覗きに行くリンクテーブルでも、そこからクエリにて「数十万件以上あるうちの数十件」を読み込むのでも、100MbpsのLANでも1秒くらいだし、メモリの増加量も1000mB以上になるのかなと思いきや、実際にはそうはなっていないので・・・。
Access2000での実態ですけど、このへんはよくわかりません。
Access97のときの挙動はわかりませんが、Access2000では、Web上でよく言われる「遅い、遅い、メモリ食う」という状況には・・・確かにメモリは食うことは食いますが、ぎゃあぎゃあ言われるほど思ったより多く食ってないし、また、遅くもなりません。
「みなさん本当にAccessの基本をちゃんとおさえてる？」とどうしても思ってしまうのですが・・・。
なので、よくわかりません。
　　
　　

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
ここまでは、システム全体のことです。また、mdbファイルの場合だけです。主に、「ネットワーク越しのリンクテーブル」を速度低下させないTips（Access2000の時からの既知の問題の解決）です。
以上の項目は、基本的にはやっておかないと、Access2000では、クエリのチューニング（ってほどでもないですね。ただの見直しです。）をしても速度が上がらないことが多いので、必ずチェックしておきます。（2002、2003もかも）
（設定するかしないかは自由ですが、最低限、チェックだけはしておきます。）
以降は、クエリの見直しに関することですが、速くなるかならないかはその時その時の状況にもよります。（あと、2007でmdbファイルを動かすときの参考にはなるかもしれません。）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

・リンクテーブルのリンク先をネットワーク越しからローカルに変える（一時テーブルなど）
　　
　　
・リレーションの本数を減らす、非正規化、など
　　
　　
・オプティマイザ？
　　
　　
・Rushmore
　　
　　
・完全一致が一番速い。次が前方一致。部分一致は遅い。
　　
　　
・複数条件なら完全一致で探せるものをできるだけ先にもってくる
　　
　　
・条件式にNullや""が入ると遅くなることがある
　　
　　
・完全一致（＝）か前方一致（Like '××*'）で Ture・False を -1や0にして遅かったらTure・False に戻す
　　
　　
・ScanPlans関数
　　
　　
・<>0 >0 などを使って遅いようならBetweenなどを使うほうが速い
　　
　　
・複数条件でNullが含まれて遅いなら Null以外を使うか値はすべて埋める
　　
　　
・複数条件でNullが含まれて遅いなら日付や時間、他のキーで取り出すことを考える
　　
　　
・差分を求めるときNullを含めて遅いならNullを使わなくて済む代替法を
　　
　　
・あえてダミーの数値型の列を作り、それを抽出する条件を完全一致や前方一致で加えてみる
　　
　　
・Orを増やさない
　　
　　
・「Like テキストボックス名」を使わない。リテラル値や、DAOならQueryDefを使う
　　
　　
・条件に使う列の順序の入れ替え
　　
　　
・3つ以上のテーブルをリレーションさせる場合、テーブルの順序を入れ替える
　　
　　
※関連記事
『 Access2000・100MbpsLAN Pentium3 の「ネットワーク越しのリンクテーブル」の開く速度が遅いときの対処法（Access2000のときからあった既知の問題）』