富山DQN男の家族消えろ　富山DQN男の親消えろ　富山DQN男の子供消えろ　富山DQN男の親戚消えろ
富山DQN男の家族消えろ　富山DQN男の親消えろ　富山DQN男の子供消えろ　富山DQN男の親戚消えろ
富山DQN男の家族消えろ　富山DQN男の親消えろ　富山DQN男の子供消えろ　富山DQN男の親戚消えろ
富山DQN男の家族消えろ　富山DQN男の親消えろ　富山DQN男の子供消えろ　富山DQN男の親戚消えろ
ニヤニヤ(・∀・)　ニヤニヤ(・∀・)　ニヤニヤ(・∀・)　ニヤニヤ(・∀・)
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
死ぬとき　このレスの事思い出してから地獄へ行けよ
ニヤ(・∀・)ニヤ(・∀・)

一応、解決策とはいえないまでもパーティショニングを行ったところ、かなりのパフォーマンス向上になりました。
報告だけさせて頂きます。

何分割にしたかとかいくつに分けたとかドンくらい速くなったかとか
レポートキボン

>>650
いえ、困っていません。
テストデータをselectしたときに気分が悪くなった、というだけです。
誤った認識が心に疑問を投げかけていたのです。

前述のカラム順序も実装させるプログラムではカラム名で取り出すので問題ありませんが、
select * って書いたときにこれまでは一番左にpkeyがあったのに、今じゃ真ん中に
pkeyがある、ってのがムカつくだけです。
order byにしろカラムの順序にしろ、実用性に欠ける質問でごめんなさい。

BINARYの解説に
「文字セットを持たず、ソートと比較は値の中の数値バイトに基づいているという意味です。」
というのがあるけどこれでしょうか？

ということは、大文字と小文字をきっちり分けたいデータはソートがうまく出来ないってことでしょうか？
これは日本語だけの問題ですか？
もしかして、ソートしたいカラムは大文字・小文字の区別はつけられなのですか？

ごめん
> VARCHAR(255) BINARY
は4.1の文法だった。5.0でも正しい。
collationがutf8_binになる。

でもなんでそのデータでマトモに動いてるのかは
まだ想像つかない。

load data infile で　datetime型に"Oct 16 2008 12:00AM"このような形式の
データを読み込みたいのですが可能でしょうか？
普通にやると0000-00-00 00:00:00で読み込まれてしまいます

MySQL5.0.67+CentOS5.2
glibc2.3のgz形式のバイナリパッケージを使っています


よろしくお願いいたします

>>663
$ cat data.csv
Oct 16 2008 12:00AM
Nov 17 2008 04:00PM

mysql> load data local infile 'data.csv'
-> into table loadtest (@var1)
-> set date = str_to_date(@var1, '%b %d %Y %h:%i%p');

Query OK, 2 rows affected (0.00 sec)
Records: 2 Deleted: 0 Skipped: 0 Warnings: 0

mysql> select * from loadtest;
+---------------------+
| date |
+---------------------+
| 2008-10-16 00:00:00 |
| 2008-11-17 16:00:00 |
+---------------------+
2 rows in set (0.00 sec)

MySQLの認定試験にこの手の問題が出ます。

MySQLの認定試験って市場価値あるの？
単に、OracleMasterのマネして金儲けしようとしているだけじゃないの？

技術者を雇う側からいうと、人事に話を通しやすいから、何であれ認定試験の資格があるとありがたい。
「この人はよくできる人です」と「この人は××のゴールド認定技術者です」では、聞こえ方が全然違う。

>>664

できました！
どうもありがとうございました。

>>666
「この人は、MySQLの認定技術者です」で、本当に聞こえがいいの？

grant文で権限をつけるデータベースを複数指定したい場合はどう知ればいいのでしょうか？
grant all privileges on hoge,hoge2.* to 'hoge' identified by 'hogehoge';

,区切りでやってみましたが無理でした。

>データベースを複数指定したい場合
ワイルドカード以外はできない。

＞６７０さん
ありがとうございます。
以下のようにワイルドカードで指定してもできません。
複数は無理なのでしょうか？

grant all privileges on hoge*.* to 'hoge' identified by 'hogehoge';

１００カラムあるテーブルと１０カラムのテーブルが１０こあるのでは
どちらが効率的に select,insert,updateできるでしょうか？

10カラムの方はselect時に個別（1テーブル）で事足りるものもありますしすべてを連結させる必要があるときもあります。
型はtinyint～textまで含まれています。

100個の方はビューを作るので擬似的に分けることはします。（なので管理がめんどくさいということはないです）

>>672
ケースバイケース。
てか効率だけで決めたら後々苦労するよ。

SELECT対象が10カラムのテーブル1個で済む場合、100カラムのテーブルを
使うよりもサイズが小さいためメモリのヒット率向上が見込まれる。
ディスクI/Oが減るため性能がよい。

SELECT対象テーブルが多いとだんだん悪くなる。

