MySQL4.0からのバージョンアップ時のハマリ点〜不正な日付の扱い〜 - sakaikの日々雑感～(T)編
とっくに EOL となっている MySQL 4.0 を未だに使い続けている会社もそれなりにまだあるようです。MySQLは バージョン 4.0 と バージョン 4.1 の間に文字コードの取り扱い変更を含む大きな変更が為されているために、バージョンアップに二の足を踏んでいるという心理があるのでしょう。4.0のままでもちゃんと動いているし！ で、実際にバージョンアップの際に文字コード（文字化け）についてはこれまで多くの書籍や記事などでも喧伝されてきたので、上手にバージョンアップするノウハウも溜まっていると思いますが、もうひとつ意外なハマりどころに「日付の扱い」があります。 （１）MySQL 4.0 では日付のチェックがちょっとルーズ （２）MySQL 5.1 (たぶん 4.1以降）ではちゃんとチェック MySQL 4.0 での日付チェックについてもう少し詳しく説明すると、MySQL 4.0 では
あらかじめインデックスカラムでソートしておくことによるINSERT速度の差に関する調査(4)〜InnoDB編 - sakaikの日々雑感～(T)編
昨日の調査結果にあとから追記したのですが、【昨日の調査は MyISAM エンジンでの結果です】！ （図らずもそうなってしまいました(^^;)） ということで InnoDB での追試。諸条件は昨日とまったく同じ。 ただしテーブル生成を行う際に、CREATE TABLE文の最後に ENGINE=InnoDB を追加したのみ、です。 MyISAM の結果を見て「やっぱりソートしておいたほうが速い、なるほどね」と思っていた私には、驚くべき結果がでました。 結果(InnoDB) 件数 unsorted sorted 10,000 0.6173 0.6070 20,000 1.1663 1.3037 50,000 2.9893 2.9497 100,000 6.0137 6.1367 200,000 12.4970 12.8287 300,000 19.8357 19.8163 400,000 2
あらかじめインデックスカラムでソートしておくことによるINSERT速度の差に関する調査(2) - sakaikの日々雑感～(T)編
前回のあらすじ ２カラムを持ち、1カラム目だけにインデックス（プライマリーキー）を作成したテーブルに対して、予め1カラム目の値でソートしたINSERT文群と、ソートしていないINSERT文群を与えて、処理に要する時間を測定した。 INSERT文群の件数は 1万、2万、5万、10万、50万、約58万 を測定。 ソートしていなかったものが 10万から50万の間で大きく時間を要するようになった（ソートしてあるものはそれほどでもない） とりあえず 10万から50万の間がどうなっているのかをもう少し細かく見たいので、20,30,40万について測定を行いたくなった 前回のグラフは以下。 今回の結果 以下のとおりとなった。20万, 30万, 40万件について追試を行い、10万と50万については前回の測定値を使用した。 感想 やっぱりまっとうに（なめらかに）所要時間が増え続けていますね、ソートしていないも
あらかじめインデックスカラムでソートしておくことによるINSERT速度の差に関する調査(1) - sakaikの日々雑感～(T)編
たくさんのデータをINSERTする際の所要時間について思うところがあったので調べてみました。今回のテーマは「インデックス」です。 INSERTする際にINDEXを構築しながらデータを登録していくわけですが、これが予め並んでいれば、INDEX生成にかかる処理負担が減るのではないか、という発想です。シンプルに、以下のテーブルに対して、ランダムな値のINSERT文を生成し、（１）ランダムに発生したままのもの （２）カラム１の値でソートしたもの の２つについて所要時間を計測しました。 テーブルは、2カラムを持ち、1カラム目にプライマリーキーが設定されているだけの非常にシンプルなものです。 CREATE TABLE tb02a ( col1 varchar(128), col2 varchar(128), PRIMARY KEY (col1) ); 件数 1万、2万、5万、10万、50万、58万(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
