あと、CRecordset::Openに引き渡しているnOpenTypeは、AFX_DB_USE_DEFAULT_TYPEで
dwOptionsは特に指定していません。

「CRecordset」は確認できていないのですが、ODBCSDKでは、ODBCドライバーからの
メッセージを取得できます。
　関数名　「SQLError」です。
　「CRecordset」にもあると思いますが、見つかっていません。
SQLの構文等のミスも見つけることができるので、便利です。
調べてみて下さい。

「CRecordset::MoveNext」
　　は、アクセルのデータ操作を想定している可能性はありませんか。
アクセルとmySQLではSQL構文の仕様に食い違いがあると思います。
僕も、オラクルとの食い違いに苦労しました。

返信有難うございます。

アクセルと言うのはMicrosoft Accessの事だと仮定して書くと
ODBCからのエラーに関してはCRecordsetの場合、CDBExceptionで例外がスローされると
思います。今回例外を補足するようにしていますが、特にエラーが発生しているという
事は無いと思います。少なくとも例外が補足される事はありません。

MySQLのC APIには結果を一気にクライアントに持ってきて処理するAPIと
一行ずつクライアントに持ってくるAPIの両方があります。
ODBCドライバが一気に持ってくる方と同じ実装している為に
上記のような動きをしているのであれば、外部からどうこうは無理ですね。
ODBC側の設定オプションに該当するような物が有れば、それが影響しているかも
しれませんけれど。
CRecordsetの動きと言うわけではないのかもしれません。

あうあう。

>アクセルと言うのはMicrosoft Accessの事だと仮定して書くと

と書いておきながらAccessに全く触れてなかった。
うーん、これに関しては何ともわかりませんね。
裏の動きはどうあれ、表向きはMoveNextで次のデータが取れるわけで
裏で一気に取ってきて小出しに引き渡すのか、
その都度取ってきて引き渡すのかの差ですからメモリの問題さえなければ、
使う方からは同じ動きに見えますからね。

MSDNの説明を見る限りではCRecordsetその物はODBCを意識して作られた物だと
いう風に理解していたんですが、Accessを意識したつくりなのかなぁ。
Accessっぽいインターフェイスで使えるようにと言う話ならわかる気はしますけれど。

> アクセルと言うのはMicrosoft Accessの事だと仮定して書くと
すみませんあたりです。

> MySQLのC APIには結果を一気にクライアントに持ってきて処理するAPIと
> 一行ずつクライアントに持ってくるAPIの両方があります。
MSDNライブラリーを調べてみましたら、「CRecordset::MoveNext」で正解みたいです。
ただ「 一行ずつ」なのかどうかは「GetRowsetSize( )」で調べるみたいです。
一行ずつにしたい場合は、OPENする前に、
SetRowsetSizeで1行に設定すればいいみたいです。
EOFはIsEOF( )でわかるみたいですね。

>dwOptionsは特に指定していません。
なのでいいと思います。

あと「結果を一気にクライアントに持ってきて処理する」は、
「CRecordset」では「バルク行フェッチ」といっているみたいです。

>MSDNの説明を見る限りではCRecordsetその物はODBCを意識して作られた物だと
>いう風に理解していたんですが、Accessを意識したつくりなのかなぁ。
>Accessっぽいインターフェイスで使えるようにと言う話ならわかる気はしますけれど。
すみません、僕も「ODBCを意識して作られた物」と理解しています。
ただ、「CRecordset::MoveNext」が自動的にSQL文を作成して1行ずつフェッチして
いくように勘違いしてしまいました。
>MySQL Administratorでコネクション情報を見ながら
>出力ファイルの作成状況を見ていると私の予想と違い、最初のOpenで
>全てのデータを返却しようとしているように見えます。
えっとー、SQL文で一致したすべての行を指定していればそうなるものと理解してます。
それは、「MySQL」のクライアント側ソフトでSQL文を実行してみるとわかると
思います。

すいません、土日は仕事の方に手を出せる状態では無いので返事が遅れました。

>えっとー、SQL文で一致したすべての行を指定していればそうなるものと理解してます。
>それは、「MySQL」のクライアント側ソフトでSQL文を実行してみるとわかると
>思います。

やっぱりそうなるんでしょうねぇ。
現状は仕方が無いのでLimit句を使って500000毎に取り出すような処理にしてますが、
次のSQL文を実行する時にCRecordset::Closeをすると前の内容を開放してしまって
最初から処理をやり直すらしくてオフセットを500000にして500000件取り出そうとすると
時間が倍くらい掛かってしまうと言う現象が起きています。
そのテーブルには取り出す時のソート順と一致したインデックスもつけているのに
最初の500000件を読み飛ばす為に時間が掛かっているような感じです。
ストアドプロシジャーで行うようにフェッチを意識的に行わない限りは
駄目なのかも知れませんねぇ。

CRecordsetでは、「バルク行フェッチ」は実装されていないように書いてありますね。
「バルク行フェッチ」は派生クラスを作成してそちらで実装する事になっているみたいです。
現状ではCRecordsetを生で使っているので「バルク行フェッチ」は使われていないと言う
認識なんですが、
そもそもここの認識が間違っているんでしょうか。
「バルク行フェッチ」の説明があったので、「バルク行フェッチ」無い時は１行ずつ
取り出すのだという解釈をしたんですけれど。
ちなみにCRecordset::SetRowsetSizeは、「バルク行フェッチ」でないとアサートする
とMSDNには書いてあります。
「バルク行フェッチ」を実装すれば、一行ずつ取り出せると言う話ならやってみる価値は
有りそうですけれど、MySQLがバルクフェッチに対応していたかは調べてみないと分から
ないです。

