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

私的良スレ書庫

不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitter
ログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。

元スレ【この先一体】MySQL 総合 Part15【どうなるの】

mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニュー
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
レスフィルター : (試験中)
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter
303 : NAME IS - 2009/06/09(火) 00:17:37 ID:??? (+61,+29,-9)
MySQL単体の問題みたいだけど、エラーも出ない、ログイン時間が掛かる
というのは不思議ですね…
304 : NAME IS - 2009/06/09(火) 08:04:23 ID:??? (-1,-29,-8)
DNSで名前がひけなくなるとそうなるかなー
skip-name-resolveとか
305 : NAME IS - 2009/06/09(火) 10:08:10 ID:??? (+57,+29,-67)
>>302
エラーログに何も出ていないなら、テーブルスペースフルとかでもないんだよね。
単純に件数が増えて遅くなっているならexplainとかを使ってクエリの中身とか
インデックスの張り方を工夫してみると良いと思う。ファイルソートになってる
とか、インデックスを使えてない可能性もあるから。
306 : NAME IS - 2009/06/09(火) 13:00:57 ID:??? (+6,-29,-1)
>>303-305
アドバイスありがとうございます。
explainなど試してみます。
307 : NAME IS - 2009/06/09(火) 13:58:46 ID:??? (+8,-29,-29)
MySQL 5 を使い始めました。

PostgreSQL には vacuum がありますが、
MySQL には同様のものはありますか?
308 : NAME IS - 2009/06/09(火) 14:28:52 ID:??? (+83,+29,+0)
そんなものはいらないない。
309 : 307 - 2009/06/09(火) 14:36:49 ID:??? (+62,+28,-11)
>>308
ありがと。すばらしい。
310 : NAME IS - 2009/06/09(火) 19:53:16 ID:??? (+124,+29,-91)
あれ? 2chはファイルシステム有利とか言ってた約1名は逃げた?

2chがDB使ってないのは、元々の仕様でそうなっていたからだろ?
要するにDB管理の掲示板じゃなかったから。

DB版掲示板の無料レンタルなんて当時ほぼ無いだろうが
スレ内検索なんかにはDBの方が有利だな。CPUに負荷もかからんし。
311 : NAME IS - 2009/06/09(火) 20:22:04 ID:??? (+57,+29,-14)
それで思い出したけど、カウンタの質問してた人は質問投げっ放しか。
疑問は解けたのかな。
312 : NAME IS - 2009/06/09(火) 20:46:27 ID:??? (+23,-9,-1)
>>310
スレ内検索…
313 : NAME IS - 2009/06/09(火) 21:13:50 ID:??? (+57,+29,-33)
ってゆうか2ちゃんってひろゆきが作ったんじゃないの?
ひろゆきプログラマー?
314 : NAME IS - 2009/06/09(火) 21:27:22 ID:??? (+64,+29,-29)
お手軽ででかいシステムだとファイルシステムがいい
金かけまくってとことん突きつめるとDBになるがコストパフォーマンスが…
315 : NAME IS - 2009/06/09(火) 21:27:54 ID:??? (+6,-21,-55)
>スレ内検索なんかにはDBの方が有利だな。CPUに負荷もかからんし。

真性のヴァカ発見

つかRDBMS覚えたて厨房はさっさと2chをMySQLで構築してみりゃいいじゃねーか。
316 : NAME IS - 2009/06/09(火) 21:30:04 ID:??? (+70,+29,-43)
>>310
本気でそう思っているなら運営板にでもいって鯖管理でもやらせてもらえば。

UNIX板あたりの住人に「バカ発見」と言われるのがオチだろうけど。
317 : NAME IS - 2009/06/09(火) 21:41:17 ID:??? (+57,+29,-25)
DBに入れると魔法の力で計算量が激減すると思ってるのかもね。
元々の仕様がなんでそうなったのかとか、検索用のインデックスを
張るコストとか、深く考えてないんじゃないかな。
318 : NAME IS - 2009/06/09(火) 21:44:30 ID:??? (+39,+21,-3)
その理由は?
319 : NAME IS - 2009/06/09(火) 21:57:24 ID:??? (+78,-29,-74)
>>314
RDBMS相当の機能を自前で実装しようとすると、もっとお金が掛かるよ~

