元スレMySQL 総合 Part15
mysql覧 / PC版 /みんなの評価 : ☆
152 = :
>>148
できるよ。
以上。
はい、次。
153 = :
全部変えたいならWHERE句はずせば1行ですむのでは
154 = :
>>153
すみません、書き方が悪かったです。
ひとつひとつデータが違うので、その手は使えないのです。
156 = :
>>154
だったら id IN() で1000個並べたら1行で済む。
158 = :
オレ、いまだにMyISAMなんだが
時代にとりのこされてるのか?
特に困ったことないけど。
159 = :
困ってないなら、それでいいやん
160 = :
トランザクションを使えないのでは?
161 = :
トランザクションと全文検索が一緒にできるようには
もうならないのかな
結構待ってるんだけど…
164 = :
テーブルを作り替えなきゃならないのかどうか、GRANT 関連が変わったかどうか、
取り敢えずこの二つは、リリースノートの最初に大書して欲しいものだとは思う。
166 = :
マイナーバージョンアップだと思って痛い目に遭う事を言ってるんじゃないの?
5.0.3 と 5.0.5 とで違うとか聞いたが。
168 = :
SSD,安くなったとは聞いたがそんなことが出来るのか
はてなの全文検索で、DB全部メモリに乗っけるのがこの前話題になってたな
そりゃ早いわ
169 = :
MySQLの定番ベンチマークって何がいいですか?
DBエンジンによってはファイルシステム次第かもしれませんが。
rawデバイスに乗せるっていうのを誰かやっていたような。
170 = :
若葉マーク
172 = :
【質問テンプレ】
・MySQL5.0
・欲しい結果:最終行のある要素の値
Mysqlのある要素の最終行の値を取得するクエリがわかりません
select [ある要素] from [table名] where ~;
こんな感じで取得するクエリを教えてください
173 = :
最終行の定義を述べないと誰も答えられんと思う。
174 = :
>>173
最終行は未ソートの状態で、一番最後にくる行です
select [ある要素] from [table名];
で一番最後にくる行です
175 = :
OracleでもMySQLでも未ソート時の並び順は決まってない。
最後に何がくるかは分からない。
176 = :
>>175
少し条件を変えます
[ある要素]はそのテーブル内での最大値が最終行にくるようになっています
その場合に最大値の値が取得できるようにしたいです
178 = :
MySQLってもしかして、サーバーのIPアドレスと、
ユーザーIDと、パスワードがばれると、
全然関係ない人から、勝手にサーバーに
アクセスされて、データーベースを使われてしまったりするの?
179 = :
アクセス元(のIPアドレスとかFQDNとか)で制限掛けてあれば、全然関係ない人からはアクセスされない。
その許可されているアクセス元の別のユーザが、ユーザID/パス盗めば、当然アクセスされる。
でも、MySQL に限らないんじゃないの?
180 = :
下記のエラーについて質問させてください。
Disk is full writing /var/lib/mysql/db/CBSC.MYI
LOGファイルなら削除で即解決だと思うのですが、
MYIファイルなのでどのように対応したらいいか分かりません。
出来ればMYIファイルを削除せずに下記のエラーが出ないようにしたいのですが、
何か良い対応方法はありませんか?
181 = :
それインデクスファイルだから、「出来れば削除せずに」どころではなく、そもそもインデクスができてない。
もうディスク増設した方がいいと思う。
どうしても現状のままというなら、まず *.MYI だけ他パーティションに移して、今の場所からは /bin/ln -s 新 旧 と
シンボリックリンク張ってから、myisampack してみるとか。(してる途中で disk full になっても知りませんよ)
182 = :
とりあえずdf -kでディスク状況を確認する事が先決だと思う。
/var/lib/mysqlに別パーティションをマウントしているならともかく、
/varが丸ごと一つのパーティションに乗っかっているとMySQL以外
にも色々問題が出てきますよ。
183 = :
HABTMリレーションを編集するときって
トランザクション使って一度全部消してから追加します?
それとも差分を求めて処理します?
auto_incrementのidがどんどんあがっていくのが・・・。
まあ1ユーザに1000回発行し直しても400万ユーザとかにならないと使い切らないんだけど。
184 = :
>>183
>トランザクション使って
そういう方法もあったか、なるほろ
188 = :
質問です。PHPからMySQLにクエリを送るとき。
型が文字列の変数$hoge を,型が int のカラムに insert したいのだが,
$sql = "INSERT INTO `table` (`column`) VALUES ('$source');"
mysql_query($sql) or die(mysql_error());
としたら,$hoge が""(空文字列)だと 0 が insert されるよね。
空文字列なら NULL が insert されるようにしたいんだが,どうすればよい?
189 = :
なんかすごくおっかない書き方なんだけど、PHPだとこれが普通なの?
191 = :
>>188
とりあえずNULLにしたいだけなら
if($hoge == 0)$hoge = "NULL";
else $hoge = "'$hoge'";
みたいなの書けば解決
DB側からのアプローチは知らん
192 = :
columnの型がintであるとわかっているのであれば、文字列から整数
への変換はクエリに値を埋め込む前に行っておくべきだと思う。
$sourceの値として空白文字列があり得るような実装がおっかない。
193 = :
188です。3行目の $source は $hoge の間違い。
>189>190
ごめん,始めたばっかなんで。どうすればよりよい?
ストアドプロシージャは一応勉強したけど,この場合どう使えばいい?
>191
できた。ありがとう。""と''の違いとsqlでの挙動がいまいち分かってなくて。
>192
フォームから入力を受け取ってDBに登録することを考えている。
もし入力がなかったらNULLにしたい。
そういうときは,$source に渡す前に空白文字列はNULLにしとけ,ってことかな。
194 = :
>>193
ユーザが入力した文字列を直接SQLに埋め込むのはとても危険。
エラーやセキュリティホールの元なので基本的には禁じ手。
なので、$sourceに渡す前に$hogeの内容を適切に処理する必要がある。
色々方法があるけど、今回はcolumnがint型なので、is_numeric関数
で文字列が数値表現かどうか調べて、intval関数でint型の値に変換。
SQLに値を埋め込む時はこの変換したint型の値を、入力された文字列
の代わりに用いる。
これらの処理の合間に入力値が有効範囲か確認してエラーを返したり
入力値が無かったらNULLをINSERTするなどの処理を書けばよい。
さらにprepared statemementを使うと確実。
195 = :
これ以上はスレチだからwikiなんかを当たって欲しいが
http://ja.wikipedia.org/wiki/SQLインジェクション
俺はXSS関連はめんどくさいから
$_POST = array_map("hoge",$_POST);
$_GET = array_map("hoge",$_GET);
とかやってるお
hogeでmysql_real_escapeやらhtmlspecialcharsやら処理
196 = :
あ、ごめんストアドプロシージャならこのスレが正しい
訂正ついでに
プリペアドステートメントでもストアドプロシージャでも
XSS対策には似たような効果を示す。(ただmysqliを使う必要があるが)
http://php.s3.to/man/pdo.prepared-statements.html
まあここらへんはだんだん慣れてくるとおもうお
197 = :
質問です。
phpMyadmin等ツールで一定の時間ごとにオーバーヘッドの解消を行いたいのですが、そのようなことは可能でしょうか?
198 = :
オーバーヘッドの解消ってなんのこと?
199 = :
>>198
phpMyAdminで見ると、項目としてあるみたいね。
http://oshiete1.goo.ne.jp/qa1155748.html
>>197
cronとかでoptimize tableしたら?
200 = :
>>197
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1413558214
みんなの評価 : ☆
類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- 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 vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について