私的良スレ書庫

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

元スレMySQL 総合 Part24

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で

301 : NAME IS - 2013/11/29(金) 20:48:03.33 ID:ld8Q8jAS.net (-5,+29,-10)

>>298-300
普通はこうするんですね
列の数が増えてしまうのが嫌だったのですが正攻法なのであればこれでいきます

302 : NAME IS - 2013/11/29(金) 23:33:23.20 ID:???.net (+2,-29,-55)

>>301
あんまりお勧めしないけど、どうしても嫌なら公開情報テーブルを別に作る

ユーザーID
該当テーブル名
公表フラグ

あとは公表フラグを元にプログラムで判定させる。
もしくはmemberテーブル自体を、

ユーザーID
該当項目（該当テーブル名）
値
公表フラグ

にしてしまう。これなら横に追加しなくても良い。

303 : NAME IS - 2013/11/30(土) 20:53:53.22 ID:???.net (+57,+29,-14)

MySQLのスレでポスグレでもオラクルでもできるテーブル設計の話
ドヤ顔で始めるチンカスってなんなの？

304 : NAME IS - 2013/12/01(日) 14:48:22.43 ID:u1FkK0X5.net (+42,+18,+0)

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10117233810
これわかる方お願いします＞＜

305 : NAME IS - 2013/12/01(日) 15:51:04.11 ID:???.net (-5,-29,+0)

>>304
ggrks

306 : NAME IS - 2013/12/01(日) 20:46:29.75 ID:???.net (-1,-29,-9)

答えは
1:g, 2:g, 3:r, 4:k, 5:s
ですね！ありがとうございます！

307 : NAME IS - 2013/12/01(日) 21:00:32.43 ID:???.net (+9,-8,-1)

wwww

308 : NAME IS - 2013/12/01(日) 21:34:18.67 ID:???.net (+60,+26,-6)

>>304
もうちょっと画質が良いのないの？

309 : NAME IS - 2013/12/01(日) 23:21:39.96 ID:???.net (+52,+29,-3)

まるち、ていわないんだ

310 : NAME IS - 2013/12/09(月) 17:10:32.62 ID:KDrt2ZmL.net (+24,+29,-34)

予約語を避けるにはどうしたらいいかな
適当な接頭語をつけるのが一番楽かな

312 : NAME IS - 2013/12/13(金) 16:51:05.75 ID:???.net (+11,-16,-40)

本気環境で使うのにRedhat標準のものをずっと使い続けることがありえない。
特にMariaの方はVersionUpも頻繁に行われるだろうし。

313 : NAME IS - 2013/12/13(金) 17:13:52.04 ID:???.net (+94,+27,-52)

RHELにはいったのはMariaDB5.5。安定版だよ。
それにディストリ固有のパッケージ使いたい人たちが多数。
普通はパッケージ管理なんてやりたくないんだよ。

そもそもMySQLのバージョンアップのほうがキツいだろ。
ボロボロの状態でGAリリース、何年たっても不安定。

314 : NAME IS - 2013/12/13(金) 17:18:31.08 ID:???.net (+57,+29,-5)

この人たち、裏で必死に転職活動してそうだわ

http://twitter.com/RKajiyama/status/387821488759250944

315 : NAME IS - 2013/12/13(金) 20:39:35.32 ID:???.net (+78,+29,-26)

>>313
出たばっかの頃はいいが、そっから3年くらいはずっとそのままのバージョンで行くんだぜ。。。
そなるといずれは自分で入れることになるんだから。

316 : NAME IS - 2013/12/13(金) 22:59:32.28 ID:???.net (+16,-27,-171)

>>315

>そなるといずれは自分で入れることになるんだから。

MariaDBをだろ
だからMySQL終了だっつうのw

>出たばっかの頃はいいが、そっから3年くらいはずっとそのままのバージョンで行くんだぜ。。。

まじめな話、Maria10.0なんてまだαだし、5.5で数年行くのは正しいだろ。
Maria5.5とMySQL5.5はほとんど同じだし。

RHELなど主要ディストリビューションがMySQLからMaria5.5から切り替えたのはデカイよ。
よほどの物好きか、最新版大好きの素人しかMySQL5.6に移行しないだろう。

317 : NAME IS - 2013/12/13(金) 23:56:53.11 ID:???.net (+57,+29,-29)

もうずいぶん前から予想できたことだろ
このスレでも何回もMySQLはオワコン、Oracle完全犯罪的な話出てきたろ
既定路線

318 : NAME IS - 2013/12/14(土) 13:06:29.41 ID:???.net (+128,+29,-5)

インデックス張ってももう無理だ
レコードが7億いった・・・

319 : NAME IS - 2013/12/14(土) 14:58:58.68 ID:???.net (+40,+22,-1)

すっごｗ

320 : 249 - 2013/12/14(土) 15:52:25.95 ID:???.net (+75,+29,-153)

>>318
十分なメモリと、最適なインデックスの追加、利用さえしておけば、
レコード数だけが問題になることはない気がするが...
（1レコードのサイズが大きいテーブルのレコード数が増えるのは問題
メモリが足りないんだったら、SSD にするかメモリつむ以外ないんじゃないかな。

