元スレMySQL 総合 Part25
mysql覧 / PC版 /みんなの評価 :
601 = :
うっかりdropしてもwindowsのゴミ箱みたいなのに入っているとか、そう言う仕組みがあるdbはないの?
602 = :
トランザクションログ取ってればいつでも任意の時点に戻せる
603 = :
>>602
さっそく調べてみます。ありがとうございました。
605 = :
いいねボタンの実装で
いいねしたユーザーidとされた記事idだけのシンプルなテーブル作ろうかと思ってるんですけど、やはり何百万件にもなるとカウントに時間かかるからカウント数のテーブルも用意したほうがいいですかね?
ツイッターとかfacebookとかどうなってるんでしょうかね
606 = :
>>605
何百万件程度なら特に問題はないと思う
607 = :
合計値を表示する頻度にもよるしな
608 = :
auto_incrementsでidキーを指定しているのですが、
もしidキーの値が最大値を超えようとする時、
バックアップなどを取ってデータを保持したままintからbigintに変更できたりできるのでしょうか?
できなければ初めからbigintしようかと思うのですが…
609 :
あえて困難に挑むチャレンジャースピリットやね
てか事前にデータ量見積もったりしないんか?
610 = :
MySQLなら普通にalterできる予感。
611 = :
普通に>>610のようにalterで出来るでしょ。つうか、 unsigned intで4294967295まで取れるのにそれを超える?
と予想されるんなら最初柄bigintにしておけば
612 = :
MySQLは運用中でも好きなだけalterしてくださいって中の人が言ってたから、
オレは闇雲に盲信してま。
613 = :
消費ペースを見積もって何年で枯渇するか計算してみればいい。
見積もれないなら10年で枯渇させるには1日幾つ消費するか計算すればいい。
614 = :
twitterのようなDMシステムを構築する場合、
どのような構造にすればよいのでしょうか?
615 = :
>>611
でかい著名サービスでうっかり越えた件というとyoutubeくらい?
617 = :
可能です^^
618 = :
mysqlを最近使い初めてパフォーマンスについて勉強中なのですが腑に落ちない教えてください。
innodbの列数30でキーは主キーのみテーブルに
1レコードをインサートしてはコミットするという処理を20万回ループさせ
インサートの時間とコミットにかかった時間を測ってみました。
最初はコミットがボトルネックだったのに
1万回ぐらいからはループ内でのインサートの遅さが2次関数的に目立ちはじめ
中盤には9割りがたの時間をインサートに費やしてるという状態でした。
が、インデックス更新に時間がかかるとはいえ
ディスクアクセスを伴うコミットよりもインサートはこうも遅くなるものなのでしょうか。
コミット時にはディスクにフラッシュする設定になっており
ログサイズはデフォルトですがバッファ使用率もメモリ使用率も低い状態でした。
619 = :
長文すみません・・・。
補足ですが何が知りたいかというと
単にインサート1000回ごとにコミットするといったようにすれば速くなるのかと思ったのですが
インサートに時間がかかるなら考え直さないといけないなと悩んでいる次第です。
620 = :
データベースから最新の50件を取り出して、それを古い順に並べたいんですけど
どうしたらいいでしょうか
SELECT * FROM table_name ORDER BY num DESC LIMIT 50
これで最新の500件を取り出したのですが、このままですと新しい順に
表示されてしまいます
よろしくお願いします
623 = :
すいません一昨日ほどからmysql勉強を始めたのですが、わかる方いらしましたら
教えていただきたいです。
2つのテーブルを内部結合するとき
select*from A inner join B on A.a = B.b
でAテーブルのaとBテーブルのbをひも付けたテーブルができるかと思いますが
この時のテーブル名は何になるのでしょうか?
alter table A inner join B on A.a = B.b rename to Cとして新しいテーブル
に書き換えて作業シたいのですがエラーが起きてしまいます・・・
624 = :
insert into tblC
select * from tblA
~;
でselectした結果をtblCに入れることは出来るはずだからselectが正しく出来てんのなら
(当然カラムのデータタイプやら順序やらは一致してんだよな。一致していないのなら個別に指定
しなきゃならんけど)出来るでしょ
なんでそこでalterが出てくるのか知らんけど
625 = :
>>624 ご回答ありがとうございました!
626 = :
なんか、View作った方が適切な案件の気がした。
627 = :
>>618
テーブル自体がでかくなってるからどこに突っ込むか探すのに手間がかかってる予感
インデックスのバッファを増やせばいいのかも
628 = :
>>627
ありがとうごさいます。
AccessからADOで使ってたんですがRecordset.openで全レコードselecされてたのが悪かったみたいです。
普通にinsert intoしたら速くなりました。
629 = :
インデックスの更新というのは、インデックスの後ろの方に追加するだけで
そのテーブルを検索する時は、インデックスをバイナリサーチで検索した後
見つからなければ後ろの方を順探索で検索する。
インデックスを再編成すれば順番通りに並ぶ、という認識であってるかな?
630 = :
ここで募集するのも筋違いだとおもうけど、SQLの文を書いたのを訂正してほしい・・・
中級者には30分ほどでおわる内容かも。
謝礼は7000で、
多分、チョー簡単。
詳しくは
remorse2015@yahoo.co.jp
日曜までとりあえず募集します。
メールで内容確認だけでも良いです/
631 = :
>>629
あれ? B-tree ってそういう仕様じゃなかったと思うんだけど…
633 = :
DBだけど
634 = :
お釈迦様もみてる
636 :
データベース勉強中で、WindowsFormと連携する簡単な帳票ソフトをつくっているのですが、
MySQL側に保存する型として、たとえば男、女の区分を保存する場合、
真偽だけの情報にしておいて、アプリケーション側で判定して性別を表示させる場合と
VARCHARあたりで、「男」「女」の文字列で保存する場合とでパフォーマンスに影響するのでしょうか?
例としては文字数が短いですが、規模が大きくなったときに速度を左右するのでしょうか
637 = :
心配するような影響は出ないと思うけど
入力が漢字入れられない環境だったり
最終出力が日本語じゃなくて多言語対応する可能性があるから
bool か f m くらいにしといてはfemale male でもいいけど
638 = :
SQLソース上で、男と女の文字を頻繁に書くことになるよ
1や2で分かりにくいと思うなら、MとFでも良いような
639 = :
不明な時はどうするの?
641 = :
初期値(未回答)、男、女、回答なし
642 = :
とりあえずboolで設計するのだけはやめておけ という話だよ
643 :
未回答と回答なしの違いについて
644 = :
みなさまレスありがとうございます
>>637
よくわかりました
特別boolだけにこだわっているのではなく、たとえばINT型にして
アプリ側で数値にあわせて値を表示させるでも良いのですが、
単純にデータ件数が1万とかになり、カラム数も10とか20になったときに
文字列保存したのと、boolやINT型で保存した場合とでデータ量そのものの違いによって
ネットワークでのやりとりやデータ処理に時間差がでないのかなと思った次第です
645 = :
カラム数なら100、データ件数なら10万を超えるまでは正味大差ないよ
それまでの規模で遅いクエリは絶対にインデックスがおかしいし
646 = :
MySQL糞難しい!!
本読んでも簡単な例文しか書いてねえ!!
647 = :
SQLを知らない人がいるとは
648 = :
>>639
1.5
649 :
難しいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいい
うぁああああああああああああああああああああああああああああああああああああ
650 = :
今日も寝苦しい
みんなの評価 :
類似してるかもしれないスレッド
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part20 (995) - [94%] - 2011/10/17 4:48
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [89%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について