10/08/01 13:59:47
アドバイスありがとうございます。
しかしながらやはりjoinよりexists(select～の方が
100倍以上早かったです。
SQLむずかすい；；（同じ結果を抽出するSQLを下に書きました）
（遅い）
SELECT a,b,c FROM t1
INNER JOIN chk ON (Yid = Wid and Mid = '$id')
where a = '1' and b = '2'
order by Time DESC
↓
速い
SELECT a,b,c FROM t1
where
EXISTS (SELECT * from chk where chk.Mid='$id' and chk.Yid = t1.c) and
EXISTS (SELECT * from t1 where a = '1 and b = '1')
order by Time DESC
148:143
10/08/01 14:06:19
訂正します
速い
SELECT a,b,c FROM t1
where
EXISTS (SELECT * from chk where chk.Mid='$id' and chk.Yid = t1.c) and
a = '1 and b = '2'
order by Time DESC
でした。場合によっては1000倍違いました。
149:NAME IS NULL
10/08/01 14:50:33
コピペミスってるのか知らんけど
遅い方の Yid = Wid と
速い方の chk.Yid = t1.c の条件がかみ合ってないよ
150:143
10/08/01 15:10:10
手打ち間違いしてしました。
見にくいので再度張りました。何度もすみません。
（遅い）
SELECT a,b,c FROM t1
INNER JOIN chk ON (Yid = t1.c and Mid = '$id')
where a = '1' and b = '2'
order by Time DESC
↓
速い
SELECT a,b,c FROM t1
where
EXISTS (SELECT * from chk where chk.Mid='$id' and chk.Yid = t1.c) and
where a = '1 and b = '2'
order by Time DESC
151:NAME IS NULL
10/08/01 15:57:41
下のパターンで速くなるなら、
上のクエリにSTRAIGHT_JOINつけてみて。
SELECT STRAIGHT_JOIN a,b,c FROM t1
INNER JOIN chk ON (Yid = t1.c and Mid = '$id')
where a = '1' and b = '2'
order by Time DESC
うまくいったら両方のEXPLAIN見せてほしい
152:143
10/08/01 16:23:58
元
1 PRIMARY rbbs ref Note,News News 18 const 3960 Using where; Using filesort
2 DEPENDENT SUBQUERY mytubu ref Mid,Yid Yid 4 community.rbbs.Wid 23 Using where
(1,362 合計, クエリの実行時間 0.1659 秒)
>>151の方法
1 SIMPLE t1 ref Wid,Note,News News 18 const 5808 Using where; Using filesort
1 SIMPLE mytubu ref Mid,Yid Yid 4 community.t1.Wid 23 Using where
(1,365 合計, クエリの実行時間 0.0629 秒)
1/3になりました！！！すごい！！！！
153:143
10/08/01 16:52:44
とおもったら、しばらく回してたら激重になっちゃいました。
もう少し本とか買って勉強したいと思います。
お付き合いありがとうございました。
154:NAME IS NULL
10/08/01 21:51:07
0.1秒を切るレベルでのチューニングなのか
そしたらちょっと難しいな
CREATE INDEX t1_test ON t1 (a, b, Time);
とやってEXPLAIN1行目のUsing filesortを消す、
さらに
CREATE INDEX mytubu_test (Yid, Mid);
とやってEXPLAIN2行目にUsing indexが付けばもうちょっと良くなるかも
あとはパラメータ側で、MyISAMならkey_buffer_size、
InnoDBならinnodb_buffer_pool_sizeを数十～数百MBに増やす、
それからsort_buffer_sizeを1～2Mに増やしてみるぐらいかな
155:NAME IS NULL
10/08/02 11:12:07
MySQL 5.0.91
CentOS 5.4
DBアクセスを参照のみに制限したくて、
GRANT SELECT on `test-db`.* to `db-user01`@`%` identified by 'password';
FLUSH PRIVILEGES;
とやったのですが、試したら普通にUPDATEできてしまいます。
書き込みを制限するにはどうすればいいんでしょうか？
156:NAME IS NULL
10/08/02 13:38:34
基本的な事聞いていいですか
where a=1 and b=5 and c=abc
a,b,c全てにインデックスを貼っている場合と、一つ或いは二つしか貼っていない場合だと速度は違いますか
つまりwhereで使うもの全てにインデックスを貼ったほうが性能があがるんでしょうか
157:NAME IS NULL
10/08/02 13:59:13
はい
158:NAME IS NULL
10/08/02 14:25:29
ありがとうございました。
159:NAME IS NULL
10/08/02 18:11:12
>>155
よくあるのがdb-user01以外で繋がってしまっているケース
mysql> status;
してCurrent user: を確認してみて
160:NAME IS NULL
10/08/03 12:08:01
>>159
どうもです。PHPからdb-user01で接続しているのでそれはないですね。
人に聞いたら、そもそもそういう書き込み制限はできないみたいです。
じゃあGRANT SELECTって何よ、って気もしますが…。ぐぐったらできそうなこと書いてあったんですが
実際できないものはしょうがない。
アプリ側で誤って書き込まないよう気を付けるしかないようですね。不安だ。
161:NAME IS NULL
10/08/03 12:55:51
ほんとに、updateとかの権限が無いかどうか確かめてみては?
use mysql;
select * from user where user='db-user01'\G
162:NAME IS NULL
10/08/03 14:04:05
>>161
どうもです。
いろいろ試してる間にSELECT権限も消しちゃったのか、priv関連は全部Nになってました。
それでも参照も書き込みもできます。
163:NAME IS NULL
10/08/03 15:16:29
そしたらあとはmy.cnfに
skip-grant-tables
が入っているとか？
164:NAME IS NULL
10/08/03 23:30:14 DnqSeYXe
MySQL Clushter(GPL版)についてお尋ねします。
web上での情報を集めていて、これから導入するか検討中です。
(1) 更新処理の際に、全てのデータノードに更新をかけるという仕組みのようですが、
それだと、1台の時と比べて著しく遅延したりすることはないでしょうか？
(2) これは、冗長性を確保するための機構で、パフォーマンスを改善させるための機構としては有効ではないのでしょうか？
私の運営しているサイトが次第に人が増えて乗り換えが必要になってきたのですが、
冗長性と同様にパフォーマンスも改善したいと思っています。
165:NAME IS NULL
10/08/03 23:46:22
導入しない方が良いと思うな。ありゃ有料サポート必須。
166:NAME IS NULL
10/08/04 02:52:37 urkSox1R
ありがとうございます。
もし、宜しければ理由をお聞かせ頂けると助かります。
ドキュメント不足で、エラーの解決に時間が掛かる。
構成が複雑で、独学では時間が掛かる。
有償オプションが付かないと実質的に運用に耐えられない。
などですか？
167:NAME IS NULL
10/08/04 16:50:14
それが調べられれないレベルだからだと思うが。。