それがなさそうなんだよねえ…。コード中1個所しかないし。
引き続き調べ中ですが、再現が難しい感じです。

データベースサーバは1台だよな

トランザクションレベルはどうなってんすか？

実はInnoDBじゃない
分離モードがREAD UNCOMITTED
FOR UPDATEついてないSQLで取得したデータ見てる

横やり失礼。
先発のトランザクションが SELECT ~ FOR UPDATE している間、
後発のトランザクションの読み込みを待たせたい場合は、
後発のクエリに「LOCK IN SHARE MODE」をつければOKって認識であってますか？

>>356
SQL文のログは取って調べたのかな?
アプリ側のコードとにらめっこしていてもしょうがないよ。

[mysqld]
log=ログファイル

MySQLユーザ会 MariaDB分科会だってさ
http://www.mysql.gr.jp/mysqlml/mysql/msg/16045

MySQLユーザ会って何もしない利権狙いの親父集団だろ
MariaDBの利権にも唾つけようと必死だな

tutuiって2009年にも利権確保に動いて止めたけど
http://tutui.net/
また盛り上がってきたら動くようだ

>>359
お、まさにそれをやりたいと思ってた。
できないんでしょうか。

http://dev.mysql.com/doc/refman/5.1/ja/innodb-parameters.html#optvar_innodb_lock_wait_timeout
http://blog.kimuradb.com/?eid=877250
> これまではグローバルで全体の指定を変えなければならなかった処理がセッションで、その接続だけ変更できるようになり、かなり敷居が下がりしました。

http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_lock_wait_timeout
> innodb_lock_wait_timeout applies to InnoDB row locks only. A MySQL table lock does not happen inside InnoDB and this timeout does not apply to waits for table locks.
テーブルロックだと、この機能効かないってよ

>>364
そのLinuxのプログラムでデータを取り扱うのならlocalhostでいいんじゃね。

>>364
それMySQLの話ちゃうやろと思いつつ、 hostsとかその手のファイル、DNS次第。

MySQLチームで募集中のプリセールスエンジニアは技術が重視されるので営業関連の経験は無くてもかまいません。ご興味のある方はDM下さい。 #mysql_jp

We Are Hiring!! 業務急拡大中につきMySQLチームでは日本でプリセールスエンジニアを募集しています。
ttps
t.co / xUXSf2pO3C

お前らの出番だぞw

転職めんどい

業務拡大じゃなくて
人が逃げたから集めるようにみえて仕方がない

Oracleの奴隷（ﾌﾟｹﾞﾗ

あるテーブルの主キーになってるserial型columnを他のテーブルで外部キーに指定しようとしてもできません。助けてください。

そんなはずがない

「他のテーブル」でインデックスも何も張ってないとかいうオチでは？

たぶん>>373これでした。ありがとうございましたm(_ _ )m

たぶん　ってw

おいおい大丈夫かよ・・・本職じゃないよな

5.6で高スペックサーバでの性能が飛躍的に向上したな
PostgreSQL抜き返したかな？

innodbにphpmyadminで33000件のデータをインポートしたのですが、なせか表示は31000件です。移動ボタンで最後のページまで飛ぶと33000件目を含むデータが表示されます。これは仕様なのでしょうか？それともどこかを修正すれば表示を改善出来ますか？

>>378
今DBに登録されてるデータをinto outfile してインポートしたデータと比べてみてはどうでしょう。

dbに 「33000件のデータをインポートし」てselect count(*)で33000件って出たらmysql側には問題なし
php側の方がおかしいんでしょ

phpがおかしい

>>378
phpMyAdmin で表示されるレコード数は、INFORMATION_SCHEMA というメタデータから引っ張ってきてるのですが、
InnoDB では概算値となるため、実際のレコード数と phpMyAdmin 上で表示させる値に誤差が生じます。
正確なレコード数を取得するには SELECT COUNT(1) FROM **** クエリを発行してください。

>>378 です。
皆さんありごとうこざいます。
innodbの仕様だったんですね。
安心しました。

はじめまして、相談です。

現在140万行あるテーブルに対して、以下のようなSQLを発行しています。
SELECT word , x,y, last FROM table_test where first != 1 and prev1 = '予測' and prev2 = 'は' and prev3 = 'に' ORDER BY RAND() LIMIT 1
こちらがテーブルです。
（現時点で厳しい物があるため、わざと使用していないカラムがいくつかあります）

SQL一回の結果が返ってくるまでに1.8秒ほど、大体10～20処理するので、1分前後かかっています。またこの先テーブルはますます大きくなります。
インデックスを貼って見ましたが、あまり早くなりません。これぐらいが普通なのでしょうか。
また、他に少しでも早くする方法はありますか？

このテーブルの用途は、趣味で作っている人工無能です。

>>384
インデックスは、first, prev1, prev2, prev3 の複合インデックス張ってる？

いまの主キー、インデックスも教えてくれないとわからん。
あと１万行くらいのダンプデータがあると検証ができてなおよし。

>>384です。環境を忘れていました。
xamppです。
Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
Client API version mysqlnd 5.0.10 - 20111026
です。

