は？
あれを経験しているからこそさっさとかえるべきだろ？

>>351
まあ判っているとは思えないな。ｗ

2007年に入ってから1回しかupdateしてない4.1系列よりは
ほぼMonthlyでupdateされてる5.0系列の方がいいと思うよ。

5.0はEnterpriseでサブスクリプション契約になったから
それだけ品質には気を使うようになってる。

B.1.1. Changes in MySQL 4.1.24 (Not yet released)
B.1.2. Changes in MySQL 4.1.23 (12 June 2007)

C.1.1. Release Notes for MySQL Enterprise 5.0.52 [MRU] (Not yet released)
C.1.2. Release Notes for MySQL Enterprise 5.0.50 [MRU] (19 Oct 2007)
C.1.3. Release Notes for MySQL Enterprise 5.0.48 [MRU] (27 August 2007)
C.1.4. Release Notes for MySQL Enterprise 5.0.46 [MRU] (13 July 2007)
C.1.6. Release Notes for MySQL Enterprise 5.0.44 [MRU] (21 June 2007)
C.1.7. Release Notes for MySQL Enterprise 5.0.42 [MRU] (23 May 2007)
C.1.8. Release Notes for MySQL Enterprise 5.0.40 [MRU] (17 April 2007)
C.1.9. Release Notes for MySQL Enterprise 5.0.38 [MRU] (20 March 2007)
C.1.11. Release Notes for MySQL Enterprise 5.0.36 [MRU] (20 February 2007)
C.1.12. Release Notes for MySQL Enterprise 5.0.34 [MRU] (17 January 2007)

>>350
いや知ってるが文字コード云々言ってる連中の大半は3.xあたりの知識のままで
運用しようとしてるだけでしょ。
（つか当時のことを知っていれば「いまどのバージョンが安定してる？」なんて聞き方はしない）

まあエンコディング周りは鬼門だからなぁ。
サロゲートペア対応してないのが問題っていうならその通りだし、
将来対応したときに問題が起こりうるってのはそうだと思うけど。

>>353
裏返せばそれだけ安定していないって事だけどなｗ

>>355

その通り安定してないんだけど、それは4.1もいっしょだよ。
新機能でない限りほどんどのバグが4.1、5.0、5.1で共通。
5.0 Enterpriseならバグ報告すれば翌月直るけど、5.0 Community、
4.1は同じバグが長期間放置される。だから5.0 Enterpriseオススメ。

MySQL ABはEnterpriseのパッケージを契約顧客にしか配ってないけど、
結局GPLなんでミラーされてしまっている。
http://mirror.provenscaling.com/mysql/

で、結局開発する時はどの環境が無難なの？
自分は昔から4.0.26だけど。

>>359
各値がクォーテーションで囲まれていないからでは？

$sql をダンプしてみりゃ一発ではないか

文字列を長さ順でソートしようと考えています。
varchar に対して length(), char_length() を行うとして、
length()の場合は、文字列と一緒に格納されいているバイト数を返すだけだから高速
char_length()の場合は、マルチバイトを考慮して文字数を数えるので低速
という認識なのですがあっていますかね？

>>363
多分あってるけど実測した結果を見たことは無いな。
適当に数十万レコードくらいでっちあげて試験してみたら？
レポート楽しみに待ってます。

>>364
確かにやってみれば済むことですね。
今度やってみて結果書きますね。

気にするべきでない
ID詰めるのはちまちまupdateすりゃできるけど
他のテーブルの外部キーになっていればそれも無理

削除されたものも含めて「一意」なんだ、と思うべき。
番号表示を気にしたいなら別のカラムでも作れ。

一度に大量（100や200）のクエリを実行したとして
速度的な影響って出ますか？

某所で「何度も実行するべきではない」っと聞いたので
気になっているのですが、調べる術がありません。。

そら少ないより多いほうが影響するでしょ。
それにクエリの内容によって影響も変わる。

