のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,747人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレMySQL 総合 Part17

    mysql覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - 2004 + - config + - Warning + - 経過時間 + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    953 = :

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

    954 = :

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

    955 = :

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

    956 = :

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

    957 = :

    夜に死ねと

    958 = :

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

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

    959 :

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

    960 = :

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

    962 = :

    さあ、ジョイナス!!

    963 = :

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

    964 = :

    >>963
    だからじゃね?

    965 = :

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

    966 = :

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

    967 = :

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

    968 = :

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

    969 = :

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

    971 = :

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

    973 = :

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

    974 = :

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

    975 = :

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

    978 = :

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

    979 = :

    >>968
    魔術はあるもん!

    980 = :

    キュキュキュッ

    982 = :

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

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

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

    983 :

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

    984 = :

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

    985 = :

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

    987 = :

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

    988 = 983 :

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

    989 = :

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

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

    990 = :

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

    991 = :

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

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

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

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

    992 = :

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

    993 = :

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

    994 = :

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

    奇妙な考えだなぁ。

    996 = :

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

    998 = :

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

    999 = :


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

    1000 = :

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


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - 2004 + - config + - Warning + - 経過時間 + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

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


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