私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part22
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>449
取ってない
取ってない
>>449
そういうログは取れなくもないが、ログ有効にするとクエリーの詳細ログまで大量に取られるはず
そういうログは取れなくもないが、ログ有効にするとクエリーの詳細ログまで大量に取られるはず
語気鰤ども、おはようさん。
今日は疲れたから研究室にはいかへんことにした。どうせ受け持ちの授業もないしな。せやから昼間っからとことんお前ら抗戦卒の誤記どもをからかったるからな(^ー゜)
よろこべや
今日は疲れたから研究室にはいかへんことにした。どうせ受け持ちの授業もないしな。せやから昼間っからとことんお前ら抗戦卒の誤記どもをからかったるからな(^ー゜)
よろこべや
a,b,cというフィールドがあるテーブルでbでまとめて、そのときのマッチしたbの値ごとのフィールドをカウントして
カウントが任意の値と等しいときにcを返すSQLを以下のように書いてみたのですが、エラーが出てしまいます。
SELECT IF COUNT(id) = {任意の値} THEN c ELSE NULL END FROM tbl WEHERE a = 1 GROUP BY b;
SELECTの返すフィールドを書くところにIFを書いてはいけないのでしょうか？
また、もっといいやり方があったら教えていただきたいです。
カウントが任意の値と等しいときにcを返すSQLを以下のように書いてみたのですが、エラーが出てしまいます。
SELECT IF COUNT(id) = {任意の値} THEN c ELSE NULL END FROM tbl WEHERE a = 1 GROUP BY b;
SELECTの返すフィールドを書くところにIFを書いてはいけないのでしょうか？
また、もっといいやり方があったら教えていただきたいです。
>>455
bでまとめたグループごとに、cが一つに定まるとは限らないので
当初目的としていったい何を出力したいのか分からない。
とりあえずcをいったん忘れれば、HAVINGを使うのが正しい。
SELECT ... FROM tbl WHERE a = 1 GROUP BY b HAVING COUNT(*) = {任意の値};
これをベースにして、SQL_MODE = ONLY_FULL_GROUP_BYできちんと動く形で
カスタマイズすればいいよ
bでまとめたグループごとに、cが一つに定まるとは限らないので
当初目的としていったい何を出力したいのか分からない。
とりあえずcをいったん忘れれば、HAVINGを使うのが正しい。
SELECT ... FROM tbl WHERE a = 1 GROUP BY b HAVING COUNT(*) = {任意の値};
これをベースにして、SQL_MODE = ONLY_FULL_GROUP_BYできちんと動く形で
カスタマイズすればいいよ
>>459
観察してるつもりの君が一番目立っていて、みんなから観察されてる状況になるのっておかしくない？
観察してるつもりの君が一番目立っていて、みんなから観察されてる状況になるのっておかしくない？
普通に妄想だし病気だよ
過去のトラウマに縛り付けられてるんだろうね
哀れな人だよ
過去のトラウマに縛り付けられてるんだろうね
哀れな人だよ
>>463
なんで、そないなこといえますのん？
なんで、そないなこといえますのん？
>>464
根拠が何なのか全く伝わってこない
根拠が何なのか全く伝わってこない
>>468
あんたの理論で言うと、何スレもわしが＂粘着"しとるのを知っとって、しつこく付け回すお前もまともやないっちゅうことになりますわな？
ワシは研究や業務の傍ら、語気鰤公選卒をかたかってやっとるだけや。
あんたの理論で言うと、何スレもわしが＂粘着"しとるのを知っとって、しつこく付け回すお前もまともやないっちゅうことになりますわな？
ワシは研究や業務の傍ら、語気鰤公選卒をかたかってやっとるだけや。
>>467
とりあえず根拠出せそうにない463のことなんかどうでもよくて、
それより前に461を書いたお前が根拠を出せるかはっきりすりゃいい。
お前が根拠を出してしまえば自動的に463の間違いは示せるし、
お前が根拠を出せずに妄想だと判明すればそれ自身が463の正しさを示す根拠になるのだから。
とりあえず根拠出せそうにない463のことなんかどうでもよくて、
それより前に461を書いたお前が根拠を出せるかはっきりすりゃいい。
お前が根拠を出してしまえば自動的に463の間違いは示せるし、
お前が根拠を出せずに妄想だと判明すればそれ自身が463の正しさを示す根拠になるのだから。
>>469
このスレの最初を読み込んだ時にちらっと見ただけでも香ばしいのは分かる物だよ
このスレの最初を読み込んだ時にちらっと見ただけでも香ばしいのは分かる物だよ
mysqlの5.1.50なんですが、
selectするカラムが増えるだけで、
速度が全然変わってくるんですが、
何か設定が悪いんでしょうか。。
selectするカラムが増えるだけで、
速度が全然変わってくるんですが、
何か設定が悪いんでしょうか。。
扱うデータが増えるんだからある程度は当たり前。
でもEXPLAINしたら違いが分かるかもね。
でもEXPLAINしたら違いが分かるかもね。
select結果を返すプロシージャはlibmysqlからは利用できないのでしょうか？
mysqlクライアントからは問題なく実行できるのですが
テストプログラムでlibmysql経由で実行すると
mysql_real_query() PROCEDURE t1 can't return a result set in the given context
てエラーがでます
mysqlクライアントからは問題なく実行できるのですが
テストプログラムでlibmysql経由で実行すると
mysql_real_query() PROCEDURE t1 can't return a result set in the given context
てエラーがでます
>>478
そりゃあんたの手順が間違ってるんだ
そりゃあんたの手順が間違ってるんだ
手順次第だけど、なんか失敗ぶっこいたときに
元に戻すのがすげー手間なので嫌いだわ。
とくに片肺運用中からの復帰が超ドキドキ・
元に戻すのがすげー手間なので嫌いだわ。
とくに片肺運用中からの復帰が超ドキドキ・
mysql-mmm使ってみてる
普通に死ぬ場合はサクサクとアクティブ変えてくれるよ
普通じゃない場合にまだ会った事無いから、if不安定時にどうなるか分からない
普通に死ぬ場合はサクサクとアクティブ変えてくれるよ
普通じゃない場合にまだ会った事無いから、if不安定時にどうなるか分からない
顕正新聞 平成24年2月5日号「原発全廃特集号」
原発は日本を滅ぼす、即時全廃せよ
人のDNAを破壊、国土を居住不能にする
代替は天然ガス・コンバインドサイクルで十分
惨禍もたらすを知って推進するは犯罪
http://d.hatena.ne.jp/kensho01/20120208/1328718592
485です。
SELECT tab1.*
from tab1
where tab1_col1 in
(select tab2_col1
from tab2
where tab2_col2 = '1'
and tab2_col3 = '1');
tab1とtab2のデータ量は約100万件です。
INDEXは（tab1_col1）と（tab2_col1,tab2_col2,tab2_col3）
にはってあります。
SQL Serverだと1秒未満、
MySQLだと30秒ぐらいです。
SELECT tab1.*
from tab1
where tab1_col1 in
(select tab2_col1
from tab2
where tab2_col2 = '1'
and tab2_col3 = '1');
tab1とtab2のデータ量は約100万件です。
INDEXは（tab1_col1）と（tab2_col1,tab2_col2,tab2_col3）
にはってあります。
SQL Serverだと1秒未満、
MySQLだと30秒ぐらいです。
>>488
相関なしIN句はMySQLの一番苦手なSQL。
まずこれを読んで、
http://nippondanji.blogspot.jp/2009/03/mysql_25.html
本当に本当にどうしても絶対にSQLを書き換えられないのなら
今回だけはMySQL使うのをあきらめてください。
相関なしIN句はMySQLの一番苦手なSQL。
まずこれを読んで、
http://nippondanji.blogspot.jp/2009/03/mysql_25.html
本当に本当にどうしても絶対にSQLを書き換えられないのなら
今回だけはMySQL使うのをあきらめてください。
あとMySQLの場合はあきらめなんだけど、MariaDB 5.3なら速いはず。
人柱になる覚悟があるなら試してみて。
http://en.oreilly.com/mysql2010/public/schedule/detail/13509
これのP26～30の仕組みが効く。
人柱になる覚悟があるなら試してみて。
http://en.oreilly.com/mysql2010/public/schedule/detail/13509
これのP26～30の仕組みが効く。
ゴキ光線ども、お前らみたいなクズはアカデミックな俺に逆らうこと自体ゆるされへんのやぞ
>>494
どんなindexがあるのか、まとめて書いてみろよ
どんなindexがあるのか、まとめて書いてみろよ
>>494
> 今回の質問には関係ないことは省略しました。
> でも必要なことも省略してしまいました。
必要か不要かの判断ができるだけの高いスキルがあると自覚してるなら、こんなところで質問しなくても解決できるだろう
> 今回の質問には関係ないことは省略しました。
> でも必要なことも省略してしまいました。
必要か不要かの判断ができるだけの高いスキルがあると自覚してるなら、こんなところで質問しなくても解決できるだろう
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
mysql スレッド一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- 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 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [89%] - 2008/11/23 10:17 ☆
- 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 ○
トップメニューへ / →のくす牧場書庫について