例えばprimary keyによるSELECTを大量に発行してもたいしたことないし、
1回のクエリで途方もない時間がかかる可能性もあるし。

更新系のクエリかどうかによっても違うし。

つかやってみれば分かるでしょ。

>>375
ありがとうございます。とりあえずWHEREによるSELECTをしました。
元データ1万件に対してWHEREで対象となるキーを抽出してSELECT。
これをPHPを使い、50回・100回と繰り返し処理をさせました。

ローカル環境でやりましたが、特に体感速度は変わりません。
これ以上の条件でやった場合はどうなるかわかりませんが、
サーバダウンするほどでもないので、気にすること無いですね。

1プロセスで繰り返し実行しても分からんでしょ。
20個ぐらい多重かけないと。

InnoDBからMyISAMに変換するにはどうすればいいでしょうか？
MyISAMからのInnoDBへはダメとは書いていましたが、

変換しなくても、mysqlダンプしてから、
InnoDBをMyISAMにして、リストアすればいいのでしょうか？

この場合、InnoDBで使っていたゴミはどこかに残っているのでしょうか？

ダンプしてdatabase作り直してリストアだろうね。
ところでゴミって例えばどんな？

ダンプして、テーブルを全部削除して、
テーブルのengineとdefault charsetを目的の値にしてから、
インポートしました。by phpmyadmin

ゴミというのは、
/var/lib/mysqlにある、

ib_logfile0
ib_logfile1
ibdata

です、これはInnoDBを使ってなければ不要なのでしょうか？

alterコマンドというのがあるんですね、
勉強になります、ありがとうございました。

すさまじくダサいテーブル名/カラム名だな。
1. ordernum(英語)とmise(ローマ字)が混じってる
2. kokyakuテーブルのPRIMARY KEY(と思われるもの)がkyaku。普通はkokyaku側はid、uriage側はkokyaku_id。
3. salseじゃなくてsales
ってのが。
ダメSIの臭いがプンプンするぜ。

SELECT u.mise, u.kyaku, u.uriageYMD, k.kyakumei, k.kakari, s.kakarimei FROM uriage u INNER JOIN kokyaku k ON k.kyaku = u.kyaku INNER JOIN salse s ON k.kakari = s.kakari;

まぁあくまでもここに例に出す為に即興で作った名前ですから… w

何はともあれ、m(__)m　です。 w

>>393
即興でこれかよ!
そっちの方がやべーYO!

たかが1万件ごときでそんなに重くなるはずがない。
インデックスの付け方が悪い。show create tableさらせ。
あと397の言うとおり、4.0.20は捨てろ。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

　　　　【　あなたのタイピングどのくらい！？　】　　　　　　　　　　　　　　2007/11/21　配信

　制限時間内に表示される画像内の、数字やアルファベットを次々とタイプ入力していく。
あなたのタイプ成功率が刻々と表示されていく。また、その時々のランキングにも表示さ
れていく。都道府県別のランキングもあれば、それぞれ友達と好きなチームを作り競い
合うチーム別ランキングもあって楽しめれる！

　また、タイプが成功したものはそのまま、「 国別対抗オンラインクリックゲーム 」の日本
チームのクリック数に貢献される。数々の激戦を戦い抜いてきた日本チームも、現在は
強敵ハンガリーチームに続いて第２位となっている。タイプの練習がそのまま日本チー
ムの優勝に貢献するかも！？あなたもぜひやってみては？

参加するには各種のツールを使う方法もあるが、まずはアクセスするだけでサイトから
簡単にできる「 小町 」をお試しください。なれてきたら各種ツールを試すのも楽しい。

タイプ入力サイトその１「 小町 」
　　http://f106.dyndns.org/komachi/cgi/acsupporter/supporter.cgi?m=ff

「 国別対抗オンラインクリックゲーム 」については、日本チームのオフィシャルサイトで。
　　http://clickjapan.jp/

　　※上記サイトはすべて「 国別対抗オンラインクリックゲーム 」日本チームの有志の
　　　　方達の運営で、すべて無料です。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