> 明けましておめでとうございます。

おめでとうございます。
今年もよろしくどうぞ（って初めての発言なんですけど・・・）。

> > ＜驚いた点＞
> > 　データベースのことはよく分かってません。だからだと思います
> > 　が、インデックスの偉大さに驚きました。
> > 　フィールド数３０の table1 とフィールド数６の table2 を LEFT
> > 　JOIN を使って SELECT したら、 table2 のキーになるデータに
> > 　Index を付けなかった場合で 8 分 30 秒。Index を振った場合、
> > 　21 秒。なんともびっくりです。ちなみに、table1 には 600 件。
> > 　table2 には 8000 件ほどのデータが入っています。
> > 　Index っていったい何なんでしょう？^^;

Indexがあるとなし、また効果的なIndexづけができているかいないかによってパ
フォーマンスって猛烈に変化しますよね。
たとえば5万レコードのテーブルに3万レコードのテーブルをLEFT JOINした場合だ
と、それこそ本当に同じプログラムかと思うほどですよね。
WHERE句で頻繁に参照されるものはIndexつけるといいです。

Indexっていろいろとあるようですが、たとえばクラスター化Indexなどと呼ばれ
るものは選択されたテーブルそのものを物理的に移動してしまって管理してます
（これはMS SQLの場合です）。
移動というのはテーブル内部のレコードの並び方を物理的に整理してしまうこと
です。
通常のIndexはディスク領域上にIndexを記憶する領域を確保して、ここにIndexの
データを保存。
選別操作を行う前に（テーブルスキャンを行う前に）まずIndexをスキャンすると
いう仕組みです。

チューニングに徹すると、たとえばデータベース本体と別のセグメント上に配し
て、マルチI/Oスレッド上で検索作業を行わせたりするようです（相棒がチューン
したシステムが目覚しく高速化してました）。
ただやたらIndex作るとディスクを圧迫するし、自動的に最適なIndexを選ばせる
とかえって遅くなったりするケースもあります（下手をするとストアドプロシー
ジャ内で明示的に適用するIndexを指定する羽目になったり、、、）。
なんかIndexとの格闘になっちゃいますよね・・・
いつも悩んでます。

> > ＜質問＞
> > 　みなさんは MySQL を「うにくす」から使うことが多いのでしょう
> > 　か？σ(^_^)は今、Win から使用するアプリを作成しています。現
> > 　在 ODBC を使用していますが、他に方法は無いんでしょうかね？

うー、、、ODBC(=OLEDB?)ぐらいしか思いつきません。
しかしOLEDBって遅いとか馬鹿にされますけど言われるほど遅いんでしょうか。
小さいシステムだと結構きびきびと動いてくれています。