元スレMySQL 総合 Part24
mysql覧 / PC版 /みんなの評価 :
302 = :
>>301
あんまりお勧めしないけど、どうしても嫌なら公開情報テーブルを別に作る
ユーザーID
該当テーブル名
公表フラグ
あとは公表フラグを元にプログラムで判定させる。
もしくはmemberテーブル自体を、
ユーザーID
該当項目(該当テーブル名)
値
公表フラグ
にしてしまう。これなら横に追加しなくても良い。
303 = :
MySQLのスレでポスグレでもオラクルでもできるテーブル設計の話
ドヤ顔で始めるチンカスってなんなの?
304 :
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10117233810
これわかる方お願いします><
307 = :
wwww
308 = :
>>304
もうちょっと画質が良いのないの?
309 = :
まるち、ていわないんだ
310 :
予約語を避けるにはどうしたらいいかな
適当な接頭語をつけるのが一番楽かな
313 = :
RHELにはいったのはMariaDB5.5。安定版だよ。
それにディストリ固有のパッケージ使いたい人たちが多数。
普通はパッケージ管理なんてやりたくないんだよ。
そもそもMySQLのバージョンアップのほうがキツいだろ。
ボロボロの状態でGAリリース、何年たっても不安定。
314 = :
この人たち、裏で必死に転職活動してそうだわ
http://twitter.com/RKajiyama/status/387821488759250944
315 = :
>>313
出たばっかの頃はいいが、そっから3年くらいはずっとそのままのバージョンで行くんだぜ。。。
そなるといずれは自分で入れることになるんだから。
316 = :
>>315
>そなるといずれは自分で入れることになるんだから。
MariaDBをだろ
だからMySQL終了だっつうのw
>出たばっかの頃はいいが、そっから3年くらいはずっとそのままのバージョンで行くんだぜ。。。
まじめな話、Maria10.0なんてまだαだし、5.5で数年行くのは正しいだろ。
Maria5.5とMySQL5.5はほとんど同じだし。
RHELなど主要ディストリビューションがMySQLからMaria5.5から切り替えたのはデカイよ。
よほどの物好きか、最新版大好きの素人しかMySQL5.6に移行しないだろう。
317 = :
もうずいぶん前から予想できたことだろ
このスレでも何回もMySQLはオワコン、Oracle完全犯罪的な話出てきたろ
既定路線
318 = :
インデックス張ってももう無理だ
レコードが7億いった・・・
319 = :
すっごw
320 = :
>>318
十分なメモリと、最適なインデックスの追加、利用さえしておけば、
レコード数だけが問題になることはない気がするが...
(1レコードのサイズが大きいテーブルのレコード数が増えるのは問題
メモリが足りないんだったら、SSD にするかメモリつむ以外ないんじゃないかな。
経験上は下手なインデックスの利用、下手なテーブル定義が問題となることが多い。
メモリ 72G で 20億レコード、インデックス含めて64Gのテーブルとか運用してるけど
レコード数がどうこうより、データサイズどうにかしたい。
321 = :
7億レコードなんて別に大したことじゃ無いと思うが。
インデックスがメモリに乗らなくなったって言いたいんだろうけど。
322 = :
日本レコード大賞
323 = :
一度にひとつのキーでしか検索しない設計なんですが
どのキーで検索するかは状況によってバラバラです
検索に使われる予定のキーに かたっぱしからインデックスを
張っといた方がいいですかね?
324 = :
>>323
実測しろ
325 = :
>>324
そりゃするけどさ、念のために聞いておきたかっただけじゃん?
あと、これも実測しろと言われるの間違いなしなんだけど、
結果がひとつだけだと確信できるクエリのときも、あえて
LIMIT 1をつけたほうが速いのかな。 速そうな印象はある
326 = :
テーブルスキャンのときは LIMIT 1 で早くなるはず
327 = :
>>318
四の五の言わずにioDrive入れちまえ。あのコスパの良さは明らかに異常。
328 = :
インストールするときにChoosing a Setup Typeのとこで
Developper Default, Server only, Client only, Full, Customから選びますがどのような違いがあるのでしょうか?
331 :
InnoDB三ヶ月に1回ぶっ壊れるようにわざとしてるだろ?
不満なら有料のもの買えってことか。
タダより高いものはないな。
332 = :
壊れねぇよ
どういう使い方してんだ
339 = :
>>338
~~ FOR UPDATE で排他ロックをかけてるときは、理解の通りロックかけたトランザクションが
コミットかロールバックするまで、ほかのトランザクションはいかなるアクセスもできないはず。
340 = :
読みだしはできる
344 = :
両方 UPDATE 付いてたら待たされるはず。
ロックかかってるとSELECT失敗するわけじゃなくて、終わるまで待つだけよ?
試しに手入力でやってみては
348 = :
クエリーログ取るんじゃダメ?
350 = :
どこかに FOR UPDATE 抜けたやつが紛れ込んでるな
みんなの評価 :
類似してるかもしれないスレッド
- 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 ○
トップメニューへ / →のくす牧場書庫について