元スレMySQL 総合 Part25
mysql覧 / PC版 /みんなの評価 :
3 = :
limitで抜き出した時に、order byに指定がないカラムがある場合、順序が一定してないと思った。
これのことかな?
4 = :
>>3
ORDER BY自体は効いてて実効タイミングがLIMIT後になるので若干違う様な気がする。
LIMITすると全カラムORDER BY必須になると言うのも驚愕だけれど。
5 :
質問させてください
データがガリガリ書き換えられているときに、
mysqldumpでデータのバックアップ取ったときって、
dumpしたsqlファイルにデータの不整合は起きないのでしょうか。
起きないとしたらそれはどのような仕組みによって実現されているのでしょうか
教えていただけると嬉しいです
7 = :
それで済むならそれで
トランザクションログ使うてもあるが、、、
9 = :
1行ごとに改行??
行を改めるで改行なんだけど何言ってんの?
10 = :
>>9
1レコードごとに改行させたい
ですすみません
11 = :
mysql使ったことのない俺が言うのもなんだけど、mysqldumpって1レコードごとに改行されないの?
12 = :
例えば、こんな感じ
INSERT INTO `t_test` VALUES (1,3),(1,4),(1,5),(2,4),(3,1),(4,1),(4,2),(5,1);
13 = :
ちょっとマニュアルみてみたけど、
--skip-extended-insert
つけたらどうかな?
14 = :
違うのか、>>12 はこう出したいという例も書いてくれ、、、
VALUES (1,3),
(1,4),
(1,5),
・
・
こうしたいの?
sed挟んだら
15 = :
すまん、オレは質問者じゃない。
>>14
うん、オレもそうしている。
17 = :
出力したあと痴漢すれば?
19 = :
なんだそれ、マジで聞いてんのか?w
どう考えても設定ファイルのdefault-storage-engine=innodbって設定を見なおせって書いてあるように思うが。
/etc/my.cnf調べりゃあるべや
20 :
>>19
ご回答ありがとうございます
ただ、その設定があることは知っているんですが
何が間違っているのかがよくわかりません。
innodbの設定は間違ってますでしょうか?
22 = :
>>20
設定が[mysql]セクションに入っているとそうなる
そのパラメータは[mysqld]セクションに入っていないとおかしい
23 :
>>22
ありがとうございます!
24 = :
ビッ○カメラ札幌店の副店長の佐藤伸弦が暴行事件が起きていた
佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦
佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦
佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦
佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦
佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦
26 = :
データベースが重くなってきたのでインデックスを作ろうと思っているのですが以下のどちらが参考になるでしょうか?
・エキスパートのための MySQL …
(技術評論社)
・MySQL トラブルシューティング
(オライリー)
データベースはMariaDB 10です。
27 = :
csvをmysqlに自動的にテーブルも作成して読み込ませたいです。
phpmyadminでcsvを読み込むときに自動的にテーブルも作成してくれますが、
mysqlimportやload data infileでは私が調べた限り無理のようでした。
なにかいい方法はありませんか?
csvファイルは100近くあるのでできればphpmyadminのようなGUIではなく、
コマンドラインでどうにかしたいです。
28 = :
解決しました
サードパーティを利用することにしました
これ使います
http://github.com/crowdsavings/csv-to-mysql
29 = :
>>26
どちらもすでに良く設計されたデータベースの運用のための本であって、
インデックスの作り方のコツなんかは書いてない。
実践ハイパフォーマンスMySQL 第3版(オライリー)
をまずじっくり読むべし。電子版もあるよ。MariaDBでも同じ。
30 = :
>>26
今月出たばかりの「理論から学ぶデータベース実践入門」でもいいんじゃまいか
11章でインデックスの仕組みや種類、適用すべきパターン等それこそ詳しく解説してるぞ
31 = :
>>29
ありがとうございます。
待ちきれずに「エキスパートの…」を買って家に戻った所でレスが…。
(´;ω;`)
あと30分待てば良かったと後悔しつつ
再度本屋に行って「実践ハイパフォーマンス…」を買いました。
インデックスだけでなくレプリケーションも詳しく掲載されていたので助かりました。
>>30
本屋でその本にも目を通したのですが本当に理論の部分が詳しくて私のように「具体的なやり方」を求めている初心者にはハードルが高かったです。
32 = :
>>31
背景となる理論の裏付けがないと勘違いする人多い
みんなDB設計でインデックス設定するよね。でも
DB設計→SQLを書く→インデックスを設ける
が本来あるべき姿
33 = :
あるテーブルの一つのカラムに存在する値の種類一覧を取得する方法ってDISTINCTしかないんですかね?
hoge
hoge
huga
fizz
fizz
fizz
みたいな感じの時に、
hoge
huga
fizz
と返してほしいんです
distinctのいっぺん全取得してから削除ってのは無駄が多い気がするし、かといってexistsで書き換えるのも難しいし…
何か良い方法はないでしょうか?
34 = :
>>33
group byでもできるけど内部処理は多分同じ。
効率を気にするなら最初から第二正規化しとけばっていう話かも。
35 = :
条件結合みたいな方法ってあるのでしょうか?
・ユーザーテーブルのgroup_idが1ならプロフィールテーブルと結合
OR
・ユーザーテーブルのgroup_idが2なら会社テーブルと結合
と言ったイメージなのですが、ググっても出来そうな気がしません。
もし、ググり方が悪くて出来るのでしたら、結合方法を教えてください。
36 = :
>>35
良い方法はないと思う。UNIONで書けるかどうか考えてみて、
UNIONで書けるようなら、そもそも会社テーブルとプロフィールテーブルを
分けた意味があったのかどうか考えてみよう。
SELECT … FROM user JOIN profile ON user.profile_id = profile.id
WHERE user.group_id = 1
UNION ALL
SELECT … FROM user JOIN company ON user.company_id = company.id
WHERE user.group_id = 2
38 = :
じゃあ普通に横に外部結合で足せば?
from ユーザーテーブル
left join プロフィールテーブル on (group_id = 1 and ユーザーIDとなにか)
left join 会社テーブル on (group_id = 2 and ユーザーIDとなにか)
39 = :
>>38
なるほど。つまり、ユーザーテーブルに2つテーブルを結合するんですね。
どっちかのテーブルに値が存在することで「一般会員」と「会社会員」と分けられそうですね。
参考にします。ありがとうございました。
40 = :
某所で話題になったMySQLの寿司ビール問題
これみんな知ってた?
古いモバイルサイトなんかヤバそうなんだけど。
http://blog.kamipo.net/entry/2015/03/23/093052
41 = :
なぜ"古いモバイルサイト"がヤバそうだと思い至ったのかがわからない
42 = :
>>40
別にあたりまえの実装だし、照合順序の違いもわからないやつが、
明示的に utf8mb4 を指定するとは思えない。
ましてや古いモバイルサイトが最近実装した utf8mb4 を使って居るとも思えない
43 = :
>>40
そういう文字の検索に対応しなきゃいけない人達は
そもそも _ci の照合順序は使わないんじゃないかな
47 = :
荒らしたい時?
48 = :
SELECTしたデータをWebに表示しているDBがあるのですが、このDBに一定の時間帯でWebでスクレイピングしたデータを取り込むようにしています。
同一サーバー内でデータ挿入用のDB(もしくはテーブル)と参照用のDB(もしくはテーブル)に分けてレプリケーションすると多少は負荷の軽減になりますか?
みんなの評価 :
類似してるかもしれないスレッド
- 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 ○
トップメニューへ / →のくす牧場書庫について