timestamp型のカラムの内容を元に、毎日一定の時刻にデータの削除をしたいんですが
このような事は可能でしょうか？
また、可能な場合はどのように設定すれば？


OSはFC6、mysqlは5.1.6です。

>>101
他のRDBMSみたいに
set (col2, col3) = (subquery)って書ければいいのに、
できないね。

こんな変態SQLでできるらしい。

mysql> update q101, (select empno, ename, job from emp where empno = 7788) v_emp set q101.col2 = v_emp.ename, q101.col3 = v_emp.job where q101.col1 = v_emp.empno;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from q101;
+------+-------+---------+
| col1 | col2 | col3 |
+------+-------+---------+
| 7788 | scott | analyst |
+------+-------+---------+
1 row in set (0.00 sec)

MySQL 5.1はバグが多そうなので、5.0を使用してみようと思ったのですが、
日本語マニュアルは5.0だけないようですね。
5.0は谷間世代で、5.0使ってる人って少ないんですかね？

phpmyadmin のスレってなかったっけ？

「EXPLAINで確認」って、どういう機能？

新機能を除けば、5.0より5.1の方が品質は良い
5.1を使いつつ新機能は当面使わないのが勝ち組

すみません、色々調査しましたがどうしてもうまく行かないので
質問させてください。

下記の様な掲示板データをテーブルに格納しております。
idは自動的に付与され、resはidの記事に対する返答が
あった場合、id(親記事)の番号は入ります。

この構成で、2008-12-18の記事だけ取得するが、
それに関連する返答も取得したい場合のクエリを
教えていただきたいと思います。

下記の構成だと、idの1とidの2が取得できれば良いのですが。。。

┌───┬──┬──────┬────────┐
│id 　　 │res 　 │ comment 　 │time 　　　 │
├───┼──┼──────┼────────┤
│1 　　　 │0 　　 │ あいう 　　　 │2008-12-18 00:0 │
├───┼──┼──────┼────────┤
│2 　　 │1 　　 │ かきく 　　　 │2008-12-19 00:10│
├───┼──┼──────┼────────┤
│3 　　 │0 　 │ さしす 　　　　 │2008-12-19 01:20│
├───┼──┼──────┼────────┤
│4　　　　│3 　 │ たちつ 　　　 │2008-12-19 09:30│
├───┼──┼──────┼────────┤
│5 　　 　 │3 　 │ なにぬ 　　 │2008-12-20 10:00 │
└───┴──┴──────┴────────┘

>>107
ふーん、montyは全く逆のこと言ってるね

>>108
select * from tbl_test where DATE(time) ='2008-12-18' or res in(select id from tbl_test where DATE(time)='2008-12-18');
これで出ることは出る

>>118

108です。

ありがとうございます。
とりあえず抜き出せたことだけでも良かったです。

本来ならばデータは大量にあるのでスレッドのように抽出出来れば
いいのですが、こちらはまた考えて見ます。
既にご存知であればお教えください。

失礼
108です

>>111は
>>110さんへの返答です。

日本語を入力して、
データーを取り出してみたら、

？？？？？

になってるんだけど、何が悪かったかな？

http://d.hatena.ne.jp/aoi_273/20071127/1196150017

自己解決した。
UTF-8って入れないと文字化けするみたい。

>>115
起動直後の一発目は速くなるかもしらんけど、
あとはOSのディスクキャッシュが効くだろうから
変わらん気がする。
期待すべきはデータを取り出すほうじゃないかな。

シフトJISにするとSQLインジェクションに対応できないという
記事を読んだのですが、UTF-8でデーターベースを設定していても
シフトJISの文字が入ってきた場合、強制的にシフトJISとして
流通してしまうのでしょうか？

http://blog.ohgaki.net/set_namesa_mcb_asc

SET NAMESは禁止

MySQLには文字エンコーディングを変更する「SET
NAMES」SQL文が用意されています。（PostgreSQL
も同様のSQL文、SET CLIENT_ENCODINGがありま
す）この機能はSQLコンソールからは使ってよい機能
ですが、アプリケーションからは使ってはならない機
能です。 SQLインジェクションに脆弱になる場合があ
ります。