10テーブルへのinsert、updateは整合性を取るためにbegin～endで囲む
ことになる。気をつけないとデッドロックを起こす。

InnoDBのページサイズは16KB。
100カラムのテーブルはレコード長が伸びるため格納効率が悪くなる。
例えばレコード長6KBだと2レコードだけ入って、4KBすきまができてしまう。

MySQLはオプティマイザがあまり賢くないので多数のテーブルの結合は
おすすめしない。10テーブル結合して数分返ってこなくても泣かないこと。

まだまだ懸念点は出てくるはず
まずは教科書通りに設計して、実機で検証すべき

>>671
マニュアル見て。ttp://dev.mysql.com/doc/refman/5.0/en/grant.html

>>673様
ありがとうございます！
とても参考になりました。

InnoDBでした。後出しすみません。

一緒に使うパラメータはなるべく一つにまとめようと思います。
またすべてを使うことはあまりないので（管理時のみ）管理ページを改める方向でいきます。

本当にありがとうございました。

create table test(
id int unsigned not null auto_increment primary key,
passwd varchar(32) not null);

（たくさんのデータが入っていると仮定して）
ここから下のSQLを流した場合、
先にidを探してそのIDと合致するデータのpasswdの正否を判定するという認識で間違いないでしょうか？

select 1 from test where id = 1 and passwd = 'example';

一意なカラムがあるwhereにある場合は他の要素（この例だとpasswd）にindexを春必要はないでしょうか？
もしくはpasswdにもindexなどをはったほうがいいでしょうか？

ただしそれ、インジェクションの典型的な例に出るやつだから注意ねｗ

>>678
便乗で申し訳ないが、なぜそれがインジェクションになるの？

select 1 from test where id = 1 and passwd = 'example';
これをexampleの部分に入るべき生データをユーザーの入力で、 ' OR 1 = 1 とかいれられて
そのままSQLにしてしまうと、
select 1 from test where id = 1 and passwd = '' OR 1 = 1;
というSQLになって常に結果が見つかることになってしまう。

http://www.itmedia.co.jp/news/articles/0806/05/news047.html
とか既出？
ちょっぴり期待しています。

>>683
データベース接続のラッパーにクオートさせてるだけだけど大丈夫か心配になってきた。

>SERVER アパッチ
ということは、外から直接DBサーバに繋ぐのではなく、外からはhttp を叩き、apache が DBサーバを呼ぶ、という理解でいいのか?
それなら、野外でノートと、とか何とか無関係では。

MySQL Clusterで、
Server1: SQL-Node,Data-Node,Management-Node
Server2: SQL-Node,Data-Node
の構成で DBの HA構成を考えています。

この時 Server1が死んでも Server2だけで稼動してくれますか？

はじめて、MySQLをいれたのですが、リモートのホストとPhpMyAdmin(3.0.0)との接続ができません。

MySQLのバージョンは、
Server version: 5.0.67 MySQL Community Server (GPL)

apache 2.0.63
PHP 5.2.6
です。


PhpMyAdminの設定後、アクセスしようとすると、以下のエラーが出ます。

MySQLのメッセージ:

#2002 - サーバが応答しません (あるいはローカルの MySQL サーバのソケットが正しく設定されていません)

mysql 拡張をロードできません。PHP の設定を確認してください - ドキュメント


ただし、以下の簡易スクリプトだとSuccess!とでます。
<?php
if(!$conn = mysqli_connect('xxxx', 'xxxxxxx', 'xxxxxxx','mysql')) {

print "ConnectError";


}else {

print("success!") ;

}

?>

インデックスの張り方で悩んでいます。
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のものがあれば早く取り出せてると思うのですが、
そうでない場合には頭から探してるようで遅いです。

○○調べてこいや、とかの助言でもいただけたらうれしいです。

EXPLAIN調べてこいや


インデックスの張り方が多分逆の予感。

インデックスは指定したキーの順であらかじめソートした索引だと
思えばいい。

更新日時を先にもってきたらその順番で並んでしまうだけでその
あとにtype持ってきても意味がないよ。秒まで同じ更新日時の
レコードがtype別にまとまることになるが、そんなにはげしく更新
されないだろ?

type, access_dateの順のインデックスにすればtypeごとにaccess_date
順で並ぶので、type=1の一番古いの一つさがすのは簡単になる。

>>696 >>697
お返事ありがとうございます嬉しいです。
やはりインデックスの順番が一番怪しいかなと思っていました。
友達に聞いたらtypeにビットマップなインデックスはってみ、普通のやつじゃ意味ねーよ、
って言われてmysqlじゃない話で落ち込んでました。
再度インデックス張り直してきます。30分ぐらいで終わる予定です。みんなこれぐらいかけてるのかな・・・。

ところで>>697氏のおっしゃる
> 更新日時を先にもってきたらその順番で並んでしまうだけでその
> あとにtype持ってきても意味がないよ。
この辺の話っていうのは、mysqlのインデックスに限った話ですか？
よければ参考書籍などを教えてもらえないでしょうか？