私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part17

みんなの評価 : ○
レスフィルター : (試験中)
>>403
できました、ありがとうございました。
できました、ありがとうございました。
CGIとかPHPでMYSQLに接続できるのは分かったのですが、
JAVAってMYSQLに接続するのに向いてますか?
もしJAVAでMYSQLの操作ができるなら、何行ぐらいのソースが必要ですか?
JAVAってMYSQLに接続するのに向いてますか?
もしJAVAでMYSQLの操作ができるなら、何行ぐらいのソースが必要ですか?
すみません。質問します。
あるプログラムがODBCを通してSQLに書き込む際、クエリがMSSQL用でうまくいかない事が解りました
しかしプログラムは変えられない為、どうにか対処する方法を探してみたのですが全く見つからず…
そこで、MySQLでは実行できないクエリが来たら「変換する」か「無視させる」ような事はできないのでしょうか?
よろしくお願いいたします。
あるプログラムがODBCを通してSQLに書き込む際、クエリがMSSQL用でうまくいかない事が解りました
しかしプログラムは変えられない為、どうにか対処する方法を探してみたのですが全く見つからず…
そこで、MySQLでは実行できないクエリが来たら「変換する」か「無視させる」ような事はできないのでしょうか?
よろしくお願いいたします。
・どうにかしてプログラムを変える
・MySQL本体を改造する
好きな方を選べばいいよ
・MySQL本体を改造する
好きな方を選べばいいよ
select between '2010-01-05' and '2010-01-10'
みたいな感じで
2010-01-05
2010-01-06
2010-01-07
2010-01-08
2010-01-09
2010-01-10
みたいに取るようなSQLは無理でしょうか?
みたいな感じで
2010-01-05
2010-01-06
2010-01-07
2010-01-08
2010-01-09
2010-01-10
みたいに取るようなSQLは無理でしょうか?
>>410
?? それで取れますが・・・。
?? それで取れますが・・・。
>>399
カラム名にカンマ区切りで名前を列挙するんじゃなかったかしら
カラム名にカンマ区切りで名前を列挙するんじゃなかったかしら
php + MySQLで作っていたポータルサイトで携帯電話の動画を扱うことになりました。
各動画は携帯の動画なのでサイズ的には小さいです。
MySQLに動画を突っ込むことは可能ですか?
あるいはDB以外の場所に保存しておくべきなのでしょうか?
動画を扱うサイトを構築した経験のある方がいましたらアドバイスを頂けないでしょうか。
各動画は携帯の動画なのでサイズ的には小さいです。
MySQLに動画を突っ込むことは可能ですか?
あるいはDB以外の場所に保存しておくべきなのでしょうか?
動画を扱うサイトを構築した経験のある方がいましたらアドバイスを頂けないでしょうか。
mysql 5.1.42 WinXP
テーブルを出力しようと思い、
select *
into outfile
'c:\testdata.csv'
fields terminated by ','
lines terminated by '\r\n'
from ****;
と入力すると
1 - Can't create/write to file 'c: estdata.csv' (Errcode: 22)
とエラーになります。
多分 c:\tの \t をタブコードとかなんかと勘違いしているんじゃないかと思うのですけど、
ファイル名を変える以外の解決策ってありますか?
(ファイル名を変えると出力はされるんですが)
テーブルを出力しようと思い、
select *
into outfile
'c:\testdata.csv'
fields terminated by ','
lines terminated by '\r\n'
from ****;
と入力すると
1 - Can't create/write to file 'c: estdata.csv' (Errcode: 22)
とエラーになります。
多分 c:\tの \t をタブコードとかなんかと勘違いしているんじゃないかと思うのですけど、
ファイル名を変える以外の解決策ってありますか?
(ファイル名を変えると出力はされるんですが)
>>423
出来ました!感謝!です
出来ました!感謝!です
auto_incrementのカラムに入る最初の値をテーブル作成時に指定できるけど、それはMyISAMのみ
engine=MiISAM,auto_increment=100; みたいな形で
engine=MiISAM,auto_increment=100; みたいな形で
あー、解決しました
>>431さんのアドバイスどんぴしゃでした。
処理2の直後に$this->_db->commit();しなきゃいけなかったんですね。
トランザクションの知識不足で、処理2の実行がされてるのでトランザクション成功してるのかと思ってた
成功してたんじゃなくて、2用のテーブルがトランザクション非対応で不具合で実行されちゃってたんですね。。
ほんと助かりました。感謝します。ありがとうございます。
>>431さんのアドバイスどんぴしゃでした。
処理2の直後に$this->_db->commit();しなきゃいけなかったんですね。
トランザクションの知識不足で、処理2の実行がされてるのでトランザクション成功してるのかと思ってた
成功してたんじゃなくて、2用のテーブルがトランザクション非対応で不具合で実行されちゃってたんですね。。
ほんと助かりました。感謝します。ありがとうございます。
インデックスについて質問です。
テーブルの特定のカラム上にない値をWHEREで指定してSELECTする場合なのですが、
EXPLAIN文を見ると、キーを使わずに検索しています。
例えば
SELECT hash FROM users WHERE hash = '39fdb309ffb5e207'
というSELECT文で、この値がテーブルのカラム上に存在する時は、
EXPLAINのpossible_keys、key ともに、hashカラムのインデックスの名前が出ます。
ところが、実際は存在しない適当な値(例えば'hoge')を検索しても、possible_keys、key は NULL でした。
存在する値で無い限り、インデックスは使用されないのでしょうか?
また、テーブルの規模が巨大化した場合、これは重い処理となってしまうのでしょうか。
どなたかよろしくお願いします。
テーブルの特定のカラム上にない値をWHEREで指定してSELECTする場合なのですが、
EXPLAIN文を見ると、キーを使わずに検索しています。
例えば
SELECT hash FROM users WHERE hash = '39fdb309ffb5e207'
というSELECT文で、この値がテーブルのカラム上に存在する時は、
EXPLAINのpossible_keys、key ともに、hashカラムのインデックスの名前が出ます。
ところが、実際は存在しない適当な値(例えば'hoge')を検索しても、possible_keys、key は NULL でした。
存在する値で無い限り、インデックスは使用されないのでしょうか?
また、テーブルの規模が巨大化した場合、これは重い処理となってしまうのでしょうか。
どなたかよろしくお願いします。
my.cnfについて質問なのですが
データベースの文字コードがおかしい(utf8にしたいけどlatin1)うえ、
my.cnfが見当たらなかった(短縮コードなども考慮して探したけどなかった)
ので自分でテキストエディタを使ってあたらしく作ったのですが、
内容を
[mysqld]
default-character-set=utf8
skip-character-set-client-handshake
(my.cnfの場所はxampp/mysql/bin の中)
にしてmysqlを再起動、新しいテーブルを作ってみても
使用している文字コードがutf8に統一されません。
たぶんmy.cnfの設定が間違っていると思うのですが、
どのように修正したらいでしょうか。
もしご存じでしたら教えてください。お願いします。
データベースの文字コードがおかしい(utf8にしたいけどlatin1)うえ、
my.cnfが見当たらなかった(短縮コードなども考慮して探したけどなかった)
ので自分でテキストエディタを使ってあたらしく作ったのですが、
内容を
[mysqld]
default-character-set=utf8
skip-character-set-client-handshake
(my.cnfの場所はxampp/mysql/bin の中)
にしてmysqlを再起動、新しいテーブルを作ってみても
使用している文字コードがutf8に統一されません。
たぶんmy.cnfの設定が間違っていると思うのですが、
どのように修正したらいでしょうか。
もしご存じでしたら教えてください。お願いします。
2つのテーブルがあります。
双方のテーブルのname, creator, sizeに同時にLIKEしたいのですがどうすればよいのでしょうか?
双方のテーブルに同一のデータは入っていないため、join on conditionできません。
主キーのhashとpathに関連性はありません。
old
hash | name | creator | size
new
path | name | creator | size
双方のテーブルのname, creator, sizeに同時にLIKEしたいのですがどうすればよいのでしょうか?
双方のテーブルに同一のデータは入っていないため、join on conditionできません。
主キーのhashとpathに関連性はありません。
old
hash | name | creator | size
new
path | name | creator | size
>>443
datetimeじゃなく、timestampにすりゃいいじゃん。
俺なんか、あれに現在日時が書き込まれるのはINSERT時だけと思い込んでて、
UPDATEの日時に書き換わっちゃって泣いた経験があるんだぞ。
ああどうせ、マニュアルもロクに読まなかったアホだよ。
datetimeじゃなく、timestampにすりゃいいじゃん。
俺なんか、あれに現在日時が書き込まれるのはINSERT時だけと思い込んでて、
UPDATEの日時に書き換わっちゃって泣いた経験があるんだぞ。
ああどうせ、マニュアルもロクに読まなかったアホだよ。
>>445
おおー、あっさり解決した。
ありがとうございます。助かりました。
後一つだけ聞きたいんですが、updateの時にlimitをかけるのっておかしいことなんでしょうか?
update 略 where hoge=1 limit 1 みたいな。
今まで意識せずにそうして来たんですが、意味ないような、でもしないとパフォーマンス悪くなりそうな。。
どうも気になっています。
おおー、あっさり解決した。
ありがとうございます。助かりました。
後一つだけ聞きたいんですが、updateの時にlimitをかけるのっておかしいことなんでしょうか?
update 略 where hoge=1 limit 1 みたいな。
今まで意識せずにそうして来たんですが、意味ないような、でもしないとパフォーマンス悪くなりそうな。。
どうも気になっています。
>>446
WHEREにマッチしたレコード全部を更新したいなら、LIMIT付けるのは無意味だと思うよ。
マッチしたレコードのうち一部を更新したいなら、LIMITを付けることもあるだろうけど、
その場合ORDER BYも併せて使わないと、どのレコードが実際に更新されるか分からない
んじゃないかな。
まあ、WHEREだけできっちり限定できるようにする/出来る場合ばかりだったけど、俺の場合。
WHEREにマッチしたレコード全部を更新したいなら、LIMIT付けるのは無意味だと思うよ。
マッチしたレコードのうち一部を更新したいなら、LIMITを付けることもあるだろうけど、
その場合ORDER BYも併せて使わないと、どのレコードが実際に更新されるか分からない
んじゃないかな。
まあ、WHEREだけできっちり限定できるようにする/出来る場合ばかりだったけど、俺の場合。



類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について