MSDNを読み返して見て思ったんですが、
１行ずつ取り出すとか言っているのはODBCドライバからの話であって
ODBCドライバには一括でデータが来ているのでは無いかと言う気がしてきました。
バルクフェッチにしてもODBCドライバから持ってくる処理を複数行一括で行うという
話なのでは無いかなと。
そうなると基本的にはクライアントにはSQLの結果は一気に送られてくると言う部分は
プログラムからはコントロールできないのではないかと言う気がしてきました。
そうなると今のLimitを使った方法しかないわけで、その動作結果からすると
MySQLも大量データになるとやはりそんなに早くないのではと言う気がしてきました。
とはいえ、C APIを直接叩く場合は、サーバーから一行ずつ取り出す為の関数があるので
その方法を使えばできるのかもしれませんが、私が調べた本にはVC++6.0を使えと
書いてあったのでこの時点で無理なのではと考えています。
VS2005で使った場合、ランタイムの関係とかでまずいのかなぁ。

>現状は仕方が無いのでLimit句を使って500000毎に取り出すような処理にしてますが、
>次のSQL文を実行する時にCRecordset::Closeをすると前の内容を開放してしまって
>最初から処理をやり直すらしくてオフセットを500000にして500000件取り出そうとする
>と時間が倍くらい掛かってしまうと言う現象が起きています。
　オラクルを扱っている方を見ていると大量のデータを扱う場合、もっと検索項目数を
増やして効率を上げてますね。
　後から項目数のふえたSQL文をみせてこれを使ってくださいと言われたことがありま
す。

>現状ではCRecordsetを生で使っているので「バルク行フェッチ」は使われていないと言
>う認識なんですが、
>そもそもここの認識が間違っているんでしょうか。
間違ってないと思います。
>「バルク行フェッチ」の説明があったので、「バルク行フェッチ」無い時は１行ずつ
> 取り出すのだという解釈をしたんですけれど。
> ちなみにCRecordset::SetRowsetSizeは、「バルク行フェッチ」でないとアサートする
> とMSDNには書いてあります。
それで正しいと思います。

>そうなると今のLimitを使った方法しかないわけで、その動作結果からすると
>MySQLも大量データになるとやはりそんなに早くないのではと言う気がしてきました。
>とはいえ、C APIを直接叩く場合は、サーバーから一行ずつ取り出す為の関数があるの
>でその方法を使えばできるのかもしれませんが、私が調べた本にはVC++6.0を使えと
>書いてあったのでこの時点で無理なのではと考えています。
うーん、フリーソフトですから速くないのかも知れません。
でも、ソフトの歴史は長いですよね。
なのでそこまで歴然とした差があるとは思えないのですが.....

その後、調査続行中。
何せ8500000件のデータをソートしてソート順にアクセスし、
特定の形式のCSVファイルに出力すると言う処理をするのに数日掛かってしまう
という状況はいくらなんでもあんまりなので何とかしないといけないのです。

とあるテーブルには出力順に一致したインデックスが作成済みです。
で、これに対して以下のようにSQL文を発行します。（ODBC + CRecordset経由）

SELECT * FROM XXXXX ORDER BY AAA,BBB LIMIT 0, 500000;

テーブルの形式はInnoDBです。
データ件数は上記の通り、8500000件あります。
テーブル上の項目は全て出力対象のもので無駄な物は有りません。

上記のSQLを発行すると直にクライアントにデータの引渡しが始まり、
今の状態だとこの引渡しだけで2時間半くらい掛かっています。
これは、DBの状態も関係しそうなので一度まっさらにしてから
再度計ってみる必要がありそうですけれど。
で、次に

SELECT * FROM XXXXX ORDER BY AAA,BBB LIMIT 500000, 500000;

が流れるとこんどは直にクライアントにデータが来ません。
2時間半くらい立った後、データが来始める状態です。
最初の直にデータが来始める部分はインデックスを利用しているわけなので
納得できますし、期待した動きです。
ところが、次のSQL文でデータがクライアントに来始めるまでに
2時間半も掛かるのがよくわかりません。
まるで500000件をスキップする為に2時間半も掛かっているように
みえます。実際にはインデックスの設定を行っているわけなので
500000件のスキップにそこまで時間が掛かるとは思えないのですけれど
私の勘違いなんでしょうか。

> １行ずつ取り出すとか言っているのはODBCドライバからの話であって
> ODBCドライバには一括でデータが来ているのでは無いかと言う気がしてきました。
> バルクフェッチにしてもODBCドライバから持ってくる処理を複数行一括で行うという話なのでは無
いかなと。

ODBC経由でのCRecordsetは通常、DBからの呼び出しは全部一括なはずです。
# ぶっちゃけ中身は単にSELECTなわけですから。

8500000件を全部一度オンメモリに置こうとしてスラッシングとか起こしてませんか？
「チューニングしたOracle」とかには勝てないとしても、MySQL自体は速いと思いますよ。

# 例えばVIEWとか自分で作れば改善されるのでは？

返信有難うございます。

>8500000件を全部一度オンメモリに置こうとしてスラッシングとか起こしてませんか？

これってMySQLの内部でと言う話なんでしょうか。
要は、WHERE文なんかでロード量を減らせば改善されると言うことであれば、
その部分の検討は行っていなかったので検討してみます。
クライアント側でスワップが起こると言う話ならLIMITで対応可能だと思うので
多分、上記の事を言われているのではと思うのですが、いかがでしょう？

試していないので憶測になってしまいますが、下記URLにあるオプションで
「Don't Cache Result」を使用してみてはいかがでしょうか。

『22.1.3.5. Connector/ODBC Connection Parameters』
http://dev.mysql.com/doc/refman/5.1/ja/myodbc-configuration-connection-parameters.html