毅です
補足。

takeshi> mysql> explain select count(*) from Test_all_tab where lotno like 'D15A0%';
takeshi> の結果をみると、だいたい妥当な感じです。
takeshi> で MySQL の場合、like を使用すると、それの正当性をいちいち
takeshi> チャックして回ります
"チェック"のまちがいです

takeshi> すなわち単に数え上げているわけでなく、内部では verify しているようです
takeshi> で、MySQL3.22 のルーチンでは、今回のような場合において、
takeshi> MySQL は 遅くなる事がわかりました。(monty は限られた場合と言ってます)
takeshi> TcX にあげたら、これは、3.23 で fix されます。

特殊な場合とは、クエリを行うためにインデックスツリーだけを使うことができない、
という状況らしいです。
だからこれはうまくインデックスが使用されていない...

takeshi> 私は empress の特徴をつかんでいないのですが、
takeshi> ↓の場合、(columnは何を指す？) Empress は速くなるそうです。
複数の項目を検索すると、エンプレスは'遅く'なるはずだそうです

takeshi> "Do you happen to know how Empress saves data? If they save everything 
takeshi> by column, this could explain why this is fast. This would of course mean
takeshi> that if you retrieve a couple of columns of data things would get
takeshi> extremely slow."


takeshi> mysql> show status;
takeshi> からは、(ハマさんや民斗さんの言うとおりIOで、)

もしかしたら、Linux Thread や libc の問題かもしれませんが、
現状ではそこまでは断定できにくいです。
# そのデータの複製があれば少しは手がかりになるかも. (←談: monty)

takeshi> また、IOのために遅くなっているので、key_buffer を増やします。
takeshi> (monty は empress にあたえているメモリーと同じぐらいにするとどうなの？
takeshi> 　と言ってます -O key_buffer=16M

(同じって、全体でだから、)
1スレッドに まずは key_buffer=16M ぐらいから試されてみては？

 村上 毅  takeshi@xxxxxxxxxx
 PGP fingerprint = 45 5D 54 12 B4 55 77 7F  D4 52 66 EC 03 3F 1B E9
 [ http://www.softagency.co.jp/mysql/ ]
 [ MySQL ML: mysql-help@xxxxxxxxxx ]