元スレMySQL 総合 Part20
mysql覧 / PC版 / みんなの評価 :
前へ
501 = :
temporaryが遅いとな。
ストレージエンジンはMYISAM、MEMORY?
テンポラリーテーブルに限った話ではないけれど
InooDBPlugingが標準になったので
初期状態で立ち上げると確かに重くはなってる気がしますね。
(DEFAULT_STORAGE_ENGINEは相変わらずMISAM?だけど）
今のハードに併せてきたんじゃないかなと予想。
503 = :
結局皆MySQL5.5導入してるの？
俺は一応Linuxにcmakeでインストールして単純な動作確認だけはしたけど、まだ5.1使ってる
マイナーだろうけどmMeasure使ったりしてるんで
これ5.0、5.1、とインストール方法が変わるので、おそらく5.5では利用できないんだろうなと思って
cacti、munin等は試していないけれど
あと、バージョンの問題だったかもしれないけれど、ソースからインストール後起動時に何度かエラーが出て解決できなかった事もあった
5.1では一度も無かったけれど
504 = :
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 を出す。
これを店舗回繰り返す。
505 = :
テンポラリテーブル作成を繰り返すから、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くらい割り当ててた。
506 = :
5.5のテンポラリーテーブルが遅いってのは本当なのか？
何か回避策があるんじゃないのか？
507 = :
OSとファイルシステムは同じ？
508 = :
>>504
indexの付け方が悪いんだろ。
509 = :
>>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。
511 = :
個人情報を晒すのは御勘弁ください。
512 = :
key_buffer_size というのはMyIsam用にあるインデックスを保存しておくバッファ
の大きさを指定するパラメータみたいですけど、Innodb用にはそれに該当する
パラメータは無いのでしょうか？
513 = :
>>512
innodb_buffer_pool_size
インデックスもテーブル本体もこれ
514 = :
>>513
ありがとうございます
515 = :
日付についての質問です。
year,month,dayで３つのIntegerフィールドを定義するのと、Dateフィールドを１つ定義するのとでは、
年+月または年+月+日でSelectする場合どちらが高速にできるのでしょうか？
できるだけ高速にSelectしたのです
516 = :
試した方が早くね？
517 = :
Dateフィールドを１つ
520 = :
DATE型の内部表現は3バイトの整数なんでしょ
他の型で代用するとかえって遅くならね？
521 = :
DATEだと、毎年2月とか、毎月5日とか飛び飛びのデータを集計するのがつらい。
Y/M/Dだと、2010/12/25～2011/1/15といった、月またがり、年またがりの
データを集計するのがつらい。
どういう集計をしたいのかによって考えるべき。両方つけてもよい
523 = :
8桁の数値にしてるわ。スッゲー楽。
524 = :
>>523
毎月5日とか10月とかは、文字列ならsubstrとかrightで抽出できそうだけど、数値のときはどうやるの？
525 = :
>>521
> DATEだと、毎年2月とか、毎月5日とか飛び飛びのデータを集計するのがつらい。
5日締め毎に集計って事ですか？
何が辛いのか分からないので詳しく教えて下さい
526 = :
２月２９日の有無とか１１月３１日とか
３月３日の一週間前とか
クライアントソフト側できっちり丸められれば良いねぇ
527 = :
day of monthで検索するなら、フィールドを分けておけば(日,月,年)なんてindexを張れて便利。
DBMSによっては関数インデックスが使えるからその場合はdateでもいけるけど、
MySQLだとたしか使えない。
530 = :
トリガーでも使えば
533 = :
トリガでできそうですね！勉強してみます。
ありがとうございます。
534 = :
MySQLは100万件程度のレコードでの運用は問題ないでしょうか？
ユーザは20名程度です。
535 = :
とりあえず、
訪問者数、日に300人前後。
収録データ数は800万ちょい超え
というショボ目のwebサイトは普通に動いてるよ。
536 = :
innodbも定期的にoptimize tableやったほうがいいの？
537 = :
>>536
大量DELETEした場合はやっておいてもいい。
やらんでも困ることはまずない
538 = :
>>534
MS製品以外は普通大丈夫
539 = :
>>357
ありがと！
540 = :
ごめん>>537だ
541 = :
絶対に許さない
546 = :
MySQLってなんだよ
さっぱり解からん
サルにも解かるように教えてくれ
547 = :
サルには必要ねーよ
548 = :
>>546
MySQLってのは、MySQLの作者の娘（まいちゃん）から取った名前だよ
550 = :
>>534
運用というか分析系には弱いね
そういう用途ならSQLServerのほうが向いているかと
予算がカツカツとかいう事情があるならPostgresでも入れるべし
みんなの評価 :
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 ○
トップメニューへ / →のくす牧場書庫について