元スレMySQL 総合 Part14
mysql覧 / PC版 / みんなの評価 : ☆
前へ
652 :
富山DQN男の家族消えろ 富山DQN男の親消えろ 富山DQN男の子供消えろ 富山DQN男の親戚消えろ
富山DQN男の家族消えろ 富山DQN男の親消えろ 富山DQN男の子供消えろ 富山DQN男の親戚消えろ
富山DQN男の家族消えろ 富山DQN男の親消えろ 富山DQN男の子供消えろ 富山DQN男の親戚消えろ
富山DQN男の家族消えろ 富山DQN男の親消えろ 富山DQN男の子供消えろ 富山DQN男の親戚消えろ
ニヤニヤ(・∀・) ニヤニヤ(・∀・) ニヤニヤ(・∀・) ニヤニヤ(・∀・)
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
死ぬとき このレスの事思い出してから地獄へ行けよ
ニヤ(・∀・)ニヤ(・∀・)
653 :
一応、解決策とはいえないまでもパーティショニングを行ったところ、かなりのパフォーマンス向上になりました。
報告だけさせて頂きます。
654 = :
何分割にしたかとかいくつに分けたとかドンくらい速くなったかとか
レポートキボン
655 = :
>>650
いえ、困っていません。
テストデータをselectしたときに気分が悪くなった、というだけです。
誤った認識が心に疑問を投げかけていたのです。
前述のカラム順序も実装させるプログラムではカラム名で取り出すので問題ありませんが、
select * って書いたときにこれまでは一番左にpkeyがあったのに、今じゃ真ん中に
pkeyがある、ってのがムカつくだけです。
order byにしろカラムの順序にしろ、実用性に欠ける質問でごめんなさい。
666 = :
技術者を雇う側からいうと、人事に話を通しやすいから、何であれ認定試験の資格があるとありがたい。
「この人はよくできる人です」と「この人は××のゴールド認定技術者です」では、聞こえ方が全然違う。
667 = :
>>664
できました！
どうもありがとうございました。
668 = :
>>666
「この人は、MySQLの認定技術者です」で、本当に聞こえがいいの？
673 = :
>>672
ケースバイケース。
てか効率だけで決めたら後々苦労するよ。
SELECT対象が10カラムのテーブル1個で済む場合、100カラムのテーブルを
使うよりもサイズが小さいためメモリのヒット率向上が見込まれる。
ディスクI/Oが減るため性能がよい。
SELECT対象テーブルが多いとだんだん悪くなる。
10テーブルへのinsert、updateは整合性を取るためにbegin～endで囲む
ことになる。気をつけないとデッドロックを起こす。
InnoDBのページサイズは16KB。
100カラムのテーブルはレコード長が伸びるため格納効率が悪くなる。
例えばレコード長6KBだと2レコードだけ入って、4KBすきまができてしまう。
MySQLはオプティマイザがあまり賢くないので多数のテーブルの結合は
おすすめしない。10テーブル結合して数分返ってこなくても泣かないこと。
まだまだ懸念点は出てくるはず
まずは教科書通りに設計して、実機で検証すべき
674 = :
>>671
マニュアル見て。ttp://dev.mysql.com/doc/refman/5.0/en/grant.html
675 = :
>>673様
ありがとうございます！
とても参考になりました。
InnoDBでした。後出しすみません。
一緒に使うパラメータはなるべく一つにまとめようと思います。
またすべてを使うことはあまりないので（管理時のみ）管理ページを改める方向でいきます。
本当にありがとうございました。
678 = :
ただしそれ、インジェクションの典型的な例に出るやつだから注意ねｗ
680 = :
>>678
便乗で申し訳ないが、なぜそれがインジェクションになるの？
684 = :
http://www.itmedia.co.jp/news/articles/0806/05/news047.html
とか既出？
ちょっぴり期待しています。
686 = :
>>683
データベース接続のラッパーにクオートさせてるだけだけど大丈夫か心配になってきた。
689 = :
>SERVER アパッチ
ということは、外から直接DBサーバに繋ぐのではなく、外からはhttp を叩き、apache が DBサーバを呼ぶ、という理解でいいのか?
それなら、野外でノートと、とか何とか無関係では。
695 = :
インデックスの張り方で悩んでいます。
pk access_date type
pkは主キー、access_dateはdatetime型の更新日時(のようなもの)、
typeは1～3とかの多くの行でかぶるカラム、です。
このテーブルで
select * from hoge
where type = 1 /* とか */
order by access_date
limit 1 /* とか */
こんなクエリをやっています。
現在はaccess_dateとtypeにこの順で複合インデックスを貼っています。
access_dateが古いところにtypeが1のものがあれば早く取り出せてると思うのですが、
そうでない場合には頭から探してるようで遅いです。
○○調べてこいや、とかの助言でもいただけたらうれしいです。
696 = :
EXPLAIN調べてこいや
インデックスの張り方が多分逆の予感。
698 = :
>>696 >>697
お返事ありがとうございます嬉しいです。
やはりインデックスの順番が一番怪しいかなと思っていました。
友達に聞いたらtypeにビットマップなインデックスはってみ、普通のやつじゃ意味ねーよ、
って言われてmysqlじゃない話で落ち込んでました。
再度インデックス張り直してきます。30分ぐらいで終わる予定です。みんなこれぐらいかけてるのかな・・・。
ところで>>697氏のおっしゃる
> 更新日時を先にもってきたらその順番で並んでしまうだけでその
> あとにtype持ってきても意味がないよ。
この辺の話っていうのは、mysqlのインデックスに限った話ですか？
よければ参考書籍などを教えてもらえないでしょうか？
みんなの評価 : ☆
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について