経験上は下手なインデックスの利用、下手なテーブル定義が問題となることが多い。
メモリ 72G で 20億レコード、インデックス含めて64Gのテーブルとか運用してるけど
レコード数がどうこうより、データサイズどうにかしたい。

321 : NAME IS - 2013/12/15(日) 11:14:44.47 ID:???.net (+57,+29,-48)

7億レコードなんて別に大したことじゃ無いと思うが。
インデックスがメモリに乗らなくなったって言いたいんだろうけど。

322 : NAME IS - 2013/12/15(日) 11:50:57.01 ID:???.net (+18,-4,-2)

日本レコード大賞

323 : NAME IS - 2013/12/17(火) 16:35:22.30 ID:???.net (+87,+29,-33)

一度にひとつのキーでしか検索しない設計なんですが
どのキーで検索するかは状況によってバラバラです

検索に使われる予定のキーにかたっぱしからインデックスを
張っといた方がいいですかね？

324 : NAME IS - 2013/12/17(火) 17:04:56.45 ID:???.net (+97,+26,+0)

>>323
実測しろ

325 : NAME IS - 2013/12/17(火) 18:32:42.40 ID:???.net (+75,+29,-57)

>>324
そりゃするけどさ、念のために聞いておきたかっただけじゃん？

あと、これも実測しろと言われるの間違いなしなんだけど、
結果がひとつだけだと確信できるクエリのときも、あえて
LIMIT 1をつけたほうが速いのかな。速そうな印象はある

326 : NAME IS - 2013/12/17(火) 20:31:46.85 ID:???.net (+23,-4,-5)

テーブルスキャンのときは LIMIT 1 で早くなるはず

327 : NAME IS - 2013/12/17(火) 22:44:58.13 ID:???.net (+75,+29,-22)

>>318
四の五の言わずにioDrive入れちまえ。あのコスパの良さは明らかに異常。

328 : NAME IS - 2013/12/23(月) 22:10:41.65 ID:???.net (+3,-30,-66)

インストールするときにChoosing a Setup Typeのとこで
Developper Default, Server only, Client only, Full, Customから選びますがどのような違いがあるのでしょうか？

329 : NAME IS - 2013/12/24(火) 21:55:49.74 ID:???.net (+0,-28,-41)

その質問をする人は、Defaultで問題ない
簡単に言うとインストールされるファイルの組み合わせを選ぶ
具体的な違いを教えろって？ggr

330 : NAME IS - 2013/12/25(水) 22:40:19.62 ID:???.net (-1,-29,-21)

試しにインストールしてみたのですが、Developper DefaultとFullは同じな気がします。

331 : NAME IS - 2013/12/27(金) 11:01:17.77 ID:RABYehPe.net (+24,+29,-56)

InnoDB三ヶ月に1回ぶっ壊れるようにわざとしてるだろ？
不満なら有料のもの買えってことか。
タダより高いものはないな。

332 : NAME IS - 2013/12/27(金) 12:39:19.36 ID:???.net (+52,+29,-2)

壊れねぇよ
どういう使い方してんだ

334 : NAME IS - 2013/12/27(金) 19:03:50.29 ID:???.net (-6,-29,-12)

--password=9999

339 : NAME IS - 2014/01/13(月) 12:32:29.31 ID:???.net (+48,+29,-44)

>>338
～～ FOR UPDATE で排他ロックをかけてるときは、理解の通りロックかけたトランザクションが
コミットかロールバックするまで、ほかのトランザクションはいかなるアクセスもできないはず。

340 : NAME IS - 2014/01/13(月) 16:12:42.90 ID:???.net (+50,+27,-3)

読みだしはできる

341 : NAME IS - 2014/01/13(月) 16:15:38.53 ID:JNIvUl1u.net (-22,+26,-1)

>>339-340
どっちが本当？

342 : NAME IS - 2014/01/13(月) 16:24:09.24 ID:???.net (-6,-29,-3)

ユーザーBのSQL次第

344 : NAME IS - 2014/01/13(月) 17:27:20.43 ID:???.net (+57,+29,-31)

両方 UPDATE 付いてたら待たされるはず。
ロックかかってるとSELECT失敗するわけじゃなくて、終わるまで待つだけよ？

試しに手入力でやってみては

346 : NAME IS - 2014/01/13(月) 18:44:14.12 ID:???.net (-5,+8,-24)

>>345
実はSQLでデータ取っていなくて、サーバのキャッシュを取得していたとかいうオチでは？

348 : NAME IS - 2014/01/13(月) 19:22:08.42 ID:???.net (+30,+7,-17)

クエリーログ取るんじゃダメ？

349 : NAME IS - 2014/01/13(月) 19:31:35.69 ID:JNIvUl1u.net (-20,+29,-26)

うーん、何度見てもキャッシュはしっかりfalse指定されてた
実は滅多に再現しないから、ログ取るようにして気長に再発を待つしかないかな

350 : NAME IS - 2014/01/14(火) 10:41:08.32 ID:???.net (+27,+0,-13)

どこかに FOR UPDATE 抜けたやつが紛れ込んでるな

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで /

mysql スレッド一覧へ

みんなの評価 :

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

MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
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 総合 Part15 (1001) - [89%] - 2009/4/20 12:15 ☆
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 ○

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

総計:	127,615,542人
頁
昨日:	no data人
頁
今日:	人
頁