私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part25
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
うっかりdropしてもwindowsのゴミ箱みたいなのに入っているとか、そう言う仕組みがあるdbはないの？
>>602
さっそく調べてみます。ありがとうございました。
さっそく調べてみます。ありがとうございました。
MySQLでwhere節で 文字列を < とか > で比較するとき
辞書比較になります っていうのはマニュアルの
どのあたりに書いてありますか？
辞書比較になります っていうのはマニュアルの
どのあたりに書いてありますか？
いいねボタンの実装で
いいねしたユーザーidとされた記事idだけのシンプルなテーブル作ろうかと思ってるんですけど、やはり何百万件にもなるとカウントに時間かかるからカウント数のテーブルも用意したほうがいいですかね?
ツイッターとかfacebookとかどうなってるんでしょうかね
いいねしたユーザーidとされた記事idだけのシンプルなテーブル作ろうかと思ってるんですけど、やはり何百万件にもなるとカウントに時間かかるからカウント数のテーブルも用意したほうがいいですかね?
ツイッターとかfacebookとかどうなってるんでしょうかね
>>605
何百万件程度なら特に問題はないと思う
何百万件程度なら特に問題はないと思う
auto_incrementsでidキーを指定しているのですが、
もしidキーの値が最大値を超えようとする時、
バックアップなどを取ってデータを保持したままintからbigintに変更できたりできるのでしょうか？
できなければ初めからbigintしようかと思うのですが…
もしidキーの値が最大値を超えようとする時、
バックアップなどを取ってデータを保持したままintからbigintに変更できたりできるのでしょうか？
できなければ初めからbigintしようかと思うのですが…
あえて困難に挑むチャレンジャースピリットやね
てか事前にデータ量見積もったりしないんか？
てか事前にデータ量見積もったりしないんか？
普通に>>610のようにalterで出来るでしょ。つうか、 unsigned intで4294967295まで取れるのにそれを超える？
と予想されるんなら最初柄bigintにしておけば
と予想されるんなら最初柄bigintにしておけば
MySQLは運用中でも好きなだけalterしてくださいって中の人が言ってたから、
オレは闇雲に盲信してま。
オレは闇雲に盲信してま。
消費ペースを見積もって何年で枯渇するか計算してみればいい。
見積もれないなら10年で枯渇させるには1日幾つ消費するか計算すればいい。
見積もれないなら10年で枯渇させるには1日幾つ消費するか計算すればいい。
twitterのようなDMシステムを構築する場合、
どのような構造にすればよいのでしょうか？
どのような構造にすればよいのでしょうか？
>>611
でかい著名サービスでうっかり越えた件というとyoutubeくらい？
でかい著名サービスでうっかり越えた件というとyoutubeくらい？
mysqlを最近使い初めてパフォーマンスについて勉強中なのですが腑に落ちない教えてください。
innodbの列数30でキーは主キーのみテーブルに
1レコードをインサートしてはコミットするという処理を20万回ループさせ
インサートの時間とコミットにかかった時間を測ってみました。
最初はコミットがボトルネックだったのに
1万回ぐらいからはループ内でのインサートの遅さが2次関数的に目立ちはじめ
中盤には9割りがたの時間をインサートに費やしてるという状態でした。
が、インデックス更新に時間がかかるとはいえ
ディスクアクセスを伴うコミットよりもインサートはこうも遅くなるものなのでしょうか。
コミット時にはディスクにフラッシュする設定になっており
ログサイズはデフォルトですがバッファ使用率もメモリ使用率も低い状態でした。
innodbの列数30でキーは主キーのみテーブルに
1レコードをインサートしてはコミットするという処理を20万回ループさせ
インサートの時間とコミットにかかった時間を測ってみました。
最初はコミットがボトルネックだったのに
1万回ぐらいからはループ内でのインサートの遅さが2次関数的に目立ちはじめ
中盤には9割りがたの時間をインサートに費やしてるという状態でした。
が、インデックス更新に時間がかかるとはいえ
ディスクアクセスを伴うコミットよりもインサートはこうも遅くなるものなのでしょうか。
コミット時にはディスクにフラッシュする設定になっており
ログサイズはデフォルトですがバッファ使用率もメモリ使用率も低い状態でした。
長文すみません・・・。
補足ですが何が知りたいかというと
単にインサート1000回ごとにコミットするといったようにすれば速くなるのかと思ったのですが
インサートに時間がかかるなら考え直さないといけないなと悩んでいる次第です。
補足ですが何が知りたいかというと
単にインサート1000回ごとにコミットするといったようにすれば速くなるのかと思ったのですが
インサートに時間がかかるなら考え直さないといけないなと悩んでいる次第です。
データベースから最新の50件を取り出して、それを古い順に並べたいんですけど
どうしたらいいでしょうか
SELECT * FROM table_name ORDER BY num DESC LIMIT 50
これで最新の500件を取り出したのですが、このままですと新しい順に
表示されてしまいます
よろしくお願いします
どうしたらいいでしょうか
SELECT * FROM table_name ORDER BY num DESC LIMIT 50
これで最新の500件を取り出したのですが、このままですと新しい順に
表示されてしまいます
よろしくお願いします
select * from
( select * from table_name order by num desc limit 50) t
order by num asc;
とかなんとか
( select * from table_name order by num desc limit 50) t
order by num asc;
とかなんとか
クエリーログなんですがエラーが出るようなクエリーを投げた場合に
エラーが出たということとエラー原因もクエリーログに含める方法って無いですか？
エラーが出たということとエラー原因もクエリーログに含める方法って無いですか？
すいません一昨日ほどからmysql勉強を始めたのですが、わかる方いらしましたら
教えていただきたいです。
２つのテーブルを内部結合するとき
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として新しいテーブル
に書き換えて作業シたいのですがエラーが起きてしまいます・・・
教えていただきたいです。
２つのテーブルを内部結合するとき
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として新しいテーブル
に書き換えて作業シたいのですがエラーが起きてしまいます・・・
insert into tblC
select * from tblA
～;
でselectした結果をtblCに入れることは出来るはずだからselectが正しく出来てんのなら
（当然カラムのデータタイプやら順序やらは一致してんだよな。一致していないのなら個別に指定
しなきゃならんけど）出来るでしょ
なんでそこでalterが出てくるのか知らんけど
select * from tblA
～;
でselectした結果をtblCに入れることは出来るはずだからselectが正しく出来てんのなら
（当然カラムのデータタイプやら順序やらは一致してんだよな。一致していないのなら個別に指定
しなきゃならんけど）出来るでしょ
なんでそこでalterが出てくるのか知らんけど
>>624 ご回答ありがとうございました！
>>627
ありがとうごさいます。
AccessからADOで使ってたんですがRecordset.openで全レコードselecされてたのが悪かったみたいです。
普通にinsert intoしたら速くなりました。
ありがとうごさいます。
AccessからADOで使ってたんですがRecordset.openで全レコードselecされてたのが悪かったみたいです。
普通にinsert intoしたら速くなりました。
インデックスの更新というのは、インデックスの後ろの方に追加するだけで
そのテーブルを検索する時は、インデックスをバイナリサーチで検索した後
見つからなければ後ろの方を順探索で検索する。
インデックスを再編成すれば順番通りに並ぶ、という認識であってるかな？
そのテーブルを検索する時は、インデックスをバイナリサーチで検索した後
見つからなければ後ろの方を順探索で検索する。
インデックスを再編成すれば順番通りに並ぶ、という認識であってるかな？
ここで募集するのも筋違いだとおもうけど、SQLの文を書いたのを訂正してほしい・・・
中級者には30分ほどでおわる内容かも。
謝礼は7000で、
多分、チョー簡単。
詳しくは
remorse2015@yahoo.co.jp
日曜までとりあえず募集します。
メールで内容確認だけでも良いです/
中級者には30分ほどでおわる内容かも。
謝礼は7000で、
多分、チョー簡単。
詳しくは
remorse2015@yahoo.co.jp
日曜までとりあえず募集します。
メールで内容確認だけでも良いです/
データベース勉強中で、WindowsFormと連携する簡単な帳票ソフトをつくっているのですが、
MySQL側に保存する型として、たとえば男、女の区分を保存する場合、
真偽だけの情報にしておいて、アプリケーション側で判定して性別を表示させる場合と
VARCHARあたりで、「男」「女」の文字列で保存する場合とでパフォーマンスに影響するのでしょうか？
例としては文字数が短いですが、規模が大きくなったときに速度を左右するのでしょうか
MySQL側に保存する型として、たとえば男、女の区分を保存する場合、
真偽だけの情報にしておいて、アプリケーション側で判定して性別を表示させる場合と
VARCHARあたりで、「男」「女」の文字列で保存する場合とでパフォーマンスに影響するのでしょうか？
例としては文字数が短いですが、規模が大きくなったときに速度を左右するのでしょうか
心配するような影響は出ないと思うけど
入力が漢字入れられない環境だったり
最終出力が日本語じゃなくて多言語対応する可能性があるから
bool か f m くらいにしといてはfemale male でもいいけど
入力が漢字入れられない環境だったり
最終出力が日本語じゃなくて多言語対応する可能性があるから
bool か f m くらいにしといてはfemale male でもいいけど
SQLソース上で、男と女の文字を頻繁に書くことになるよ
1や2で分かりにくいと思うなら、MとFでも良いような
1や2で分かりにくいと思うなら、MとFでも良いような
null許容しないならbool以外でu とか unknownとかにしては
みなさまレスありがとうございます
>>637
よくわかりました
特別boolだけにこだわっているのではなく、たとえばINT型にして
アプリ側で数値にあわせて値を表示させるでも良いのですが、
単純にデータ件数が1万とかになり、カラム数も10とか20になったときに
文字列保存したのと、boolやINT型で保存した場合とでデータ量そのものの違いによって
ネットワークでのやりとりやデータ処理に時間差がでないのかなと思った次第です
>>637
よくわかりました
特別boolだけにこだわっているのではなく、たとえばINT型にして
アプリ側で数値にあわせて値を表示させるでも良いのですが、
単純にデータ件数が1万とかになり、カラム数も10とか20になったときに
文字列保存したのと、boolやINT型で保存した場合とでデータ量そのものの違いによって
ネットワークでのやりとりやデータ処理に時間差がでないのかなと思った次第です
カラム数なら100、データ件数なら10万を超えるまでは正味大差ないよ
それまでの規模で遅いクエリは絶対にインデックスがおかしいし
それまでの規模で遅いクエリは絶対にインデックスがおかしいし
>>639
1.5
1.5
難しいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいい
うぁああああああああああああああああああああああああああああああああああああ
うぁああああああああああああああああああああああああああああああああああああ
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
mysql スレッド一覧へ類似してるかもしれないスレッド
- 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 ○
トップメニューへ / →のくす牧場書庫について