ありがとうございます。
向かうべき方向が分かりました。
これから勉強します。

情報不足でなんとも言えないけど、もしストレージエンジンが InnoDB だったら
設定によっては１つのトランザクション内で実行することで早くなる。

START TRANSACTION;
UPDATE テーブル SET a = a + 1 WHERE key = 1;
UPDATE テーブル SET a = a + 1 WHERE key = 2;
UPDATE テーブル SET a = a + 1 WHERE key = 3;
・・・
COMMIT;

> 最適化方法の選択に影響を及ぼすキーの、カーディナリティなどのテーブル統計を更新するために、ANALYZE TABLE を定期的に実行する必要があります。
postgresqlぐらいしか使ったことないけど、MySQLのマニュアルにこう書いてた。やってる？

どうやっても同じようにならないんだけど、
こっちで再現できるだけの情報全部出せる？

NFSではないです
EXPLAINやってみましが難しくてどこを改善したらいいのか良く分かりませんでした

知り合いにちょっと聞いてみたのですが
UPDATE1文だけでも(クエリの実行時間 0.0474 秒)というのは別にそれほど遅くない
ただ100回投げて4秒は遅いというかやり方を変えた方が良いと言われました

自分は↓のようなストアドプロシージャを登録して
　CREATE PROCEDURE test( IN x1 INT, IN x2 INT, IN x3 INT ～～ )
　BEGIN
　UPDATE テーブル SET a = a + 1 WHERE key = x1
　UPDATE テーブル SET b = b + 1 WHERE key = x2
　UPDATE テーブル SET a = a + 1 WHERE key = x3
　～～
　×100行

100回連続でUPDATE文を実行していたのですが
>>863さんは別の方法で0.036sという時間なのでしょうか

何度もすいません

↓が自分がテスト用に作って実際に↑の文を試してるDBとテーブルです
MySQL: 5.5.15
プロトコルバージョン: 10
サーバの文字セット: UTF-8 Unicode (utf8)
Apache/2.2.21 (Win32) PHP/5.3.5

実行はphpMyAdmin: 4.0.1から

テーブル構成
key(int11) AUTO_INCREMENT
a(int11)
b(int11)
c(int11)
d(int11)

インデックス
key（PRIMARY BTREE）

10万行程でa～dは1～20のランダムな値

>>866
そんなシンプルなUPDATE分のEXPLAIN結果が、どう改善していいのかわからないほど複雑なことになってるなら、
何か致命的な問題を抱えているか、何か重要な情報を隠されてるかのどっちかだな。

あとANALYZEの件はどうなりましたか…？

>>866
phpMyAdminを使わずシェルから直接実行しました。

CREATE TABLE `t` (
`key` int(11) NOT NULL AUTO_INCREMENT,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
PRIMARY KEY (`key`)
) ENGINE=InnoDB;

mysql> select count(*) from t;
+----------+
| count(*) |
+----------+
| 1000000 |
+----------+

upd.sqlの内容
start transaction;
update t set a = a+1 where `key` = 100;
update t set b = b+1 where `key` = 102;
update t set a = a+1 where `key` = 103;
～(300行のupdate行)
update t set b = b+1 where `key` = 546;
update t set a = a+1 where `key` = 547;
update t set b = b+1 where `key` = 549;
commit;

[db]$time mysql db -uusername -ppassword < upd.sql

real 0m0.066s ←実行時間
user 0m0.006s
sys 0m0.009s

Server version: 5.5.32 MySQL Community Server (GPL)

>>869
ありがとうございます
出来ました
>>858さんの指摘でSTART TRANSACTIONを試してみたつもりでしたが出来てなかったようです
>>869さんのようにストアドプロシージャの中に書いたらキッチリ速くなりました
初歩的な事でお騒がせしてすみませんでした
>>868 ANALYZE TABLEというのを調べてみたのですMyISAM用のコマンドだと出てきたので
試していませんでした
でもありがとうございます

>>870
関係ないANALYZEの話出してごめんなさい。
解決してよかった

