>>800
midに既に複合インデックスを他のカラムと作成済みだったのですが、こちらの方が頻度が多いので見直してみます。
INDEXのdescって意味があるんですよね？ちょっとぐぐってきます。

>>794-795
ありがとうございました
今まで使っていて「数字の左側の空白」は意識したことがなかったのですが、
事実上、この数字にはほとんど意味がないってことですね

文字列xからフィールド内の要素を検索するという事は可能でしょうか？
つまりxの中にフィールドの要素があるかを検索するという事です。

table a
+----+-------+
| id | value |
+----+-------+
| 1 | test |
| 2 | hoge |
| 3 | hoge |
| 4 | test |
+----+-------+

table b
+----+-------+
| id | a_id |
+----+-------+
| 1 | 1 |
| 2 | 2 |
| 3 | 2 |
+----+-------+

select a.id,count(b.id) from a left join b on a.id=b.a_id group by b.id;

+----+---------+
| a.id | count(b.id) |
+----+---------+
| 1 | 1 |
| 2 | 2 |
| 3 | 0 |
+----+---------+

この場合countが0のものを全て含めて抽出するにはどうすれば良いでしょうか？
上の場合
+----+---------+
| a.id | count(b.id) |
+----+---------+
| 1 | 1 |
| 2 | 2 |
| 3 | 0 |
| 4 | 0 |
+----+---------+

という結果を得たいのですが。

訂正

table a
+----+-------+
| id | value |
+----+-------+
| 1 | test |
| 2 | hoge |
| 3 | hoge |
| 4 | test |
+----+-------+

table b
+----+-------+
| id | a_id |
+----+-------+
| 1 | 1 |
| 2 | 2 |
| 3 | 2 |
+----+-------+

select a.id,count(b.a_id) from a left join b on a.id=b.a_id group by b.a_id;

+----+---------+
| a.id | count(b.a_id) |
+----+---------+
| 1 | 1 |
| 2 | 2 |
| 3 | 0 |
+----+---------+

この場合countが0のものを全て含めて抽出するにはどうすれば良いでしょうか？
上の場合
+----+---------+
| a.id | count(b.a_id) |
+----+---------+
| 1 | 1 |
| 2 | 2 |
| 3 | 0 |
| 4 | 0 |
+----+---------+

という結果を得たいのですが。

>>804
日本語でおｋ

>>805,806
group byを適用する前にどうなるか見てみればわかるが、
a_idはbにない要素についてはNULLになってしまうので
よくない。

mysql> select * from a left join b on a.id=b.a_id;
+----+-------+------+------+
| id | value | id | a_id |
+----+-------+------+------+
| 1 | test | 1 | 1 |
| 2 | hoge | 2 | 2 |
| 2 | hoge | 3 | 2 |
| 3 | hoge | NULL | NULL |
| 4 | test | NULL | NULL |
+----+-------+------+------+
5 rows in set (0.00 sec)

a.idを使えばいいと思われる。そもそもgroup byに使ってない
カラムを集約関数なしでselectするのは本来は反則だしね。

mysql> select a.id,count(b.id) from a left join b on a.id=b.a_id group by a.id;
+----+-------------+
| id | count(b.id) |
+----+-------------+
| 1 | 1 |
| 2 | 2 |
| 3 | 0 |
| 4 | 0 |
+----+-------------+
4 rows in set (0.00 sec)

>>808
ありがとうございます。
NULLになってNULLで集約されてしまっているのはわかっていたんですが、方法が思いつきませんでした。
助かります。

>>807
すいません。%を入れることで自己解決しました

すいません質問させて下さい

カウンターをmySQLで作ったのですが、現状は
セレクトで数字を出し
PHPで1を足して
アップデートで入れてます。

これで不便は無いのですが
カラムからレコードを取り出さずに直接中の値を加算する事はできないですか？
できたら便利かと思って。

UPDATE table SET col = col + 1 WHERE ・・・

ストアドで加算しつつ取り出すこともできないことはないが・・

>>812-814
ありがとうございます
さっそく今から試してみます
表示が必要なカウンタは結局取り出さなきゃいけませんが
ファイルのダウンロード数をカウントして自分だけで見るカウンタもあるので、そういうのに使ってみます。

メールサーバ専用のサーバで
postfixをmysqlにて使っているのですが、
クエリで
SELECT forward FROM postfix WHERE username='%s' AND active='Y'
と、基本的には、AND でフラグで有効なユーザを絞り込んでいるのですが、

activeフィールドは、1と0のvarcharなのですが、
このフィールドにはインデックスを指定したほうがいいのでしょうか？

4時間稼働した状態で、phpmyadminでは
Handler_read_rnd_next 11 k

データファイルの次の行を読み込んだリクエストの数。
この値が高いのはテーブルスキャンを大量に実行しているためです。
一般にこれはテーブルのインデックスが不適切か、
クエリがインデックスを利用するように書かれていないことを意味します

とあるのですが、
ユーザアカウントには、usernameだけをインデックスに指定しています。
どのように行えば、このエラーが少なくなるのでしょうか？

>>790
ありがとうございます。
非常に助かりました。

もう一点質問させてください。

