私的良スレ書庫

不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterで
ログインするとレス評価できます。登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。

元スレMySQL 総合 Part17

mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニュー

みんなの評価 : ○
レスフィルター : (試験中)

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

953 : NAME IS - 2010/06/07(月) 23:41:24 ID:??? (+29,+29,-38)

>>950
また条件後付けで「私のメモリは16GBです」「私のストレージはSSDです」とか言われるぞ。

954 : NAME IS - 2010/06/08(火) 00:16:03 ID:??? (+34,+29,-4)

>>953
その条件だからって、20分が2秒にはならないだろ？

955 : NAME IS - 2010/06/08(火) 00:26:01 ID:??? (+28,+29,-1)

>>954
20分がなんぼになるかじゃなくて、>>947条件後出しすんなボケ氏ねって話。

956 : NAME IS - 2010/06/08(火) 01:12:11 ID:??? (+22,+29,-1)

いいえ、死ぬ必要はNight思うわ

957 : NAME IS - 2010/06/08(火) 10:07:34 ID:??? (+10,+22,+0)

夜に死ねと

958 : NAME IS - 2010/06/08(火) 10:13:06 ID:??? (+27,+29,-23)

・後出して条件出して答えてもらう
・単にMySQLの可能性が知りたいだけ

どっちだろ？素人だったらそもそも
100万件のデータなんて扱わないはずだから、後者かな。

959 : NAME IS - 2010/06/08(火) 14:18:15 ID:6789QTvE (+12,+17,-8)

話はそれるけどいまMysqlの日本語全文検索って
senna 以外はどんなのがあるの？

960 : NAME IS - 2010/06/08(火) 14:34:14 ID:??? (+26,+28,-3)

5.1のエクステンションを見たことある
実績とかは知らない

962 : NAME IS - 2010/06/08(火) 22:48:10 ID:??? (+11,+18,+0)

さあ、ジョイナス！！

963 : NAME IS - 2010/06/08(火) 23:15:01 ID:??? (+26,+25,-6)

テーブル構造もSQL文もインデックスも情報なしに、なぁ。

964 : NAME IS - 2010/06/09(水) 04:06:02 ID:??? (+16,+19,-1)

>>963
だからじゃね？

965 : NAME IS - 2010/06/09(水) 07:12:19 ID:??? (+15,+22,-11)

ありがちなのは、N自乗。

966 : NAME IS - 2010/06/09(水) 13:17:17 ID:??? (+27,+29,-9)

でも実際、インデックスを理解しないで使っている人周りに結構居ない？

967 : NAME IS - 2010/06/09(水) 13:39:55 ID:??? (+33,+29,-18)

なんだか分からないが付けると速くなる魔法の機能でしょ、理解してるよ

968 : NAME IS - 2010/06/09(水) 13:41:21 ID:??? (+36,+29,-19)

>>967
はネタだろうが、
実際に使わないインデックスが20くらい付いたテーブルは見たことがある

969 : NAME IS - 2010/06/09(水) 16:10:11 ID:??? (+27,+29,-2)

とりあえず、JOINのキーになっているフィールドはインデックスにしてる

971 : NAME IS - 2010/06/09(水) 18:51:52 ID:??? (+30,+29,-58)

join されるテーブルで where 句使うなら、
複合インデックスで
where 句のカラム, 結合カラム
とインデックスを張らないとダメだよ。
joinする場合はどっち道フルJOIN 避けるために件数減らしてからJOINだから、
結合カラムに単体でインデックスを張るのは意味がないと思う。

972 : NAME IS - 2010/06/09(水) 19:00:02 ID:??? (-23,-28,-21)

>>971
結合カラム自体を where で絞り込む場合は？

973 : NAME IS - 2010/06/09(水) 19:02:01 ID:??? (+12,+22,-1)

>>972
その場合は有効か。

974 : NAME IS - 2010/06/09(水) 19:35:50 ID:??? (+27,+29,-31)

でもまあ実際コード引継ぎとかすると、
インデックスとクエリ直すだけで速度が100倍とかなるから、
おかげで神みたいな扱いをされて楽。

975 : NAME IS - 2010/06/09(水) 20:40:41 ID:??? (+21,+28,-1)

とあるカラムのインデックス

978 : NAME IS - 2010/06/09(水) 23:31:31 ID:??? (+20,+27,-26)

インナーのネイティブアルターか

979 : NAME IS - 2010/06/10(木) 00:09:03 ID:??? (+27,+29,+0)

>>968
魔術はあるもん！

980 : NAME IS - 2010/06/10(木) 03:34:47 ID:??? (+13,+25,-1)

