元スレMySQL 総合 Part17
mysql覧 / PC版 /みんなの評価 : ○
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 = :
普通にサイト運営してたらログとして溜まるだろうが
みんなの評価 : ○
類似してるかもしれないスレッド
- 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 ○
トップメニューへ / →のくす牧場書庫について