2chの書き込みをわざわざSQLを使って格納するのは無駄だし、ACID特性も
必要無いし、RDBMSを使う意味は無いよね。
320 : NAME IS - 2009/06/09(火) 21:59:23 ID:??? (-4,-27,-27)
mixiはデータベース管理だお
321 : NAME IS - 2009/06/09(火) 22:01:49 ID:??? (+57,+29,-19)
2chはファイルシステム管理だお

技術要件が違うんだから適材適所
322 : NAME IS - 2009/06/09(火) 22:35:10 ID:??? (+53,+25,-6)
ファイルシステム管理とか変だろ。
ただのベタファイルだろ。
323 : NAME IS - 2009/06/09(火) 23:12:57 ID:??? (+38,+10,-9)
たいていのブログもDBじゃね?
ファイルで管理とか初心者すぎだろ
324 : NAME IS - 2009/06/09(火) 23:13:14 ID:??? (+57,+29,-65)
そのベタファイルをファイルシステムで管理してるんだよ。
ディレクトリとかキャッシュとかタイムスタンプとかアクセス権減とか、
その他のメタデータとか、実装をきちんと理解していれば変ではない。
325 : NAME IS - 2009/06/09(火) 23:42:44 ID:??? (+131,+27,-15)
ファイルでの管理の問題点は、ファイル内を検索する速度の速い遅いではなく
同じディレクトリ内に大量のファイルを置くとそのファイルを探すのに時間がかかる事。
326 : NAME IS - 2009/06/09(火) 23:46:52 ID:??? (+104,+29,-28)
>>319
?2chでもACID特性は重要だろ。
でなきゃ同時に書き込みしたらレスが混じるとか、行数制限を越えた
書き込みをした時にレスが半分だけ書かれるなどということが
起きかねない。
327 : NAME IS - 2009/06/10(水) 00:02:11 ID:??? (+136,+29,-33)
>>325
板毎にディレクトリは分かれてると思うけど、読み書き可能なスレッドだけ
なら大量というほどの事は無いでしょ。ファイル名のキャッシュもあるし。
もしファイル数が問題なら、ある程度のスレッド数毎にディレクトリを
分ければいいだけだし。

