柴垣さん、こんにちは。池田と申します。

例えば、こんな感じのテーブルに適当にデータを突っ込んで、
CREATE TABLE t1 (c1 INT NOT NULL, UNIQUE INDEX (c1)) TYPE=HEAP;

EXPLAINをすると以下のようになります。
mysql> EXPLAIN SELECT c1 FROM t1 ORDER BY c1\G
*************************** 1. row ***************************
        table: t1
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 5
        Extra: Using filesort
1 row in set (0.00 sec)

HEAPテーブルではB-Treeインデックスではなく、ハッシュインデックスが使用されています。
つまり、"Extra： Using filesort"の示すようにORDER BYではソート処理が発生します。

このソート処理による性能低下がどれくらいのものであるかは、ソート対象のレコード数、
即ち、そのSELECT文で返される結果の行数がどれくらいあるのかに依存すると思います。

HEAPテーブルの利用そのもので言えば、100MBを超えるサイズのHEAPテーブルの利用事例なども
あるようですし、数MByteということ自体は問題ないのではないでしょうか。

HEAPを使わない場合にはMyISAMを使うのではと思いますが、
やはり一度、実際に測定してみたほうがいいのではと思います。

あまりお役に立てずに済みません。

柴垣 wrote:
> 柴垣です。
> 
> 　MyISAMのHeapテーブルを使用するつもりなのですが、マニュア
> ルに、
> 
> 「次のエントリを順番に検索できない（つまり、インデックスを
> 使って ORDER BY を実行できない）。 」
> 
> と記述してあります。
> 　つまり、ある程度のサイズがあって、「order by 」句が含まれ
> るような用途には適していないのでしょうか。
> 　また、スピード等の観点からいって、どの程度のサイズまでが
> 運用に適しているのでしょうか。
> 
> 　今回の環境は、バージョン3.23.55nt WindowsXP です。システム
> 変数では、max-heap-table-size が、16777216 で、予定している
> Heap テーブルのサイズは、最大で、数Mbyteなのですが。
> 
> 
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
>  柴垣　顕郎 akiro@xxxxxxxxxx
> 
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
> 


-- 
Tetsuro Ikeda, Intern Development & Support
MySQL Inc, www.mysql.com
Office: +1-206-336-2030   Mobile: +1-206-661-4293
Are you MySQL certified?  www.mysql.com/certification