>>385
ありがとうございます。
1万行のダンプデータというのはこれでいいでしょうか
http://www.dotup.org/uploda/www.dotup.org4869465.sql

複合INDEXを初めて聞いたので検索、実行してみました
恐らくindex自体は作成されていると思うのですが、うまく使えない状態です

WHERE条件で大量のデータが返るのならORDER BY RAND()ではなく
対象件数を取得、その範囲の乱数を生成、LIMIT <乱数値>, 1とした方が早いかも。
EXPLAINでインデックスが使用されているか調べることが先だけど。

>>384
可能であればdescの結果か、show create table の結果を貼ってください。

>>386
388です。すいません、更新してませんでした。
ちょっとあっぷして頂いたデータでやってみます。

mysql> desc cc_ai_c;
+-----------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+-------------+------+-----+---------+-------+
| id | int(11) | NO | | 0 | |
| word | varchar(10) | NO | | NULL | |
| hinsi | varchar(10) | NO | | NULL | |
| first | int(11) | NO | | NULL | |
| last | int(11) | NO | | NULL | |
| noudo | double | NO | | NULL | |
| x | int(11) | NO | | NULL | |
| y | int(11) | NO | | NULL | |
| z | int(11) | NO | | NULL | |
| next | varchar(10) | NO | | NULL | |
| prev1 | varchar(10) | NO | | NULL | |
| prev2 | varchar(10) | NO | | NULL | |
| prev3 | varchar(10) | NO | | NULL | |
| hinsisaibunrui1 | varchar(10) | NO | | NULL | |
| hinsisaibunrui2 | varchar(10) | NO | | NULL | |
| hinsisaibunrui3 | varchar(10) | NO | | NULL | |
| katuyoukei | varchar(10) | NO | | NULL | |
| katuyougata | varchar(10) | NO | | NULL | |
| genkei | varchar(10) | NO | | NULL | |
| yomi | varchar(10) | NO | | NULL | |
| hatuon | varchar(10) | NO | | NULL | |
+-----------------+-------------+------+-----+---------+-------+
21 rows in set (0.01 sec)

どう見てもインデックスがないんですが。

>>390
すいません、すいません…
indexってmysqlで「構造」のカラムにチェックして、インデックスをクリックすれば作れると思っていました

そしてもうデータベースにもアクセスできずにどうしていいかわからないです…orz
Fatal error: Maximum execution time of 30 seconds exceeded in C:\xampp\phpMyAdmin\libraries\session.inc.php on line 96

ちょっと勉強してきます。。。

なるほど、確かにインデックスを設定すれば1５倍はやくなりそう

>>391
388です。
1万件のデータで例にあったselectしてみたけど、0.07秒（初回）でした。
CPUはAMDのE450というatom以下のCPUです。

で、keyがよくわかんないから
alter table cc_ai_c add key (first);
alter table cc_ai_c add key (prev1);
alter table cc_ai_c add key (prev2);
alter table cc_ai_c add key (prev3);
して同じselectしたら0.00秒でした。

ちなみにクエリキャッシュは使ってないので、keyを設定するだけでも改善すると思います。

うおー！ありがとうございます！！凄まじく早くなりました。
しばらくは問題なさそうです

複合インデックス、今後も大事にします、ありがとうございました！

「同時に１つのインデックスしか使えない」って仕様に引っかかりやすいよね。
複合インデックスは頭からしか使えないからカラムの順序に注意。

あとインデックスには指定したカラムに加え、主キーが入るってことも知っておくと役立つ。

64bit版のRHEL6.4にバンドルされてる5.1.66で
got signal 11
のエラーがでてmysqlが再起動します。

mysqlのバグで5.1.59以降では治ってるって書いてある
サイトがあったんだけど、再発したんでしょうか？

回避する方法ってなんかあります？

ちょっとヒントがほしいです
Using Index が表示されるのに、 Using temporary; Using filesort が出てしまうのは、設定ファイルがいけないのだろうか？

EXPLAIN SELECT article_date,count(id)
FROM `log`
WHERE user = 4 and FIND_IN_SET(“aaa”,`category`) and date between ‘2013-01-01’ and ‘2013-12-31’ group by date

複合は(user、category、date)に貼っていて、ちゃんとに使われている。

>>397
FIND_IN_SETのカラムにインデックスを張っても効率化されないと思う。
関係者にごめんなさいして第一正規化するか、
とりあえず妥協して複合インデックスを(user, date)に張ってみる。

それからSELECT article_dateなのにGROUP BY dateとなっているが、
転記ミスでなければこれはGROUP BYのよくない使い方。
SET sql_mode = ONLY_FULL_GROUP_BY;
で動くSQLに直してからチューニングを考えたほうがよいかも。

>>397
別になんの不思議もないと思いますが？
インデックスを使ってレコードを絞り込めるが、
それの集計やソートにテンポラリテーブルやクイックソートが必要ってことかと。

urlを保存する時って
1つのカラムに「http」削って
://～
って保存するのと、「0=http://、1=https://、2=http://www」とかって定義して2つのカラムに
1(int)　2
0　　　yahoo.co.jp
って保存するのでは後者の方がいいよね？みんなの保存方法を聞きたいです。