>>326
程度の問題だけど、2chはレスを書き込む度にいちいちfsync()しないと
いけないサイトではないでしょ。永続性は限定的で十分。
328 : NAME IS - 2009/06/10(水) 00:05:35 ID:??? (+57,+29,-6)
楽観的ロックという考え方もあるしな。
329 : NAME IS - 2009/06/10(水) 00:32:16 ID:??? (+40,+0,-3)
あれ?>>310は(ry
330 : NAME IS - 2009/06/10(水) 01:00:58 ID:??? (+85,+10,-10)
>>327
なぜその文脈でfsyncだの永続性だのといった単語が出てくる?
331 : NAME IS - 2009/06/10(水) 05:22:08 ID:??? (+66,+27,-13)
>>319
だから、同等の機能はそもそもアキラメル
332 : NAME IS - 2009/06/10(水) 05:23:18 ID:??? (+57,+29,-8)
ちなみにとことん突きつめると全データオンメモリとか
そんなもんw
333 : NAME IS - 2009/06/10(水) 11:28:53 ID:??? (+112,+29,-5)
>>327
だからファイルで管理する場合ディレクトリを分けなきゃいけないって事でしょ
334 : NAME IS - 2009/06/10(水) 11:29:40 ID:??? (+57,+29,-12)
スレ内検索は、全文検索だから
転地インデックスにするか、grepみたいに全部見るしかないんじゃね?
335 : NAME IS - 2009/06/10(水) 12:27:47 ID:??? (+76,+29,-27)
>>330
理解出来なかったのならACIDのDについて調べてみよう。

>>333
2chのスレ数なら>>325の問題はそもそも気にしなくて良いという事。
336 : NAME IS - 2009/06/10(水) 13:59:16 ID:??? (+94,+29,-7)
そういえば「したらば」もデータベースって聞いた事あるよ。
337 : NAME IS - 2009/06/10(水) 14:36:36 ID:??? (+57,+29,-49)
掲示板にDBを使う主な理由はこのどちらかだけど、

・データを連携させて高度な機能を実現したい
・性能を多少犠牲にしても、データの管理を丸投げしたい

「2ch」はどちらにも当て嵌まらないんだよね。
338 : NAME IS - 2009/06/10(水) 15:36:27 ID:??? (+75,+29,-53)
>>336
何処で聞いたんだ?したらばも2chとほぼ同じ仕掛けだったと思うが。
まあ、今話しているのはスレッドの管理のことで、
板自体の管理にDBを使ってる可能性は否定しない。
2chブラウザの仕組みを知ってるならスレッドの管理にDBを使ってないのは明白だろ。
339 : NAME IS - 2009/06/10(水) 15:50:01 ID:??? (+57,+29,-29)
2chがどうとか言う話になってるから便乗して質問したいのだが
sennaってどうなの?
仕組みがよく分からないのだが、効率よく分かち書きしてくれるって事?
340 : NAME IS - 2009/06/10(水) 16:29:18 ID:??? (-1,-29,-11)
N-GRAMかMeCabつかった分かち書きだから、Sennaの肝は転置インデックスでの検索でしょう
341 : NAME IS - 2009/06/10(水) 21:03:54 ID:??? (+57,+29,-21)
2ちゃんがデータベースだろうが何だろうがかまわないが
FOX★がハゲすぎてるのが気になる
342 : NAME IS - 2009/06/11(木) 15:32:27 ID:??? (+0,-27,-40)
InnoDBってどうやって読むのでしょうか?
インノデービーで合ってます?

MyISAMはマイアイサムで合ってますよね?
343 : NAME IS - 2009/06/11(木) 15:59:04 ID:??? (+0,-17,-11)
マィイサム
344 : NAME IS - 2009/06/11(木) 15:59:57 ID:??? (+47,+29,-15)
猪野出武威
345 : NAME IS - 2009/06/11(木) 16:02:49 ID:??? (+53,+25,+0)
えー、イノデブイとマイイサムなんですか‥‥。
346 : NAME IS - 2009/06/11(木) 22:13:18 ID:??? (+43,+20,+1)
イノデービーとマイイザム
347 : NAME IS - 2009/06/12(金) 01:01:19 ID:??? (+49,+21,-6)
http://www.youtube.com/watch?v=RpC1BMOZeAs

0:37 で『インノディービー』って言ってるね。
日本では『イノデービー』と呼んでる人が多いと思う。
348 : NAME IS - 2009/06/12(金) 12:08:04 ID:??? (+3,-30,-130)
mysql+phpで、例えばmysqlに
A123A456A789
って文字が格納されてるローがあって、
これからA456てのを削除して、A123A789を残したいってときには、
まずselectして、そこのローをみて、str_replaceしてupdate set
する方法しかないかな?
sql文だけで便利なものありませんか
349 : NAME IS - 2009/06/12(金) 12:11:46 ID:??? (+9,-18,+0)
と思って調べたらREPLACE関数ってのがあった
お騒がせしました
350 : NAME IS - 2009/06/14(日) 08:31:28 ID:??? (+9,-30,-122)
解決できずモヤモヤしてます。
初心者すぎてめっちゃ恥ずかしいですが、よろしくお願いします。
バージョンは 5.1.22-rc です。

TESTテーブルにある、SUUJIというカラムの構造を変更する文を書いてみました。

ALTER TABLE `TEST` CHANGE `SUUJI` `SUUJI` INT( 4 )

INT型は4byte必要と知ったので、INT(4) としてはみたものの、INT(1)でもINT(5)でもエラーが出ません。
INT(1)にしたあと、試しに数字を保存(999999.....と大きめな数を入力)してみたのですが
通常の最大値2147483647まで保存可能なようです。
INT( xx ) の指定には意味があるのでしょうか。そして、本来どう指定するのが正しいのでしょうか?
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql スレッド一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

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


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