元スレMySQL 総合 Part24
mysql覧 / PC版 / みんなの評価 :
前へ
353 :
トランザクションレベルはどうなってんすか？
355 = :
横やり失礼。
先発のトランザクションが SELECT ~ FOR UPDATE している間、
後発のトランザクションの読み込みを待たせたい場合は、
後発のクエリに「LOCK IN SHARE MODE」をつければOKって認識であってますか？
358 = :
MySQLユーザ会 MariaDB分科会だってさ
http://www.mysql.gr.jp/mysqlml/mysql/msg/16045
MySQLユーザ会って何もしない利権狙いの親父集団だろ
MariaDBの利権にも唾つけようと必死だな
tutuiって2009年にも利権確保に動いて止めたけど
http://tutui.net/
また盛り上がってきたら動くようだ
360 = :
>>359
お、まさにそれをやりたいと思ってた。
できないんでしょうか。
http://dev.mysql.com/doc/refman/5.1/ja/innodb-parameters.html#optvar_innodb_lock_wait_timeout
http://blog.kimuradb.com/?eid=877250
> これまではグローバルで全体の指定を変えなければならなかった処理がセッションで、その接続だけ変更できるようになり、かなり敷居が下がりしました。
361 = :
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.
テーブルロックだと、この機能効かないってよ
367 = :
MySQLチームで募集中のプリセールスエンジニアは技術が重視されるので営業関連の経験は無くてもかまいません。ご興味のある方はDM下さい。 #mysql_jp
We Are Hiring!! 業務急拡大中につきMySQLチームでは日本でプリセールスエンジニアを募集しています。
ttps
t.co / xUXSf2pO3C
お前らの出番だぞw
368 = :
転職めんどい
369 = :
業務拡大じゃなくて
人が逃げたから集めるようにみえて仕方がない
371 = :
あるテーブルの主キーになってるserial型columnを他のテーブルで外部キーに指定しようとしてもできません。助けてください。
372 = :
そんなはずがない
373 = :
「他のテーブル」でインデックスも何も張ってないとかいうオチでは？
374 = :
たぶん>>373これでした。ありがとうございましたm(_ _ )m
375 = :
たぶん ってw
376 = :
おいおい大丈夫かよ・・・本職じゃないよな
378 = :
innodbにphpmyadminで33000件のデータをインポートしたのですが、なせか表示は31000件です。移動ボタンで最後のページまで飛ぶと33000件目を含むデータが表示されます。これは仕様なのでしょうか？それともどこかを修正すれば表示を改善出来ますか？
381 = :
phpがおかしい
382 = :
>>378
phpMyAdmin で表示されるレコード数は、INFORMATION_SCHEMA というメタデータから引っ張ってきてるのですが、
InnoDB では概算値となるため、実際のレコード数と phpMyAdmin 上で表示させる値に誤差が生じます。
正確なレコード数を取得するには SELECT COUNT(1) FROM **** クエリを発行してください。
383 = :
>>378 です。
皆さんありごとうこざいます。
innodbの仕様だったんですね。
安心しました。
384 = :
はじめまして、相談です。
現在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分前後かかっています。またこの先テーブルはますます大きくなります。
インデックスを貼って見ましたが、あまり早くなりません。これぐらいが普通なのでしょうか。
また、他に少しでも早くする方法はありますか？
このテーブルの用途は、趣味で作っている人工無能です。
385 = :
>>384
インデックスは、first, prev1, prev2, prev3 の複合インデックス張ってる？
いまの主キー、インデックスも教えてくれないとわからん。
あと１万行くらいのダンプデータがあると検証ができてなおよし。
386 :
>>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自体は作成されていると思うのですが、うまく使えない状態です
387 = :
WHERE条件で大量のデータが返るのならORDER BY RAND()ではなく
対象件数を取得、その範囲の乱数を生成、LIMIT <乱数値>, 1とした方が早いかも。
EXPLAINでインデックスが使用されているか調べることが先だけど。
388 = :
>>384
可能であればdescの結果か、show create table の結果を貼ってください。
389 = :
>>386
388です。すいません、更新してませんでした。
ちょっとあっぷして頂いたデータでやってみます。
392 = :
なるほど、確かにインデックスを設定すれば1５倍はやくなりそう
394 = 386 :
うおー！ありがとうございます！！凄まじく早くなりました。
しばらくは問題なさそうです 複合インデックス、今後も大事にします、ありがとうございました！
395 = :
「同時に１つのインデックスしか使えない」って仕様に引っかかりやすいよね。
複合インデックスは頭からしか使えないからカラムの順序に注意。
あとインデックスには指定したカラムに加え、主キーが入るってことも知っておくと役立つ。
396 = :
64bit版のRHEL6.4にバンドルされてる5.1.66で
got signal 11
のエラーがでてmysqlが再起動します。
mysqlのバグで5.1.59以降では治ってるって書いてある
サイトがあったんだけど、再発したんでしょうか？
回避する方法ってなんかあります？
397 = :
ちょっとヒントがほしいです
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)に貼っていて、ちゃんとに使われている。
398 = :
>>397
FIND_IN_SETのカラムにインデックスを張っても効率化されないと思う。
関係者にごめんなさいして第一正規化するか、
とりあえず妥協して複合インデックスを(user, date)に張ってみる。
それからSELECT article_dateなのにGROUP BY dateとなっているが、
転記ミスでなければこれはGROUP BYのよくない使い方。
SET sql_mode = ONLY_FULL_GROUP_BY;
で動くSQLに直してからチューニングを考えたほうがよいかも。
399 = :
>>397
別になんの不思議もないと思いますが？
インデックスを使ってレコードを絞り込めるが、
それの集計やソートにテンポラリテーブルやクイックソートが必要ってことかと。
400 = :
urlを保存する時って
1つのカラムに「http」削って
://～
って保存するのと、「0=http://、1=https://、2=http://www」とかって定義して2つのカラムに
1(int) 2
0 yahoo.co.jp
って保存するのでは後者の方がいいよね？みんなの保存方法を聞きたいです。
みんなの評価 :
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part20 (995) - [94%] - 2011/10/17 4:48
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part15 (1001) - [89%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について