私的良スレ書庫

不明な単語は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で

551 : NAME IS - 2014/05/15(木) 00:24:58.72 ID:???.net (+28,-5,+0)

>>550
できます。

552 : NAME IS - 2014/05/15(木) 10:38:18.02 ID:7rqME05r.net (+74,+29,-44)

>>551
ぐぐっても見つけられないのですが
やり方を教えてもらえますか

ちょっと特殊な要件でinsertやupdateは自動変換してほしくて、selectは変換しないでほしいと言った
使い方をしたいのですが

553 : NAME IS - 2014/05/15(木) 12:50:46.89 ID:???.net (+67,+29,-24)

>>552
要件はしらんが、やり方はぐぐってすぐわかるんだが。
ググり方下手なんじゃないの？

554 : NAME IS - 2014/05/15(木) 19:40:14.02 ID:???.net (+12,-30,-121)

>>552
> ちょっと特殊な要件でinsertやupdateは自動変換してほしくて、selectは変換しないでほしいと言った
> 使い方をしたいのですが
そもそもalter tableで解決するの？
保存している文字列自体の文字コードを、character_set_clientを変更することにより自動で変換したいように見える。
もちろんそんなことは出来ないけど。

555 : NAME IS - 2014/05/15(木) 20:27:39.03 ID:???.net (+7,-30,-122)

具体的に言うと、テレビのEPGデータがshift_jisと思われるのですが
海外のソフトを使うとテーブルがUTF8なんで文字化けしちゃうので
EPGテーブルをテーブルにinsertするときに変換して
検索するときにはUTF８で使いたいという内容です

556 : NAME IS - 2014/05/15(木) 21:50:49.96 ID:NZTm8MNZP (+38,+29,-25)

>>559
それだと、期間の最後のほうにそのデータがあるとき、
期間で検索すると変なことにならない?

557 : NAME IS - 2014/05/15(木) 21:55:53.80 ID:NZTm8MNZP (+33,+30,-135)

ある書類に関するデータベースを作っているんだけど、
そのなかに、作成年月日を作ってあるんだけど、
昔の書類は年月日までなくて、年とか年月までとか
そんなデータしか残ってないものもあって、
そんな書類が膨大にあって、そのデータをいろいろ
検索したい。作成の年・月・日がわかっているものは、
期間検索でばさっと検索できるけど、月までしかない
もののとき、1日とか入れちゃうと、本当に1日に作成されている
ものとぐちゃぐちゃになるし、期間検索で、月の途中から
途中までで検索したいとき、うまくひっかからないことがある。
そういうのをどうすればいいかなーと悩んでます。

558 : NAME IS - 2014/05/15(木) 21:02:53.84 ID:???.net (-1,-30,-36)

>>555
character_set_clientを変更しても解決しない。
アプリ側で文字列をUTF-8にエンコードするしかないね。

559 : NAME IS - 2014/05/15(木) 21:33:02.27 ID:???.net (+81,+29,-50)

ものすごい初歩的なこと聞いていい?
日付データ的なもので、年と月までのデータがあるんだけど、
これってどうするの?　今はとりあえずテキストで1999年12月
とか入れてあるけど、期間で検索できないから困ってる。

560 : NAME IS - 2014/05/15(木) 21:37:30.35 ID:???.net (+36,+13,-4)

日付に１を入れておく、とか？

561 : NAME IS - 2014/05/15(木) 21:51:48.98 ID:???.net (+7,+29,-20)

カラムの詳細（型とか）と最終的にやりたいことが分からないから答えようがない。
まとまったら
http://toro.2ch.net/test/read.cgi/db/1371476534/
で聞けばいい。

562 : NAME IS - 2014/05/15(木) 21:59:33.80 ID:???.net (+184,+29,-47)

昔の文献のデータベースを作ってるんだけど、
昔の文献には作成年月日が詳細に書かれていないものが多くて、
月までしかわからないものは月までにしておかないと、
詳細に作成年月日がわかっているものと区別がつかなくなる。
それに下手に1日とか15日とか入れちゃうと、期間検索したときに
不都合多そうで。

563 : NAME IS - 2014/05/15(木) 23:17:56.76 ID:???.net (+25,-30,-15)

mysqlだと日付に0入れることが出来るけどね
こんな感じで
insert into dd values ('2014-05-00');

564 : NAME IS - 2014/05/16(金) 04:38:32.72 ID:???.net (+76,+29,-36)

>>562
昔、悩んだことがある。
日だけ別のフィールドを作れば理論的には区別できるけど面倒。

