私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【この先一体】MySQL 総合 Part15【どうなるの】
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ○
レスフィルター : (試験中)
MySQLの文字コードの事なんですが『＼（全角のバックスラッシュ）』の表示が正しくできません。
EUCのサイトのフォームからMySQLに入れ、
これをEUCで取り出すと半角の\になってしまいます。
MySQLのデフォルト文字コードはUTF8で、UTF8で取り出しても同様です。
ただコマンドプロンプト上でSJISで取り出した時はちゃんとバックスラッシュになるので、これをEUCでバックスラッシュにできないですか？
入出力時はちゃんとset names ujisは使ってますし、入れるときもエスケープ処理してます。
EUCのサイトのフォームからMySQLに入れ、
これをEUCで取り出すと半角の\になってしまいます。
MySQLのデフォルト文字コードはUTF8で、UTF8で取り出しても同様です。
ただコマンドプロンプト上でSJISで取り出した時はちゃんとバックスラッシュになるので、これをEUCでバックスラッシュにできないですか？
入出力時はちゃんとset names ujisは使ってますし、入れるときもエスケープ処理してます。
>>451-452
ここの住人はプログラムに関してはド素人なので他で聞いた方がいいと思います。
ここの住人はプログラムに関してはド素人なので他で聞いた方がいいと思います。
アップロードファイルのテーブルを作って、
日記のID, パスとかにすれば、
1日1ファイルじゃなくても大丈夫だぞ。
そのテーブルに、特定の日記に紐付くレコードがあれば
アップロードされたファイルがあるってことになる。
日記のID, パスとかにすれば、
1日1ファイルじゃなくても大丈夫だぞ。
そのテーブルに、特定の日記に紐付くレコードがあれば
アップロードされたファイルがあるってことになる。
>>453
マジで？プログラム使わずにMySQLだけだと出来る事が限られない？
マジで？プログラム使わずにMySQLだけだと出来る事が限られない？
>>456
データ出し入れするだけなら初級程度のプログラムで十分ですから。
データ出し入れするだけなら初級程度のプログラムで十分ですから。
MySQLが5.1になったらしいからインストールしてみたらイルカの写真が入ってただけだったわ。
さらに実験してみました。
UTF8のページでpost → set names utf8 → UTF8のDBに格納
select → set names utf8 → UTF8のページでprint
↑上記においても＼が\に変換される事はありませんでした。
文字コードが同じだから当然といえば当然ですが、
SJISとutf8、SJISとujisとの変換も問題ありませんでした。
よってこれはutf8とEUCの間における変換のバグなのでは？
バグでないとしても利便性が悪いので改善してほしいです。
この様な要望はどこに出せばいいのでしょうか？
参考までに
UTF8のページでpost → set names utf8 → UTF8のDBに格納
select → set names ujis → EUCのページでprint
だと＼は?になりました。
それ以外の文字は全く問題ありませんので普段DBに＼を入れない人は気が付かないのではないですか？
試しに自分のDBに＼をぶち込んでみて下さい。
※使用したDBは5.0と5.1です。
UTF8のページでpost → set names utf8 → UTF8のDBに格納
select → set names utf8 → UTF8のページでprint
↑上記においても＼が\に変換される事はありませんでした。
文字コードが同じだから当然といえば当然ですが、
SJISとutf8、SJISとujisとの変換も問題ありませんでした。
よってこれはutf8とEUCの間における変換のバグなのでは？
バグでないとしても利便性が悪いので改善してほしいです。
この様な要望はどこに出せばいいのでしょうか？
参考までに
UTF8のページでpost → set names utf8 → UTF8のDBに格納
select → set names ujis → EUCのページでprint
だと＼は?になりました。
それ以外の文字は全く問題ありませんので普段DBに＼を入れない人は気が付かないのではないですか？
試しに自分のDBに＼をぶち込んでみて下さい。
※使用したDBは5.0と5.1です。
なんで PostgreSQL 人気がないのか分からない。
速度も MySQL に勝つくらいになったし、いい本もあるし。
速度も MySQL に勝つくらいになったし、いい本もあるし。
っていうかポストグレだってきっと潜在バグあるだろーか。
mysqlだけが悪いように書くなや。
mysqlだけが悪いように書くなや。
>>453
文字コードの話をプログラミングだと思い込むようなド素人はそんなにいないから安心しれ。
文字コードの話をプログラミングだと思い込むようなド素人はそんなにいないから安心しれ。
これWindowsの話だよね？
俺もさっきやってみたら確かに同じ現象が出たｗ
バグかどうか知らんがユーザーの会のQ&Aにも無い事象だから
今まで誰も気が付かなかったんだろうねｗ
多分MySQL側がWindowsに配慮して文字コードを変える時にわざわざ\にしてるんだと思うけど。
俺もさっきやってみたら確かに同じ現象が出たｗ
バグかどうか知らんがユーザーの会のQ&Aにも無い事象だから
今まで誰も気が付かなかったんだろうねｗ
多分MySQL側がWindowsに配慮して文字コードを変える時にわざわざ\にしてるんだと思うけど。
>>473
死なす前にアドバイスを。。。
死なす前にアドバイスを。。。
>>451
その場合EUC-JPとしてujisじゃなくてeucjpmsを使う。
MySQLとしては4年前に対策済み。
このへんの記事をどうぞ。
http://www.mysql.gr.jp/mysqlml/mysql/msg/12442
その場合EUC-JPとしてujisじゃなくてeucjpmsを使う。
MySQLとしては4年前に対策済み。
このへんの記事をどうぞ。
http://www.mysql.gr.jp/mysqlml/mysql/msg/12442
>>477
情報小出しがよくない。
・対象のテーブルについてshow create table XXX\G
・例示しているshow processlist;を省略しないで全部書く
・my.cnfもさらす
話はそれから。
情報小出しがよくない。
・対象のテーブルについてshow create table XXX\G
・例示しているshow processlist;を省略しないで全部書く
・my.cnfもさらす
話はそれから。
だからポスグレ使えばいいじゃん。こんなクソみたいなDBにいつまでもしがみつくなって。
>>477
情報があまりにも小出しで憶測でしか回答できないんだけど
要するにユーザーエージェントとかIPアドレスとかリファラを取得してそれをDBに入れたいって事だよね。
この流れの中に著しく遅くなる原因があるとすれば
思い当たるのはIPアドレスからホスト名を得る場合に若干遅くなるので
それが溜まって遅延するのかも。
それにしてもPHPがタイムアウトする程遅いというのは若干異常。
マイクロタイム関数とかでどの処理に時間がかかってるのかを調べた方がいい。
MYSQL側は、一つのスクリプトで不必要にコネクトやクローズ繰り返したりせず
テーブル設計も不必要に大きくせず、不必要なクエリを送ったりしなければ
デフォルトで十分速いので大丈夫。
情報があまりにも小出しで憶測でしか回答できないんだけど
要するにユーザーエージェントとかIPアドレスとかリファラを取得してそれをDBに入れたいって事だよね。
この流れの中に著しく遅くなる原因があるとすれば
思い当たるのはIPアドレスからホスト名を得る場合に若干遅くなるので
それが溜まって遅延するのかも。
それにしてもPHPがタイムアウトする程遅いというのは若干異常。
マイクロタイム関数とかでどの処理に時間がかかってるのかを調べた方がいい。
MYSQL側は、一つのスクリプトで不必要にコネクトやクローズ繰り返したりせず
テーブル設計も不必要に大きくせず、不必要なクエリを送ったりしなければ
デフォルトで十分速いので大丈夫。
>>479
有難うございます。
+--------+----------------------+-----------------+-------------+---------+------+----------+---------------------------------------------------------------------------------------------------------------------------------
| Id | User | Host | db | Command | Time | State | Info
+--------+----------------------+-----------------+-------------+---------+------+----------+----------------------------------------------------------------------------------------------------------------------------------
| 256912 | ****** | localhost | *********** | Query | 33 | Locked | insert into user (個体識別,初めての時間,最新の時間,UA,訪問履歴,どこから来たか) values ('XXXX','1247543954','1247543954','DoCoMo....','1247543954idx,','5')
| 256913 | ****** | localhost | *********** | Query | 33 | Locked | insert into user (個体識別,初めての時間,最新の時間,UA,訪問履歴,どこから来たか) values ('YYYY','1247543954','1247543954','DoCoMo....','1247543954idx,','5')
| 256914 | ****** | localhost | *********** | Query | 33 | Locked | update user set 最新の時間='1247543954',comedate='1247543914idx,1247543945idx,' where 個体識別'xxxxxxx'
| 256915 | ****** | localhost | *********** | Query | 33 | Locked | update user set 最新の時間='1247543954',comedate='1247543914idx,1247543945idx,' where 個体識別'yyyyyyy'
そのほかは用意できしだい、載せます。
>>482
有難うございます。
>要するにユーザーエージェントとかIPアドレスとかリファラを取得してそれをDBに入れたいって事だよね。
そのとおりです。
携帯サイトなんですけど、ユーザー情報の種類は情報は
・個体識別番号
・機種名(UA)
・初めて訪問したUNIX時間
・最新のindexに訪問したUNIX時間
・訪問履歴、いつどこのページに訪問したか(時間index.php,時間main.php、時間out.php......)
・どこからきたユーザーか
です。ですからトップページへアクセスすると必ず
select->insert
もしくは
select->update
という流れが発生します。
>思い当たるのはIPアドレスからホスト名を得る場合に若干遅くなるので
それが溜まって遅延するのかも。
htacssessでIP制限をかけたうえで、UAでDoCoMoなどは判断しております。
よってIPアドレスからホスト名得るような記述はありません。
>それにしてもPHPがタイムアウトする程遅いというのは若干異常。 マイクロタイム関数とかでどの処理に時間がかかってるのかを調べた方がいい。
自分も異常だと思います。
マイクロタイム関数ではないんですけど、やはりSQL履歴をみると、
多数の処理がロックされてしまっているのが原因のようです。
解決策がわかりません。。。。。
たしかにそこそこアクセスはあるんですけど、
感覚的にタイムアウトしてしまうほどの処理の量はありえないと思うんですが。。。。
・
有難うございます。
+--------+----------------------+-----------------+-------------+---------+------+----------+---------------------------------------------------------------------------------------------------------------------------------
| Id | User | Host | db | Command | Time | State | Info
+--------+----------------------+-----------------+-------------+---------+------+----------+----------------------------------------------------------------------------------------------------------------------------------
| 256912 | ****** | localhost | *********** | Query | 33 | Locked | insert into user (個体識別,初めての時間,最新の時間,UA,訪問履歴,どこから来たか) values ('XXXX','1247543954','1247543954','DoCoMo....','1247543954idx,','5')
| 256913 | ****** | localhost | *********** | Query | 33 | Locked | insert into user (個体識別,初めての時間,最新の時間,UA,訪問履歴,どこから来たか) values ('YYYY','1247543954','1247543954','DoCoMo....','1247543954idx,','5')
| 256914 | ****** | localhost | *********** | Query | 33 | Locked | update user set 最新の時間='1247543954',comedate='1247543914idx,1247543945idx,' where 個体識別'xxxxxxx'
| 256915 | ****** | localhost | *********** | Query | 33 | Locked | update user set 最新の時間='1247543954',comedate='1247543914idx,1247543945idx,' where 個体識別'yyyyyyy'
そのほかは用意できしだい、載せます。
>>482
有難うございます。
>要するにユーザーエージェントとかIPアドレスとかリファラを取得してそれをDBに入れたいって事だよね。
そのとおりです。
携帯サイトなんですけど、ユーザー情報の種類は情報は
・個体識別番号
・機種名(UA)
・初めて訪問したUNIX時間
・最新のindexに訪問したUNIX時間
・訪問履歴、いつどこのページに訪問したか(時間index.php,時間main.php、時間out.php......)
・どこからきたユーザーか
です。ですからトップページへアクセスすると必ず
select->insert
もしくは
select->update
という流れが発生します。
>思い当たるのはIPアドレスからホスト名を得る場合に若干遅くなるので
それが溜まって遅延するのかも。
htacssessでIP制限をかけたうえで、UAでDoCoMoなどは判断しております。
よってIPアドレスからホスト名得るような記述はありません。
>それにしてもPHPがタイムアウトする程遅いというのは若干異常。 マイクロタイム関数とかでどの処理に時間がかかってるのかを調べた方がいい。
自分も異常だと思います。
マイクロタイム関数ではないんですけど、やはりSQL履歴をみると、
多数の処理がロックされてしまっているのが原因のようです。
解決策がわかりません。。。。。
たしかにそこそこアクセスはあるんですけど、
感覚的にタイムアウトしてしまうほどの処理の量はありえないと思うんですが。。。。
・
>>483
insertもupdateも原則爆速なのでselectの方法に問題があるのかも。
PHP側の処理で時間がかかりDBがその間待たされてる可能性もあるのでどっちに原因があるのかは調べた方がいいけど。
insertもupdateも原則爆速なのでselectの方法に問題があるのかも。
PHP側の処理で時間がかかりDBがその間待たされてる可能性もあるのでどっちに原因があるのかは調べた方がいいけど。
>>484
selectに関しては、
select 初めての訪問時間,最新の訪問時間,訪問履歴 from user where 個体識別='そのアクセスの個体識別'
というように毎回発行し、
結果行数が一行(訪問したことがある)の場合はupdate,
結果行数が0行(初めての訪問)の場合はinsert
というようにSQL文を発行しています。
SQLクエリ自体がロックされている(待たされている)ので、
SQL文を受ける側、DB側、に問題があるかと思います。
selectに関しては、
select 初めての訪問時間,最新の訪問時間,訪問履歴 from user where 個体識別='そのアクセスの個体識別'
というように毎回発行し、
結果行数が一行(訪問したことがある)の場合はupdate,
結果行数が0行(初めての訪問)の場合はinsert
というようにSQL文を発行しています。
SQLクエリ自体がロックされている(待たされている)ので、
SQL文を受ける側、DB側、に問題があるかと思います。
インデックスを作成したところ、あっさりと解決できました。
お騒がせしました、感謝します＾＾
お騒がせしました、感謝します＾＾
時期が時期だし米ではMyQL（マイクェル）みたいな新DB立ち上がったりしてないのかね。
正直選択に困る時代になったなあ…
ポスグレはレンサバが対応してないことも多いし。
正直選択に困る時代になったなあ…
ポスグレはレンサバが対応してないことも多いし。
MySQL に ISAM や InnoDB のように PostgreSQL があれば…
>>478
ついでに言っとくと、文字コード指定で、
sjisとujisは使わないほうがいい。
かわりに、cp932とeucjpmsを使うべき。
ちなみに、そうなった原因は、ユニコード
コンソーシアムが非常識だったせい。
MySQL ABはあんまり悪くない。
ついでに言っとくと、文字コード指定で、
sjisとujisは使わないほうがいい。
かわりに、cp932とeucjpmsを使うべき。
ちなみに、そうなった原因は、ユニコード
コンソーシアムが非常識だったせい。
MySQL ABはあんまり悪くない。
で、まだMySQLはsun製って事になってるけどいつ頃にOracle製って表記されるようになる予定なの？
>>455
そうだね。トランザクションでやることになると思う。
ただ、日記のIDを通番とかじゃなくて、先にIDがわかる方法(日付/時間ベースで振るとか)なら、
先にuploadファイルの方をINSERTしてから、日記INSERTでも良さそうだけど、
途中でエラーが起こることを考えたら、やっぱりトランザクションにした方がいいと思う。
そうだね。トランザクションでやることになると思う。
ただ、日記のIDを通番とかじゃなくて、先にIDがわかる方法(日付/時間ベースで振るとか)なら、
先にuploadファイルの方をINSERTしてから、日記INSERTでも良さそうだけど、
途中でエラーが起こることを考えたら、やっぱりトランザクションにした方がいいと思う。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
mysql スレッド一覧へ類似してるかもしれないスレッド
- 【MySQL】下らねぇ質問はID出して書き込みやがれ 2 (985) - [21%] - 2012/10/17 7:16
- 【】 MySQLを買収したSunを買収したOracleを 【】 (112) - [19%] - 2023/1/22 14:15
トップメニューへ / →のくす牧場書庫について