元スレMySQL 総合 Part17

mysql覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

654 = :

>>653
第1引数は、時刻型か日付時刻型だど。

655 = :

データを保持してるテーブルに対して、カラム名を変更したり型を変えると中身のデータはどうなるのでしょうか？
カラムを削除したらそのカラムに関するデータが失われるだけですか？

656 = :

>>655
ALTERでMODIFYしてる分には失われないよ
サイズとか種類とか変えるとそれにあわせて
欠損したりするけど大体はまあいける。

657 = :

>>656
ありがとうございます。
データの型を変えてもデータが失われないというのは意外でした。
実は会社のデータベースをいじる業務を任されましてテーブルの型を変えるのが怖かったのです。
動作中のWebサービスのテーブル構造を変えるのはよく行われることなのでしょうか？

658 = :

型変更中はテーブルロックがかかりシステムが停止しますので、
行われません。

別のところできちんとテスト、リハーサルをして
データのバックアップを取って何が起こってもいいようにしてから
取り組みましょう。

659 = :

おおなるほど…アドバイスありがとうございました。
カラムを変える時はバックアップ取って慎重に行うようにします。

663 = :

>>661
そういうことだったのですか
ありがとうございました

665 = :

テーブル考えるのも難しいね。
できるだけ幅広く対応できるようにリレーショナル組むと
ばっらばらで、どこに何のデータがあるのかわからなくなるし、一気に複数のテーブルを
読み込んで最終的にデータが重くなる。

かといってシンプルに組もうと思うとあとで拡張するのがしんどくなる。
テーブルの組み方もやっぱりセンスなのかな？

みんなはどう？
一度組んであーしとけばよかったー・・・って思うときある？

670 = :

クエリーの重さはWhere次第、データ通信量は1件のみだから減る、でいいんじゃね？

671 = :

>１件のデータを読むだけの処理になるのでしょうか？

そうですよ。

ORDER BY併用のときはかなり軽くなる可能性。
最小値、もしくは最大値だけ算出されれば、後は何億件該当があっても関係無いはずだもんね。

672 = :

回答ありがとうございました。すっきりしました。
違う箇所を調査してみることにします。

674 = :

MySQLサーバに接続回数が何回あったとか確認する方法はありますでしょうか？
今アプリケーションを作っていて、
オーバヘッドを少なくするために、できるだけ接続回数を少なくして処理するよう組もうと思ってるのですが、
アプリケーション側の挙動（関数などの）がイマイチ理解できていないもので、
実際にどのくらい接続してるのか目で確かめることができれば、試行錯誤できるのですが、
FTPサーバのようにリアルタイムでユーザの接続状況がわかるような機能や、
外部アプリケーションがあったら教えてください。

678 = :

レス遅くなってすみません。

>>675-676
どうもありがとうございます。
早速その方法でテストしてみたいと思います。

>>677
どうもありがとうございます。
開発環境はWindows、本番環境もLinuxなのでちょっと無理ですが、
こういうのもあるんだということを今後のために頭に入れておきたいと思います。

レスくださったお三方ありがとうございました。

679 = :

>>677
あ、日本男児がいるぞ。

680 = :

違うってw
この間マニュアルを眺めてて発見しただけ。使ってみると便利だよ。

689 = :

>>688
どうやって入れたの？

690 :

会社のシステムのMySQLを運用して３ヶ月になります。
一つのDBサーバで４つのサービスを動かしているため、かなり負担がかかっています。
状況改善を指示されたため自分なりにネットで調べたところ、レプリケーションを行うのが良さそうだという結論になりました。

しかし、サーバをいじる経験が乏しい上、データベース自体の経験も３ヶ月です。
レプリケーションを行うことで既存のデータが壊れてしまうのがとても怖いです。

サーバを追加してレプリケーションを行うのは、素人に毛が生えたような技術者でも行える作業でしょうか？
あるいはリスクがあるのであれば他の対処法を教えていただけないでしょうか。

宜しくお願いします。

692 = :

ストレージ負荷とかメモリ負荷とかCPU負荷とかまず調べないとわからんちん

下手にレプリするより、より強力なサーバーに適切なチューニングして動かしたほうがいいんでねーの？

693 = :

1つのサーバで4つのサービス動かすのやめて
2つないし4つのサーバで動かせばいいじゃん
レプリケーションいらないじゃん

694 = :

アドバイスありがとうございます。

>>691
>>692
重い原因は分かっておりません。
１日のページビューが４つ合わせて２０万ぐらいなのですが、
マシンの性能はかなりハイスペックなのでどうして重くなってしまうのかが分かりません。
４つのサービスのうち２つが重くて残りの２つは快適に動くのが不思議なんです。
とりあえずレプリケーションは大変そうですね。
頂いたアドバイスを考慮すると時期早々な気がするので違う方法を考えてみることにします。

>>693
ごもっともなのですが、サービスは絶対に止めるなと言われてるのでデータ移行するのは少し怖いですね

695 = :

どういった対策をするにしても、まず重い原因を調べるのが先だろう

696 = :

・・・負荷が何にかかってるか調べるのが先でねーのｗ

698 = :

MySQLにinsertしたはずのレコードが入っていないという現象が
時々起こります。

具体的には、ブラウザからFORMで10個ほどの自然数のデータを送り、
PHPで、データ処理をして正誤を表示します。
送った10個のデータは、ひとつのレコードとしてMySQLに格納します。

通常は正常に動作しますが、一見正常に動作しているように見えて、
データベースに、この10個のデータのレコードが残っていないことがあります。
60～70回やって3回起こりました。

特にエラー表示などはなく、ブラウザには結果が正常に表示されます。
また、同時にデータベースとは他のやり取りもしており、これらも正常に動作し、
そのレコードも残っているので、データベースとの接続には問題ないようです。

このようなことはよく起こるのでしょうか？
対策としてinsertしたデータを、MySQLから再度呼び出して確認するなどの
機能を加えた方が良いのでしょうか？