テーブルの分割(昨日の続き)。
MySQLのMERGEテーブルには
primary keyが定義できないということで。
一応パフォーマンス測定はしてみたものの、
そりゃ、一意にできないんだもの。遅くなるわな。
という結果でした。
MERGEテーブル案、却下。
別な方法として、ビューを使ってみました。
分割したテーブルは昨日のまま。
結果1996〜結果2006です。
で、
create (or replace) view 結果 as
select * from 結果1996
union
select * from 結果1997
…
union
select * from 結果2006
という感じ。
「こりゃ、unionだから遅いだろ」
というのは重々承知。
実際にパフォーマンスを測ってみたら
何十倍?何百倍の違いが出ました。
しかも、
分割テーブルのcharがビューだとすべてvarcharになってるし。
intがすべて11バイトになってるし。
doubleがすべて22,1になってるし。
show create view を見たら、大変なことになってるし。
ビューはもっと賢い使い方しましょう(失)
-------------
とりあえず、今のところ
テーブルを分割することによるパフォーマンス向上は
期待できませんという結論で。
元テーブルがもっとでかかったりすれば
多少は期待できるのではないでしょうか。
ちなみに、MySQL5.1では
パーティショニングの機能が搭載されています。
が、まだ5.1系はベータ版。
実際に導入するのはもう少し時間がいるかと思われます。
primary keyが定義できないということで。
一応パフォーマンス測定はしてみたものの、
そりゃ、一意にできないんだもの。遅くなるわな。
という結果でした。
MERGEテーブル案、却下。
別な方法として、ビューを使ってみました。
分割したテーブルは昨日のまま。
結果1996〜結果2006です。
で、
create (or replace) view 結果 as
select * from 結果1996
union
select * from 結果1997
…
union
select * from 結果2006
という感じ。
「こりゃ、unionだから遅いだろ」
というのは重々承知。
実際にパフォーマンスを測ってみたら
何十倍?何百倍の違いが出ました。
しかも、
分割テーブルのcharがビューだとすべてvarcharになってるし。
intがすべて11バイトになってるし。
doubleがすべて22,1になってるし。
show create view を見たら、大変なことになってるし。
ビューはもっと賢い使い方しましょう(失)
-------------
とりあえず、今のところ
テーブルを分割することによるパフォーマンス向上は
期待できませんという結論で。
元テーブルがもっとでかかったりすれば
多少は期待できるのではないでしょうか。
ちなみに、MySQL5.1では
パーティショニングの機能が搭載されています。
が、まだ5.1系はベータ版。
実際に導入するのはもう少し時間がいるかと思われます。
このネタへのコメント:
コメントはありません。