>>117
文字化けしたデータとして流通するでしょ
知識の問題じゃなく単に分析力の問題じゃん、それ
UTF-8のところにSJIS無理やり流し込むとか文字化けして当然なんだから
気にせずサニタイズしたらいい
ある文章が文字化けしてるのか自然な文章なのかを判別するのは割りと凝った事が必要そう

つまりデーターベースで使われる文字コード自体を
utf-8としておけば、シフトJISの文字コードの文字が
入ってきても、普通にサニタイズすれば問題ないという
ことですね。

強制的にセキュリティを破られるのかと思った。

質問

準備された文＝Prepared Statement＝バインド変数＝プレースホルダー

であってる？

>準備された文＝Prepared Statement
これはいいだろうが、二つ目、三つ目の＝は変。

バインド変数は プレースホルダにバインドされる変数

MySQL 4.1以降での文字の扱い

MySQLはバージョン4.1以降で文字の扱いが大きく変わりました。

それまでのMySQLは、クライアント側で使っている文字(バイトの並び)
がそのままDBに格納され、取得するとそのまま返ってくるという非常
に単純な挙動でした。従って、クライアント側で使用している文字エ
ンコーディング(符号化方式)がDBで使用する文字エンコーディングと
異なる場合は、クライアント側でDBに合わせて変換を行う必要があり
ました。

しかし、MySQL 4.1以降ではサーバ側とクライアント側にそれぞれ文字
エンコーディングが指定できるようになり、ちゃんと設定すればサーバ
が透過的に変換してくれるので、クライアント側で事前に変換をする必
要が無くなったのです。

ここまでなら便利な機能が増えて良かった良かったとなるのですが、現
実はそうも行かないのでした。

MySQLはサーバもクライアントもデフォルトでlatin1という文字コード(?)を
使用します。latin1というのは名前の通りの文字コードで、漢字とかはか
らっきしダメです。MySQLサーバで何も指定せずにDBを作るとその中の
テーブルでは基本的にlatin1を使う事になりますので、日本向けのサー
ビスでMySQLを使用するなら、大抵はujis(EUC-JP),sjis(Shift_JIS),utf8(U
TF-8)のどれかを指定してDBを作ります。

DBの文字エンコーディングをUTF-8にして、DBサーバに対してクライアン
トとなるアプリケーションからUTF-8のINSERT SQLを発行した場合、問
題なく動きそうですが、MySQLのクライアントは何も設定していなければ
SQLの文字エンコーディングがlatin1だとサーバに通知するので、サーバ
ではlatin1からDBの文字エンコーディングであるUTF-8へ変換するルー
ルを送られてきたUTF-8に適用してしまい、大抵の場合文字化けしてグ
チャグチャになります。

4.1より前のバージョンではこういう変換は行われなかったため、その時
代に書かれたアプリケーションの中には動かなくなるものもあり対策が
必要になりました。

skip-character-set-client-handshake

ってどこに設定するのかな？

「SQLインジェクション対策でプリペアドステートメントを使おう」
って記事をよく見かけるのですが、
プリペアドステートメントの使いかたが
わかりません

http://jp.php.net/manual/ja/pdo.prepared-statements.php

ここのページに

「アプリケーションで明示的にプリペアドステート
メントを使用するように すれば、SQL インジェク
ションは決して発生しません」

って書いてあるのだが、文字コードに
シフトJISを使っている場合は、
プリペアドステートメントでも通過されて
しまうよね？

SQLインジェクション対策で、
mysql_real_escape_string　を使ってエスケープするのと、
preparedstatement　と使う方法と、
2種類あるようですが、
どっちを使うべきなのですか？

prepareが使える環境ならprepare

>>126
>文字コードにシフトJISを使っている場合は、

何コード使ってようが、関係ないと思う。

>プリペアドステートメントでも通過されてしまうよね？

「通過されてしまう」とは?

>>127
一般論としては、prepared statement なんだろうけど、
クエリーキャッシュが効かなくなるとかの難点もある。

ＳＪＩＳなら発生するか文字化けするか二択じゃないの？
入力時に文字化けさせて出力時に修正して表示する、とかならあるだろうけど

