私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part20
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
temporaryが遅いとな。
ストレージエンジンはMYISAM、MEMORY?
テンポラリーテーブルに限った話ではないけれど
InooDBPlugingが標準になったので
初期状態で立ち上げると確かに重くはなってる気がしますね。
(DEFAULT_STORAGE_ENGINEは相変わらずMISAM?だけど）
今のハードに併せてきたんじゃないかなと予想。
ストレージエンジンはMYISAM、MEMORY?
テンポラリーテーブルに限った話ではないけれど
InooDBPlugingが標準になったので
初期状態で立ち上げると確かに重くはなってる気がしますね。
(DEFAULT_STORAGE_ENGINEは相変わらずMISAM?だけど）
今のハードに併せてきたんじゃないかなと予想。
結局皆MySQL5.5導入してるの？
俺は一応Linuxにcmakeでインストールして単純な動作確認だけはしたけど、まだ5.1使ってる
マイナーだろうけどmMeasure使ったりしてるんで
これ5.0、5.1、とインストール方法が変わるので、おそらく5.5では利用できないんだろうなと思って
cacti、munin等は試していないけれど
あと、バージョンの問題だったかもしれないけれど、ソースからインストール後起動時に何度かエラーが出て解決できなかった事もあった
5.1では一度も無かったけれど
俺は一応Linuxにcmakeでインストールして単純な動作確認だけはしたけど、まだ5.1使ってる
マイナーだろうけどmMeasure使ったりしてるんで
これ5.0、5.1、とインストール方法が変わるので、おそらく5.5では利用できないんだろうなと思って
cacti、munin等は試していないけれど
あと、バージョンの問題だったかもしれないけれど、ソースからインストール後起動時に何度かエラーが出て解決できなかった事もあった
5.1では一度も無かったけれど
500です。
チェーン店の日別店別の商品売り上げテーブルなんだが、
date date
store_id smallint
item_id mediumint
sales mediumint
って感じ。
10店舗くらいあって、指定商品が各店の売上ランキング何位にあるのかを割り出すのに
指定期間の商品別の売上順に集計したtemporary tableを作って
@i=0;
create temporary table `t1` select (@i:=@i+1)as`rank`,SUM(`sales`)as`sales`,`item_id` form `table` where `date` between 'A' and 'B' and store_id=1 group by `item_id` order by `sales` desc;
って感じで。
で、そこから指定のitem_idを条件に rank を出す。
これを店舗回繰り返す。
チェーン店の日別店別の商品売り上げテーブルなんだが、
date date
store_id smallint
item_id mediumint
sales mediumint
って感じ。
10店舗くらいあって、指定商品が各店の売上ランキング何位にあるのかを割り出すのに
指定期間の商品別の売上順に集計したtemporary tableを作って
@i=0;
create temporary table `t1` select (@i:=@i+1)as`rank`,SUM(`sales`)as`sales`,`item_id` form `table` where `date` between 'A' and 'B' and store_id=1 group by `item_id` order by `sales` desc;
って感じで。
で、そこから指定のitem_idを条件に rank を出す。
これを店舗回繰り返す。
テンポラリテーブル作成を繰り返すから、5.1よりめちゃめちゃ時間かかってしまった。
5.1だと1秒未満で5.5だと5秒以上かかった。
日付指定が変動したり、カテゴリで絞ったりで、事前に値を出しておけないので、このようなことをしてたけど、
今は日付の期間指定させないで、日別、週別、月別のサマリテーブルに順位いれて、そこから選ばせるようにしてる。
まぁ、設計や方法がアホだったと思うけど、ようは5.5のテンポラリーテーブルは遅い、ってのはここで強く感じたわけです。
ちなみに、5.1、5.5ともにInnoDB plugin でbuffer poolは5GBくらい。
tmp_table_sizeもmax_heap_table_sizeも 512MBくらい割り当ててた。
5.1だと1秒未満で5.5だと5秒以上かかった。
日付指定が変動したり、カテゴリで絞ったりで、事前に値を出しておけないので、このようなことをしてたけど、
今は日付の期間指定させないで、日別、週別、月別のサマリテーブルに順位いれて、そこから選ばせるようにしてる。
まぁ、設計や方法がアホだったと思うけど、ようは5.5のテンポラリーテーブルは遅い、ってのはここで強く感じたわけです。
ちなみに、5.1、5.5ともにInnoDB plugin でbuffer poolは5GBくらい。
tmp_table_sizeもmax_heap_table_sizeも 512MBくらい割り当ててた。
5.5のテンポラリーテーブルが遅いってのは本当なのか？
何か回避策があるんじゃないのか？
何か回避策があるんじゃないのか？
>>504
indexの付け方が悪いんだろ。
indexの付け方が悪いんだろ。
>>507
ファイルシステムはubuntuだとext4で、
Macはデフォルトです。
>>508
Indexは、
date=index
store_id,date=index
item_id,date,store_id=primary
にそれぞれついてます。
たとえなにかおかしくても、5.1と5.5でまったく同じ環境でやってるので、
どちらにも同じように事象は起きるはずですが。
5.1はOSのパッケージ管理でインストール。
5.5は遅かったので、パッケージ管理と公式サイトからバイナリ、の2種類で試しました。が、結果は同様でした。
あと、5.1で作ったテーブルをそのまま5.5で共用しました。5.5で何か変更があって互換性に問題が起きてるんでしょうかね。
ファイルフォーマットはBarracuda。
ファイルシステムはubuntuだとext4で、
Macはデフォルトです。
>>508
Indexは、
date=index
store_id,date=index
item_id,date,store_id=primary
にそれぞれついてます。
たとえなにかおかしくても、5.1と5.5でまったく同じ環境でやってるので、
どちらにも同じように事象は起きるはずですが。
5.1はOSのパッケージ管理でインストール。
5.5は遅かったので、パッケージ管理と公式サイトからバイナリ、の2種類で試しました。が、結果は同様でした。
あと、5.1で作ったテーブルをそのまま5.5で共用しました。5.5で何か変更があって互換性に問題が起きてるんでしょうかね。
ファイルフォーマットはBarracuda。
key_buffer_size というのはMyIsam用にあるインデックスを保存しておくバッファ
の大きさを指定するパラメータみたいですけど、Innodb用にはそれに該当する
パラメータは無いのでしょうか？
の大きさを指定するパラメータみたいですけど、Innodb用にはそれに該当する
パラメータは無いのでしょうか？
>>513
ありがとうございます
ありがとうございます
日付についての質問です。
year,month,dayで３つのIntegerフィールドを定義するのと、Dateフィールドを１つ定義するのとでは、
年+月または年+月+日でSelectする場合どちらが高速にできるのでしょうか？
できるだけ高速にSelectしたのです
year,month,dayで３つのIntegerフィールドを定義するのと、Dateフィールドを１つ定義するのとでは、
年+月または年+月+日でSelectする場合どちらが高速にできるのでしょうか？
できるだけ高速にSelectしたのです
year,month,dayの数字を各桁ごとに分解し、それぞれを2進数化してTextフィールドに納めるのが良い
DATE型の内部表現は3バイトの整数なんでしょ
他の型で代用するとかえって遅くならね？
他の型で代用するとかえって遅くならね？
DATEだと、毎年2月とか、毎月5日とか飛び飛びのデータを集計するのがつらい。
Y/M/Dだと、2010/12/25～2011/1/15といった、月またがり、年またがりの
データを集計するのがつらい。
どういう集計をしたいのかによって考えるべき。両方つけてもよい
Y/M/Dだと、2010/12/25～2011/1/15といった、月またがり、年またがりの
データを集計するのがつらい。
どういう集計をしたいのかによって考えるべき。両方つけてもよい
>>523
毎月5日とか10月とかは、文字列ならsubstrとかrightで抽出できそうだけど、数値のときはどうやるの？
毎月5日とか10月とかは、文字列ならsubstrとかrightで抽出できそうだけど、数値のときはどうやるの？
２月２９日の有無とか１１月３１日とか
３月３日の一週間前とか
クライアントソフト側できっちり丸められれば良いねぇ
３月３日の一週間前とか
クライアントソフト側できっちり丸められれば良いねぇ
day of monthで検索するなら、フィールドを分けておけば(日,月,年)なんてindexを張れて便利。
DBMSによっては関数インデックスが使えるからその場合はdateでもいけるけど、
MySQLだとたしか使えない。
DBMSによっては関数インデックスが使えるからその場合はdateでもいけるけど、
MySQLだとたしか使えない。
MySQLは100万件程度のレコードでの運用は問題ないでしょうか？
ユーザは20名程度です。
ユーザは20名程度です。
とりあえず、
訪問者数、日に300人前後。
収録データ数は800万ちょい超え
というショボ目のwebサイトは普通に動いてるよ。
訪問者数、日に300人前後。
収録データ数は800万ちょい超え
というショボ目のwebサイトは普通に動いてるよ。
>>534
MS製品以外は普通大丈夫
MS製品以外は普通大丈夫
>>546
MySQLってのは、MySQLの作者の娘（まいちゃん）から取った名前だよ
MySQLってのは、MySQLの作者の娘（まいちゃん）から取った名前だよ
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
mysql スレッド一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [89%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [89%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について