元スレMySQL 総合 Part12
mysql覧 / PC版 /みんなの評価 : ○
655 = :
>>653
ぐぐればいくらでも答えは有るのに。
http://oshiete1.goo.ne.jp/qa746515.html
とか。
657 = :
>>656
addressテーブルはインデックスきいてるってことだから、
1万だろうが1000万だろうが速度差はそれほど出ないですよ。
SELECT * に時間かかってないかい? SELECTを整数の
1項目だけに絞ったら何秒になんの?
659 = :
ところで社保庁のデータベースって何使ってんの?
高スペクでも照合に時間かかるだろうなー。
660 = :
>>659
社会保険庁は、NTT系が受注開発しているから、
Oracleに決まっているだろ
661 = :
>>656
EXPAINの結果を張らないヤツの「問題ありません」は信用できないからなー
663 = :
開発と照合で5000マンだっけ?>社保庁
稼ぐなぁ
664 = :
じゃおまいら5000マソもらってできるか?アンダーソン君
673 = :
ググったけどわかんね
682 = :
前からインデックスについて疑問に感じていることがあるのですが、
1,2,3,4..........と続いているindexに2を追加すると、
1,2,2,3,4.........と3以下全て並べ替えになると理解しているのですが、
そのような仕組みになっているのでしょうか?
もし、そうだとすると100万件のデータが入っているtableで、
データを追加する際に、最悪100回の並べ替え(位置をずらす処理)が発生して大変なことになると思っています。
将来膨大なデータ件数になることが予想されるtableにindexをつけるかどうかで迷っているので、
アドバイスを頂けないでしょうか?
683 = :
>>682
インデックスがそういう構造だと
検索にはあまり向かないだろう
単なるノベタンではなくて、挿入・削除が容易な
例えばツリー構造のようになっているのだろう
安心してインデックス張るよろし
つか張らないと遅いでしょ
688 = :
>>687さん
即レス、ありがとうございます!
本当に助かりました
ありがとうございます
692 = :
>>691
仕方ないからyahooで調べてみた
http://www.google.com/search?q=mysqldump+opt
ここのサイトに詳しく載ってたよ
サンプルもいくつかあった
693 :
700 = :
変更された実行計画に対して適切な索引が無いから
かなー
みんなの評価 : ○
類似してるかもしれないスレッド
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- 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 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について