5.1ではPrepared Statementでもクエリーキャッシュが効いちゃったりなんかしちゃったり
http://dev.mysql.com/doc/refman/5.1/en/query-cache-how.html

CREATE/DROP TEMPORARY TABLE と、TEMPORARY TABLE への INSERT/UPDATE/DELETE/SELECT
だけができるようなアクセス権限設定は可能でしょうか？
CREATE TEMPOARY TABLE テーブル名を決め打ちするくらいしか思いつきませんでした。

myisam の場合は、myisampack するとテーブルが ReadOnly になるので、
実質的には temp table しか変更できなくなるけど。

データベース example1 があったとき、このデータベースの default character set を調べるにはどうしたらいいですか。

show create database example1;

>>136
ちょーさんくすです。

どうもありがとうございます >>134

InnoDB 使っているのですが、一時作業用にDATABASEを作っておいて、
そこではなんでもできる権限を付与するのがいいのかなあ。

インストール直後の設定がうまくいかない・・・。

>>132
charset はサーバ単位じゃなくても、データベース/テーブル/カラム単位に設定できるので、好きにしなされ。

質問です。
PHPから操作するときなんだけど，hoge1ていうテーブルをuseするとき，
mysql_selectdb("hoge1");
と
mysql_query("use hoge1");
って何か違うの？

最終的にそのPHPスクリプトが掴んでいるMySQLサーバーとのセッション上で
use hoge1 と同等の処理を実行するという点では同等だと思います >>141

個人的には MySQL と PHP のどちらに処理を寄せるかの趣味の問題かな、という気が
しますけれども、どちら派が多いのですかね。SQL文レベルでの紛れを嫌うのであれば
PHP上で mysql_selectdb を使う方が無難ですかねえ。

php5-5.2.4 のソースコードを眺めてみましたが、mysql_selectdb の方は最終的に
MySQL C API の mysql_select_db() を呼び出しているようです。

mysql_query の方は(当然ながら)引数として何でもありなので最終的には MySQL C API
の mysql_real_query() を呼び出しているようです。

mysql-5.0-5.0.51 のソースコードを眺めたところでは mysql_select_db() の
mysql_real_query() どちらも実質的には(マクロですが) simple_command()
を発行しているだけかな…最終的にサーバーと通信する際に流れる(MySQLプロ
トコルの)パケットは同じになるような気がします(けど調べ方がわからない)。

>>140
違うよ
データーベース側の文字コードと、
クライアント側の文字コードを、同じとみなす、、
って設定をどうやるのか、って聞いてるの。

明示的に指定しないと、MySQLは、デフォルトで
lation-1を勝手にあてはめやがるから。

WinXPproSP3でMySQL5.0を使用しております

小一時間ほど前からMySQLを始めたのですがバックアップの項目でつまっています
何が間違っているか教えていただけないでしょうか？
mysqldump -uroot -pxxxxxx -hlocalhost test > c:\Documents and Settings\xxxxxx\test.sql
と入力すると
ERROR:
Unknown command '\D'.
Outfile disabled.
Outfile disabled.

と表示されてしまいます
\Dがひっかかってるのは一目瞭然なのですが、教本ではこれでバックアップが出来てるようです
ためしに/Dや\d、/dなどに変えてみても（他の\も/に変えてます）同じようにOutfile Disabledと出てしまいます
何が問題なのでしょうか？

すみません、自己解決しました
MySQLのコマンドラインからじゃなくて、Winにくっついてるほうからなんですね

http://www.google.co.jp/trends?q=MySQL

MySQL
じわじわ低下しとる

3000レコードほどのデータベースを更新する処理を考えています。

UPDATE hoge SET key = val, key = val, WHERE id = 1
UPDATE hoge SET key = val, key = val, WHERE id = 2
…
と3000個クエリを発行するのと、

REPLACE hoge (key,key) VALUES (val,val), (val,val)...
としてひとつのクエリで済ませるのではどちらが早いものなのでしょうか。

Syntax Errorですね。上のWHEREの前のコンマは不要です。

それってやってることが違うよね？
UPDATE: 空振りしたらなにもしない
REPLACE: 空振りしたらINSERTする