トランザクションの件は移動前のスレで最初に聞いたんだけどな
無視されたか

念のためいっとくけど、ストアドの中でトランザクションを開始したり終了したりするのは
基本的には駄目だからな。どんな文脈で呼ばれても大丈夫なようにしとくのが基本。

どういう理屈かわからんが、ストアドの外で開始してもうまくいかなかったって書いてるよ。

パージスレッドって何をするんでしょうか？

ドキュメント読むとパージはDELETEで消した行のインデックスとテーブルデータ領域から削除
するって書いてるように見えるんですが、
http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_purge

ネット検索するとパージスレッドはUPDOログのデータを消すみたいに書いてるものばかり引っかかってくるので、
詳しい人、教えてくれませんか。

まあ、不要なインデックスが残ったり、削除マークがついたデータが削除後も残るのも、実装詳細と言えなくもない

>>877
正直、SpiderはS氏に多額のお布施を払わないとお仕事レベルで使うのは困難。
MySQLそのものの広範なチューン無しでは肝心な所でパフォーマンスが出ない。

評論家気取った奴がちょろっと使うだけなら結構よく見えるんだけどな。

MySQL5.5

key　　　a　　　b　　　c
--------------------
1　　　　3　　　3　　　2
1　　　　4　　　1　　　1
1　　　　5　　　2　　　2
1　　　　2　　　3　　　2
2　　　　1　　　0　　　5
2　　　　5　　　0　　　2
2　　　　2　　　3　　　2
2　　　　1　　　0　　　0
3　　　　1　　　2　　　2
3　　　　2　　　3　　　0


2000万行程あるテーブルで上のような構成なのですが
このテーブルに↓のようなSELECT文を投げる大体20秒くらいの時間が掛かってしまいます

SELECT abs(a + b - c) AS abs_hoge, key FROM table WHERE key = 2 ORDER BY abs_hoge ASC LIMIT 1;

インデックスはkeyにのみ張っています
一つのkeyの値につき2000レコード程あるので
まず2000行フェッチされた後、a+b-cの絶対値でfile_sortされてるみたいなのですが
2000行程度のソートに非常に長い時間が掛かってしまうのは回避のしようがないのでしょうか

どうにかして処理を速くしたいのですが
よろしくお願いします

というか、テーブルやインデックスの構成もわからん

テーブル構成は
1 id　：　int(11)
2 key　：　smallint(6)
3 a　：　smallint(6)
4 b　：　smallint(6)
5 c　：　smallint(6)
...
66 cp　：　smallint(6)
67 cq　：　smallint(6)

インデックスは
idカラムに「PRIMARY」 PRIMARY BTREE
keyカラムに「key_index」 INDEX BTREE

EXPLAIN結果は
id　：　1
table　：　 SIMPLE
table　：　table
type　：　ref
possible_keys　：　key_index
key　：　key_index
key_len　：　2
ref　：　const
rows　：　2199
Extra　：　Using where Using filesort

レコード数は19,520,590
keyカラムは一つの値につき2200レコードあります

先にソートされてるっぽいなあ

SELECT abs(a + b - c) AS abs_hoge, key FROM (select * from table WHERE key = 2) as T ORDER BY abs_hoge ASC LIMIT 1;

だとどうですか

>>890
同じテーブル作って再現したけど、0.003秒くらいで実行できちゃうなぁ。
ゴミカラムつけてテーブルを2GBくらいに肥やしてみたけど変わらず。
数千行で20秒というのはいくらなんでも遅い気がするので、サーバ環境を見直した方がいいかも。

ところで、最小値が知りたいのなら
SELECT MIN(ABS(a+b-c)) AS abs_hoge, `key` FROM table WHERE `key`=2;
とすれば少なくともソートの処理時間は省けると思う。と素人考え。

あと頻繁に使う値なら計算済みのカラムなりテーブルを別に用意した方がいいと思う。

ない。
自作しろ。

そうですか、ありがとうございます。

>>895
mysql syncでググるといくつかヒットするけど、この中で試したある？