よくよく考えてみるとこれがやっかいな問題で。。
以前mysqlの結合数上限に引っかかった時，その上限が32bit環境によるものだ，と書いたのですが，また今回はまっちゃいました。
今度はサブクエリのネスト数制限にひっかかってしまいました。当初の開発環境だとfedora 32bitだっため特に気にすることもなかった（本番環境も32bitのため）のですが，ある時サーバの入れ替えで64bit環境に変更されていたのです。
まあ，いまから入れなおしって意味では64bit環境にしたいという欲求はわかるんだけど，本番環境と違ってきてしまうわけで，それはまずいｗ
実際，64bit環境でとおったーーと思ったsqlを本番環境にもってったところ，見事に動かず，原因判明するのにちょっと時間がかかってしまいました。
一番いいのは並行して32bit環境を残して，そちらでテストするようにしたほうがよいのかもしれません。というか，そうしないとまずいｗ
64bitの優位性という意味ではメモリ空間が広いとか，CPU性能が若干32bitと比べてよいとかあるけど，利用方法によっては32bitより64bitの方がパフォーマンスが落ちることもあるみたいだし，互換性の問題もあるし，使う方からみたらどちらがいい，というのは一概にはいえなさそう。
ただ，大容量メモリ時代のことを考えると結局は64bitに移行していくのは間違いないのだろうし，実際にモノづくりに携わる方からみると使えるリソースが増えるのはいいことだし，どちらかというと作り手や売り手の問題なのかもしれないなぁ。
今回の64bit移行は移行自体は全く不要で腹立ちますｗが，考えさせられるいい機会にはなったような気がする。
仕事上はつぶして32bitにしたいところだけど，検証のために残したいという思いもあるので，結局２本だてか。。。。(;´д｀)トホホ
人気のある記事
- Visual Studioでsubversion – AnkhSVN
- 無料オンラインストレージ比較 – quanp vs dropbox vs sugarsync
- osqleditでつながらないときにやったことメモ – oracle10g & windows7(xp-mode)
- grubコンソールで止まりbootできない – CentOS 5.4 grub.conf
- google アドレス帳 , iPhone, outlook, becky!間での連絡先共有 その２