キュキュキュッ

982 : NAME IS - 2010/06/10(木) 10:03:27 ID:??? (+32,+29,-58)

記号などって…w
例えばどの文字なのか、いくつか挙げるってのを何故しないの?

DB/テーブルの文字コード設定を調べておくってことを
「質問させてください」の前にやってないの?

そういやMySQLのバージョンすら分からんな。

983 : NAME IS - 2010/06/10(木) 14:45:20 ID:3agFnNQw (+5,+29,-35)

みなさん、どこまで正規化します？
正規化してテーブル分けすぎて後から結合する時に困ります・・。
かといって1つのテーブルで管理すると、レコードが多くなりすぎるし。

984 : NAME IS - 2010/06/10(木) 14:51:51 ID:??? (+27,+29,-17)

正規化って何なのかよくワカンナイ
同じデータが重複しないようにしたりするだけ、１つのテーブルで管理とか逆にどうやってるのか分からない
正規化もワカンナイ

985 : NAME IS - 2010/06/10(木) 15:03:32 ID:??? (+22,+29,-18)

>>983
結合する時に困るってどう困るんだい？

987 : NAME IS - 2010/06/10(木) 16:28:09 ID:??? (+27,+29,-53)

>>986
ハードウェアのスペック挙げれば解決できるからいいんじゃないの。
俺の場合、データを重複させないようにした方が、二時利用に役立つから極力してるよ。

988 : NAME IS - 2010/06/10(木) 16:31:35 ID:3agFnNQw (+4,+26,-4)

>>987
そうですね。SQL文が長くなる＝プログラム側の問題は考えないようにします。

989 : NAME IS - 2010/06/10(木) 16:55:58 ID:??? (+28,+29,-55)

>>988
SQL文が長くなってしまってメンテが大変になる場合は、
ある程度区切って結合させてデータを取得し、プログラム側で結合させる事もある。

ま、いろいろ方法はあるよね。

990 : NAME IS - 2010/06/10(木) 19:09:09 ID:??? (+29,+29,-22)

>>987
ハードに逃げるのは馬鹿のやること。
厳しい事を言うが設計がおかしいと考えるべき。

991 : NAME IS - 2010/06/10(木) 19:35:56 ID:??? (+33,+30,-187)

3テーブルを結合したくらいで"ものすごく"SQLが長くなるってのがイメージ付かないんだけど？

それにSQLの長さ自体はパフォーマンスには関係ない。
商品IDは主キーなりインデックス張ってあるなりしてるだろうけど、インデックスを使っている限りはDBというものは極めて高速に動く。

データ数が1テーブル10万～100万オーダー超になるとどうしても遅くなるので、
そういった場合は最後の手段としてハードウェアのスペックを上げる。

3テーブルJOINを使うとメンテ出来ないって？さっさと別業種に転職しろｗ

992 : NAME IS - 2010/06/10(木) 19:58:03 ID:??? (+22,+29,-2)

メンテ出来ないって誰が書いてるの？

993 : NAME IS - 2010/06/10(木) 20:17:15 ID:??? (+22,+29,-18)

「長い」という基準の違いでしょう

994 : NAME IS - 2010/06/10(木) 21:39:21 ID:??? (+27,+29,-49)

>物凄くSQL文が長くなり、パフォーマンスに影響が出ないか懸念しています。

奇妙な考えだなぁ。

996 : NAME IS - 2010/06/10(木) 22:25:18 ID:??? (+27,+29,-36)

どうせDBの実行所要時間なんて殆どがディスクアクセスでしょ。
いくら長いSQL文たって、そのパースにかかる時間の割合なんぞたかが知れてるんじゃないの。

998 : NAME IS - 2010/06/10(木) 23:54:41 ID:??? (+25,+27,-63)

パスワードはユーザに設定してるもんだよ。
だから、DBにそのユーザが含まれていたら同じ。

999 : NAME IS - 2010/06/11(金) 10:35:04 ID:??? (+27,+29,-11)

毎日毎日、１０万件ものデータいつどうやって作ってるのか、そっちのほうが気になるよ。

1000 : NAME IS - 2010/06/11(金) 13:53:37 ID:??? (+27,+29,-4)

普通にサイト運営してたらログとして溜まるだろうが

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで /

mysql スレッド一覧へ

みんなの評価 : ○

類似してるかもしれないスレッド

MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
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 総合 Part23 (992) - [89%] - 2013/8/11 17:00
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 ○

トップメニューへ / →のくす牧場書庫について

総計:	127,621,713人
頁
昨日:	no data人
頁
今日:	人
頁