実用的には日まで気にして検索することは少ないので、日が不明なのは15日と仮定し、オリジナルのデータを別フィールドで持つことにした。

565 : NAME IS - 2014/05/16(金) 08:14:30.39 ID:???.net (+48,+11,-40)

>>563
それって言語によって2014-04-30と認識しちゃうとか?
ポスグレ移行も考えてるのでなるべく標準に近いデータにしたい。

どうすりゃいいんだろ。普通に年・月のデータってあると思うんだけど
ググってもわからないし。

566 : NAME IS - 2014/05/16(金) 08:27:04.68 ID:???.net (+117,+19,-8)

え、６桁の数字とか文字にするのはだめなの

567 : NAME IS - 2014/05/16(金) 08:47:37.04 ID:???.net (+56,+28,-4)

うちの音楽ＤＢは不明は１日にしちゃってる

568 : NAME IS - 2014/05/16(金) 13:39:56.94 ID:???.net (+68,+29,-28)

>>566
日付の足し算、引き算の必要がないなら、ストリングでよいですね。
期間指定して検索もできます。

569 : NAME IS - 2014/05/16(金) 15:03:40.33 ID:???.net (+61,-7,-14)

INTEGER でいいじゃんか。
計算も工夫すりゃそのままできるし

570 : NAME IS - 2014/05/17(土) 07:49:28.47 ID:???.net (+111,+29,-110)

>>566
>>569
いやそれだと日付が詳細まで入力してあるのが、、、、、と思ったけど、
10桁の数字にして月までのデータは末尾0000にすればいいのか?
期間検索できるし。日数計算できないけど、それは考えようか。
、、、、、、、とすると、今まで入力した日付データを変換するには、、、、
5000くらいデータあるけど、手修正かorz?　質問してよかったぁ。
数万になってからでは目もあてられんかったorz

数字10桁の期間検索用フィールド入力→日付データに日付型に
変換して入力(月までのデータは適当に)とかかなあ。あー面倒orz。

571 : NAME IS - 2014/05/17(土) 10:15:29.35 ID:???.net (+52,+29,-3)

俺なら精度のカラム作るな

572 : NAME IS - 2014/05/17(土) 10:33:16.95 ID:???.net (+145,+29,-41)

>>570
まあどれがいいかは今後の運用方法によるけど
変換はUPDATE文工夫すれば数十万件なら一瞬だよ

573 : NAME IS - 2014/05/17(土) 12:08:37.27 ID:???.net (+84,+29,-8)

>>572
ぜひ詳しく。

>>572
ですよね～。SQLおぼつかないから勉強しないと。

574 : NAME IS - 2014/05/17(土) 17:56:26.38 ID:???.net (+52,-30,-82)

>>573
文字型では難しくて、日付型だと簡単なのは、日付の足し算、引き算だけでは？
>>562　の文献データベースなら、日付の足し算とか引き算は

文字型でも期間指定で検索ができるよ。
PubDate >= "1853年07月08日" AND PubDate <= "1854年06月01日"

少し話は違うけど、「嘉永6年」ではなくて「癸丑」と干支だけ書かれた文献もあるよ。

575 : NAME IS - 2014/05/17(土) 17:57:42.50 ID:???.net (+79,+29,-19)

>>574

×　>>562　の文献データベースなら、日付の足し算とか引き算は
○　>>562　の文献データベースなら、日付の足し算とか引き算は不要では

576 : NAME IS - 2014/05/19(月) 22:16:03.67 ID:???.net (+23,-30,-38)

(´・ω・｀)バックアップ取るとき、default-character-setにbinaryを指定するのって変？

577 : NAME IS - 2014/05/20(火) 13:05:08.37 ID:???.net (+44,+18,+0)

>>576
安全

578 : NAME IS - 2014/05/22(木) 01:44:14.44 ID:???.net (+40,+12,-6)

バイナリーが文字コード依存じゃないからよいのでわー

579 : NAME IS - 2014/05/22(木) 17:52:03.74 ID:???.net (+49,+26,-12)

Mariaさまがみてる

580 : NAME IS - 2014/05/22(木) 22:53:46.84 ID:???.net (+57,+29,-57)

会社でmysql使ってるんだけど
Dumpしたデータをリストアしようとしたら、途中から急にメモリが跳ね上がってサービスが強制終了するんだけどなんで？
どこ調べても解決しない

582 : NAME IS - 2014/05/26(月) 23:37:23.25 ID:???.net (+57,+29,-8)

入門本というか基礎本一冊終わらしたんですが次に買うのにオススメの本はありますか？

