元スレMySQL 総合 Part13
mysql覧 / PC版 / みんなの評価 : ☆
前へ
851 = :
853 :
まぁ単に
結合条件をFROM句に書いたか
WHERE句に書いたかの違いだけだと思うけど。
性能の違いはないんじゃないかな？
１のように結合条件をWHERE句にごちゃごちゃとかくよりも
２みたいにFROM句に書いたほうが
テーブルとの関係が分かりやすいのはあるかもね。
でも自分は１の方法が多いかな。
以上、末節ながら。。。
854 = :
MySQL5.1で2GBほどのデータベースをインポートしているんですが、すでに170時間以上経過しています
DB元のサイトによると予想時間が八時間ということですが、同じように予想時間二時間のファイルをインポートした時は16時間かかりました
170時間以上経過というのは異常でしょうか？ また原因はどこにあるでしょうか？
スペックはCPU:Celeron2.2G,Mem:DDR333の512MB,HDD:UltraATA/100の40GB、Ubuntu8.04上で動かしています
855 = :
>>854
MySQL詳しくないんだが、インポートの途中経過とかログに出せないの？
CPU使用率とかディスクアクセス見るしかない？
856 = :
>>855
作業を始めてからGUIの動作を受け付けなくなりましたorz
さっき調べたら途中経過を出すステートメントを見つけましたが、作業中でコマンド入力不能……
一度落としてデータベースを空にしてから再開しようかと迷ってます
857 = :
>>854
メモリーが少なすぎないか？
せめて1GBは無いと、その規模では予想時間の倍の時間がかかるイメージ。
858 = :
>>854
データベース区切った方が早いよ
自分の場合、1GBちょっと約700万のデータを50万レコードごと区切って入れたら1時間くらいだった。
あと基本だけど
・リモートよりサーバにUPしてから、コマンド打って入れたほうが数倍早い
・INSERT文はマルチインサートの方が数十倍早い
・インデックス貼ってるなら削除してからの方が早い
因みに環境はCPU:Athlon 3200 ,Mem:1GB
860 :
text型は例えば「備考」とか「理由」とかいう長文が入る可能性のカラムに対して
明示的に使うことがあるよね。
861 = :
txtにしないと内部検索できねーだろ
862 = :
お忙しいところ恐れ入ります。下記のように設定したいのですが、
syntaxエラーが出てしまい困っております。
どのように改修したら宜しいでしょうか？
アドバイス頂ければと思います。
create table m_user(
No integer PRIMARY KEY AUTO_INCREMENT,
ID char(8) UNIQUE KEY,
password varchar(20),
name varchar(20),
mail_address varchar(50),
authority varchar(2) NOTNULL);
エラー内容は下記です。
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near 'NOTNU
LL)' at line 7
864 = :
NOTNULL じゃなくて NOT NULL でしょ。
865 = :
メモリ増設してきました！
一気に三倍の1.5GBにして、HDD領域も少し増やして、改めてテーブルを用意して流し込んでます
結果が出たらまた報告しますね
866 = :
>>864
ありがとうございました。
なんという・・・俺バカ＞＜
ありがとうございました！
869 = :
とりあえず -p なしにしてみたら、どうなる ?
871 = :
とりあえず -q つけてみたら、どうなる？
872 :
-pって付け足しても同じようなのが出てきました。
873 :
インスコした時のぱ素ワード入れろよ
874 = :
商品テーブルにある、商品単価*数量の結果を
注文明細テーブルにある金額カラムに
自動でインサートしたいんですが何か方法はありますか？
たとえば、
商品単価=100
数量=3
だったら、自動で金額カラムに300とインサートしたいです。
数量を4に変更したら金額が400になって欲しいです。
876 = :
バージョン書いてないから、解らんけど、トリガー使えば？
877 = :
明細インサート、アップデート時に、その計算項目入れれば
878 = :
Oracleのストアドプロシージャだと、
INSERT文の中に、算術記号も使えた。
INSERT INTO tbl (金額) VALUES (商品単価*数量);
MySQLも似たようなことが出来るはず。
879 = :
「はず」じゃなくて、5.0からできる
880 = :
皆さんテーブル名やカラム名は、普通どんなフォーマットにしてる？
「TABLE_NAME」とか大文字とアンダバー組み合わせて統一？
本やググっても「これが定番」という資料がみつからないんで、ちと困ってます。
881 = :
itirou とか matui とか matuzaka とかにしてる
882 = :
>>880
別に特に気にしてない。気分次第かな。
カラム名については、外部参照するようなidなんかは、
"なんたら_id"みたいな感じ。
ちなみに、大文字小文字については、Unix環境だけでなく、
まったく同じ構成のDBをWin環境でもテストとかするから、小文字で統一。
883 = :
SQLの予約語を大文字で書く習慣があるからテーブルやカラム名は小文字
884 = :
>>881-883
なるほど。参考になります。
小文字に統一しとこう。ありがとうございます。
885 = :
>>880
2byteだけはやめとけ。
英語でもローマ字表記でもいいから、ASCII文字の方がOSが変わっても扱いやすい。
886 = :
hoge
-----------------------------------
id int
name VARCHAR(128)
priority TINYINT(2) DEFAULT 1
-----------------------------------
こんなテーブルがあったとして以下の条件でデータをとるにはどうすればいいでしょうか？
カラムは５つ
ランダムでとる
priority(優先度)が高いものが選ばれる可能性を高くする
５つとる・ランダムは以下でできますが
SELECT * FROM `hoge` Order By rand() limit 0,5;
優先順位を考慮に入れるとり方が思いつきません。
正確（完璧なアルゴリズム）ではなくてもいいのでご鞭撻のほどお願いします。
テーブルのつくりに問題がある場合もおっしゃっていただけると助かります。
今考えているのは
先に優先順位でソートして上位数件取得
そこからランダム取得
です。
887 = :
>>886
優先順位が高いと当たる確立が上がる という意味でしょうか。
その場合でしたら、やり方はいろいろあるでしょうけど、
シンプルなのは優先順位の値に従い該当レコードを
重複させたリストを作り、それに対してランダム取得など。
888 = :
>>886
今即席で考えてみた。
priority の値を1～5として、
select *,(rand()*5 + priority) as rand_col from hoge order by rand_col desc limit 1;
みたいな感じでどうか。(実際はpriorityの数値と、rand()*nのnを適切に与えてやらないといけないが・・)
上の例を、レコード5件、priorityを1.2.3.4.5としてやってみて、10000回の結果(それぞれのidが最大になった回数)
(priorityの値が大きいほうが選ばれやすい。言葉の意味的には逆なような気が？？)
1 = 28
2 = 259
3 = 1058
4 = 2767
5 = 5888
割合的には、(約)1:10:40:100:200
もっときれいに分かれるかと思ったけど、微妙だな・・・。
(文系脳ではここら辺が限界、スマソ)
890 = :
init-connect='SET NAMES utf8'
892 :
DQN男の家族消えろ DQN男の親消えろ DQN男の友達消えろ DQN男の親戚消えろ
DQN男の家族消えろ DQN男の親消えろ DQN男の友達消えろ DQN男の親戚消えろ
DQN男の家族消えろ DQN男の親消えろ DQN男の友達消えろ DQN男の親戚消えろ
DQN男の家族消えろ DQN男の親消えろ DQN男の友達消えろ DQN男の親戚消えろ
ニヤニヤ(・∀・) ニヤニヤ(・∀・) ニヤニヤ(・∀・) ニヤニヤ(・∀・)
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね
苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね
苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね
苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね苦しんで死ね
死ぬとき このレスの事思い出してから地獄いけよ
ニヤニヤ(・∀・) ニヤニヤ(・∀・) ニヤニヤ(・∀・) ニヤニヤ(・∀・)
893 :
>>890
どこの部分に書き込めばいいんですか？
895 = :
>>892
落ち着けｗ
896 = :
MySQLでPHPのアプリ作ったら、アプリのソース公開しなきゃいけないっていうのは本当ですか？
GPL汚染とはいえ、SQL叩いただけでというのは意味が分からないんですが・・
897 = :
レプリケーションについて、MySQLのマニュアルに、
「MySQL 4.0.2 はレプリケーション目的には適しません」
とありますがこれは何故なんでしょうか？
現在4.027を使っています。
898 = :
主キーを追加するのに
ALTER TABLE address ADO PRIMARY KEY (NUMBER);と入力したら、
ERROR 1064 (42000): You habe an error in your SQL syntax; check the manulal that
corresponds to your MySQL serber version for the right syntax to use near
'ADO PRIMARY KEY(number)' at line 1
とゆうエラーが出たんですけどどうゆう意味ですか？
899 = :
>>896
アプリ販売するなら一応そうだけど、MySQL＋PHPの場合は回避されるはず。それで一回MySQLのサポート外したから＞PHP
900 :
ほい！
「にっこっこ掲示板」ヤフーで検索してみ！「にっこっこ」でOK
新しいの誕生したよ
まだ規制ないし、色々貼れる
みんなの評価 : ☆
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について