CREATE TABLE `diary` (
`id` bigint(20) NOT NULL auto_increment,
`date` date NOT NULL,
`mid` varchar(10) NOT NULL,
`title` varchar(200) NOT NULL,
`comment` text NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `mid_date` (`mid`,`date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `comment` (
`id` bigint(20) NOT NULL auto_increment,
`diary_id` bigint(20) NOT NULL,
`wtime` datetime NOT NULL,
`mid` varchar(10) default NULL,
`mname` varchar(30) NOT NULL,
`comment` text NOT NULL,
PRIMARY KEY (`id`),
KEY `mid` (`mid`),
KEY `diary_id_id` (`daiary_id`,`id`)
CONSTRAINT `comment_diary_id_fk` FOREIGN KEY (`diary_id`) REFERENCES `diary` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


SELECT d.id,d.title,c.diary_id,c.mname,c.comment FROM comment c, diary d WHERE d.id = c.diary_id AND d.mid='hoge' ORDER BY c.id DESC LIMIT 5;

日記用のテーブルとそのコメント用のテーブルの結合なのですが、
以上のクエリのORDER BYでUsing temporary; Using filesortとなってしまいます。
この場合は複合KEYで対応できないのでしょうか？
テーブル設計自体に問題があるのでしょうか。

>>820
ありがとうございます。
(1)だと期待する結果ではないので使えません。（あくまでコメントの最新5件を拾いたいため）
(2)は当方のテーブルでは逆に時間がかかりそうです。

クエリを二回にわけると、どうなのでしょうか？以下のようにすると速度的には早くなるのですが。

SELECT c.id FROM comment c ,diary d WHERE d.id=c.diary_id AND d.mid='hoge';
SELECT * FROM comment WHERE id=○ OR id=○ OR ・・・ ORDER BY id DESC LIMIT 5;


d.midをcommentテーブルにも作成しようと思ったのですが、正規化という呪縛にとらわれてしまって・・・
そもそもテーブルをわけない方がいいんですかね？

>>822
(1)と(2)は元のクエリをmysqlが実行するときの内部動作の説明でした。
わかりにくかったらすいません。

d.midをcommentにつくるのは正規化には反するかもしれません。重複
するデータをあちこちに持ちたくないというのはわかります。私もどうして
も速度を稼ぎたいときにしかやりたくないです。mid='hoge'から拾い出される
commentの数がそれほど多くないなら今のままでもなんとかなるんじゃ
ないでしょうか。

>>823
勘違いしました。
現在でもmid='hoge'の該当数が多い場合があるので最適化してるんですが、期待の結果を得るにはd.midを重複させるしかないみたいですね。
あまり正規化にとらわれずにやってみます。

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

>>811
ロックしなくてもいいのかな？
Apacheだから複数プロセスが走っているような。。。
実用上問題なしかも。
カウンターが正確である必要ないなら。
詳しくは竹村健一先生に聞いてください。

この順番でやればおｋ
begin;
update counter set count = count + 1;
select count from counter;
commit;

こっちでもおｋ
begin;
select count from counter for update;
update counter set count = (PHPで計算した値);
commit;

MySQL5.1でInnoDBを使っているのですが、
参照専用で、更新は数ヶ月に1回のテーブルがあります。

参照の回数が非常に多いので、このテーブルを同じ構造のMEORYテーブルを作って、
そこにアクセスするようにしたのですが、これって、クエリーキャッシュという機構があるので、
まったく無駄なことでしょうか？

クエリーキャッシュが働くことによって、MEMORYテーブルを作ったのと同じように、
ディスクアクセスが無くなるということで正しいでしょうか？

作ってしまってから、ディスクキャッシュという機構を知ったので、
いまどうしようか、悩んでいるところです。

クエリキャッシュは、一度処理したクエリの結果を保持しておくもの。
MEMORYはDBをオンメモリで持っておくもの。

一度も処理してないクエリはクエリキャッシュでは高速化できない。
よって、クエリのばらつきが多い場合はMEMORYのほうが有利と言える。

ただしMEMORYといえど検索コストはかかるので、
特定のクエリばっかりの場合は逆にクエリキャッシュのほうが有利とも言える。

フィールドの移動ってできないのかな？
idってフィールドを3番目に作ったんだけど、
これを1番目に表示するようにしたいんだよね

だいたいやね。

すみません、以下のように修正します
insert into cateTable (`cateName`,`id`) value('スープ',0)
insert into menuTable (`menuName1`,`cateId`,`id`) value('ポタージュ',{$cateId},0)

エラーが発生しているのにメニューテーブルへの処理を続行すること自体がおかしい。
どういう異常パターンで何がしたいの？

>>837
どうもありがとう
ｶﾃｺﾞﾘTABLEへの登録がちゃんと済んだときのみ、ﾒﾆｭｰTABLEにも
登録するようにしたいんです
自分としては>>835のプログラムで対応を考えてるんですが、、
あれだと、２つめのクエリ（ﾒﾆｭｰTABLE）が成功するとは限らないし、
失敗した場合は結局　１つめだけ成功・２つめ失敗になります

その辺の対処をどうしたらいいのか、出来ればSQL文の簡単なサンプルと
あわせて教えてもらえるとうれしいです。

PHPに限らず、try-catchによる例外処理と
データベースのトランザクションについては、
いまのうちに勉強しといたほうがいいと思います。

try {
　begin;
　insert 1個目;
　insert 2個目;
　commit;
} catch (例外) {
　rollback;
}

>>841
ありがとうございます！
それ、勉強してみます！

>>845
適当なテーブル作って試してみればいいじゃん。
なんでも聞けばいいってもんじゃないだろ。

メモ帳やめて秀丸でやればいいんじゃね