583 : NAME IS - 2014/05/27(火) 00:07:18.05 ID:???.net (+57,+29,-40)

本読むのも良いし止めろとは言わないけど、自分で実際にデータ入れて作業してみたら？
そこで、外部制約かけたりとかストアドプロシジャ作ってみるとか

それから自分で出来る言語でDBアプリ作ってみるとか

584 : NAME IS - 2014/05/27(火) 12:57:46.93 ID:???.net (-1,-29,-14)

phpMyAdminでインポートタブのなかのフォーマットの中にCSV load dataみたいな名前のやつがあったのに無くなってしまった
元に戻すにはどうしたらよいですか？

586 : NAME IS - 2014/05/28(水) 05:20:49.87 ID:???.net (-5,-24,-5)

>>585
下のが早いならそれでいいじゃん。
count(*)してるからじゃないの？

587 : NAME IS - 2014/05/28(水) 20:51:20.13 ID:???.net (-5,-30,-42)

>>585
books.book_idには主キーかインデックスを作ってあると思うけど、
それを大前提として、それでも遅いならディスクI/Oかなあ。
Linuxならiostat -xm 1 で r/s と %util を見て。Windowsは知らん

590 : NAME IS - 2014/05/29(木) 01:34:48.86 ID:???.net (-7,-29,-108)

>>589
プラン同じだね。
下は結果がが50万行出てくるけど、50万行垂れ流すのが0.0027秒で終わるわけがない。
何らかのGUIツールを使っていて、1画面だけ表示、暗黙的にLIMIT 100とかしてない？
つまり上が遅いのではなく、下がインチキしている(最後まで処理をしていない)と言いたい。
プラン見る限り一時テーブルは作ってない。

それで個人的な感想ですけど、50万行の集計が2.2秒というのは「十分に速い」です。
明らかにI/Oはしていない。I/Oしてたら数分かかる。
もっと速くしたいなら前段にmemcachedなどを入れて結果をキャッシュしよう。

591 : NAME IS - 2014/05/29(木) 01:59:43.88 ID:???.net (+57,+29,-45)

あと、メンテナンスがつらくなるのでおすすめはしないけど
テーブルを非正規化してcommentsテーブルにdeletedカラムを入れてもいいと思う。
それで1秒は切れると予想。

592 : NAME IS - 2014/05/29(木) 06:31:55.57 ID:???.net (-8,-29,-41)

>>585
なぜcountなのにgroup byがないのですか？

left join使わず、出力も1行でいいですよね？

594 : NAME IS - 2014/05/29(木) 10:04:08.44 ID:???.net (-12,-29,-38)

>>589
booksにdeleted,book_idの複合インデックスってないのかな？
あとはleftでなくinnerかな。こっちのが普通かと

595 : NAME IS - 2014/05/29(木) 19:32:40.25 ID:???.net (-11,-29,-6)

>>589
ちなみに、count(comments.comment_id)だとどう？

596 : NAME IS - 2014/05/29(木) 21:22:03.18 ID:???.net (+21,-6,-17)

つまり*は重いので、取得は1列。
他は内部結合、インデックスと。

597 : NAME IS - 2014/05/30(金) 00:12:28.93 ID:???.net (+57,+29,-27)

こんなんんで2秒かかってたらPostgreSQLにボロ負けなんで許せません
あっちはハッシュを使ってくるのでどう戦いますかな

599 : NAME IS - 2014/05/30(金) 01:26:26.61 ID:???.net (+3,-30,-62)

> FROM (SELECT books.book_id FROM books WHERE deleted=0)
> INNER JOIN comments USING(book_id)
もEXPLAIN同じだろうし

comments.book_idには既にインデックス付けてるだろうし

↓しかないかも？
http://github.com/nekoatcafe/wiki/wiki/MySQL%EF%BC%9Acount(*)%E5%AF%BE%E7%AD%96

600 : NAME IS - 2014/05/30(金) 01:31:03.79 ID:???.net (-6,-30,-163)

>>598
あまり期待しないでほしいのだけれど、テーブル結合順を逆にする案。
大半の本が削除されている(deleted = 0が少ない)場合はこちらの方が速い。

CREATE INDEX books_deleted ON books (deleted);
CREATE INDEX comments_book_id ON comments (book_id)

SELECT STRAIGHT_JOIN COUNT(comments.comment_id)
FROM books INNER JOIN comments ON books.book_id = comments.book_id
WHERE books.deleted = 0

前へ 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 ○

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

総計:	126,369,175人
頁
昨日:	no data人
頁
今日:	人
頁