元スレMySQL 総合 Part13
mysql覧 / PC版 / みんなの評価 : ☆
前へ
801 = :
mysql_install_dbが権限テーブル作成に失敗していました。
（データベース「MySQL」のusr.MYDファイルを開いてみたら空だった）
原因は/tmpにアクセスする際の
パーミション問題(PCLinuxOSのディストリ的な影響)だったので
TMPDIR=/tmp/
MYSQL_UNIX_PORT=/tmp/mysqld.sock
export TMPDIR MYSQL_UNIX_PORT
という形で環境変数を変更してmysql_install_dbを実行したら問題なく動作しました。
>>797-798
ありがとうございました。助かりました。
802 = :
long_query_timeについて質問です。
現在DBI経由で、perlなどからSQL実行していますが
この時 long_query_timeに引っかかったクエリーは
エラーなり、補足捕捉情報かなにかを返すのでしょうか？
またこの時、viewは正しく返ってこない、と考えて良いのでしょうか？
MySQLバージョンは、4.0/4.1/5.0になります。
805 = :
>>782
GPLと相容れないプログラムとリンクできない
807 = :
HEAPテーブルについて、マニュアルには「クライアント間で共有できる」
とありますが、接続毎に隔離されたHEAPテーブルは作れないでしょうか？
バージョン4.1です。
810 = :
>>807
接続が切れたときに消えてなくなってもいいのであれば、temporary テーブル。
811 = :
>>809
それ、mysql> プロンプトからやってないか？
813 :
>>811
コマンドプロンプトからやってますが何か？
814 = :
MYSQLを導入したんだけどPHPから接続できないですけどどうしてでしょうか？
MYSQLの設定を済ませて
PHP５のphp.iniの設定では
絵xtension=php_mysql.dllのところを；はずしました。
MySQLの動作もちゃんとしてます。
ですが、
<?php
phpinfo()
?>
上で確認したところMySQLの表示してないです。
ｍｙSQLのインストールはこちらのURLを参考にしました。
？http://vine.1-max.net/MySQL.html？
こちらには、php5-mysqlが乗ってなかったので追加して
インストールしました。
どこが悪いのでしょうか？
以下がバーションになります。
LINUX：vinelinux3.2
apache：1.3 場所：/etc/httpd/
php5：5.2 /etc/php5/
MYSQL：4.0 /usr/share/mysql/
815 = :
自己解決しました。
817 = :
MySQL 5.0.51a Linux版です。
全テーブルに更新時刻と挿入時刻カラムをつけ、
beforeトリガーでこれらを更新しようと考えていますが、
オーバーヘッドはどんなものでしょうか？
用途は中小規模のグループウェアみたいなものです。
もしオーバーヘッドが大きいならtimestampで更新時刻だけ
記録することも考えるのですが、挿入時刻もあった方がいいようなのです。
MySQLで設計するのは初めてで感覚がわからないので、
なんとなくで結構ですので助言をお願いします。
818 :
>>813
何お前
ずいぶんと偉そうだな
819 = :
>>813
理解できるようになってから出直せ
820 :
出来ましたが何か？
822 = :
>>821
limit
823 = :
>>821
mysql> pager less
825 = :
cidrとip表記をごっちゃにしている時点でどうかと思うが、
phpがトリガならmod_geoipでも使ったらどうか？
826 = :
>>822 >>823 解決しました。ありがとうございます！！
827 = :
>>825
レス有り難う御座います。
早速調べてみます。
829 = :
みんな文字化け回避するためにカラムごとに文字コード設定してるの？
830 = :
http://mainichi.jp/enta/geinou/graph/200805/21/?inb=yt
ネット証券会社が主催するＦＸ（外国為替証拠金）取引コンテストの発表会が２１日、都内で行われた。
コンテストに特別参加するグラビアアイドルの滝沢乃南さん、山本彩乃さん、折原みかさん、山口愛実さん、佐々木梨絵さん
の５人が顔をそろえ、シストレに挑戦する意気込みなどを語った。
同コンテストは、自分で作成したトレードソフトの機能を評価する「シストレソフト部門」と、
ＦＸ初心者でも安心の仮想マネーを使った取引を体験できる「トレード部門」で賞金総額２０００万円を争う。
シストレ優秀ソフトは、最高２０００万円までの範囲内で買い取りの可能性もあるという。登録受付は２２日から。
仮想取引は６月２日～０９年４月３０日までとなっている。
▼トレード部門
初期資産500万円で、デモ取引のトレード収益を競っていただきます。
http://www.click-sec.com/corp/guide/demo/
http://www.fx-gp.com/about/
▼賞金総額
■社長特別賞（シストレソフト買取価格） 10,000,000円
●シストレソフト部門賞 1位300万円 2位100万円 3位50万円
●トレード部門賞 1位300万円 2位100万円 3位50万円
●前期MVP賞 50万円
●後期MVP賞 50万円
833 = :
varchar (n)の使用バイト数はn+1とのことですが、それなら
本来は100文字までのデータしか入力しないカラムでも
varchar(255)とtinytextの限界で作成しておいて、
アプリ側の入力チェックで100文字制限をするという方針はありでしょうか？
制限を100文字以上に拡張したくなったとき、アプリ側のチェックだけ直して
テーブルは変更する必要がなくていいのではないかと思うのですが。
834 = :
>>833の便乗質問ですが各データ型で使用するバイト長ってどこでわかりますか？
835 = :
>>834
http://dev.mysql.com/doc/refman/5.1/ja/storage-requirements.html
>>833
別に自分のしたいようにすればいいんでね？(自分にとって、管理しやすいほう、扱いやすいほうで)
ただ、fixed formatでテーブル作成してるんなら、discには実際使ってない部分の領域も書き込まれるけどね。
836 = :
>>835
ありがとうございます！助かりました
839 :
その規模になると、MySQLでは、どうやっても無理。パフォーマンスや安定性の面でもお薦めしない。
クラに泣き付いてでも、オラクルに戻してもらえ。
840 = :
単一tblって時点で何だかな～…
大規模すぎてMySQLの範疇じゃないだろ
841 = :
>>839-840
ありがとうございます。でも、それは無理っぽいです。
クライアントのライバル会社が全社的にOpenOfficeを採用したとかで、新聞に載ったらしく、
クライアントの経営トップがそれに対抗して、バックエンドにオープンソース採用の方針を
打ち出したいらしく、私が土下座するくらいでは受け入れられそうにも無いです。
842 = 839 :
かなり痛いトップだな。
コッド博士クラスの優秀なDB開発者を雇ってMySQLを改造してもらえ。
843 :
バカ相手してても身体壊すだけだから辞めちゃえｗ
844 = :
>>841
土下座て。
やるだけの事はやってちゃんと検証データとボトルネック、仕組み的に無理ですって事を踏まえた上で
それでもなんとかしろと言うならやりますが、紆余曲折、最悪こういう想定事態になりますが
よろしいですか？ってクライアントと折衝する人に言ってもらえばどうでしょうか。
自分の仕事は最低限筋の通った理屈を報告して折衝担当者に理解してもらうこと。
もちろん前向きにね。
自分の仕事を理解し、精一杯やるだけやってしっかりとこなした上で無理難題言う上司や客に必要以上の負担を強いられる道理はないでしょ？
ただその事を丁寧にビジネス用語で当たり障り無く表現して相手に理解、納得してもらうよう「伝える」努力は必要ですけど。
私もそこまでのデータの運用経験はないけど、微力ながら言わせてもらうと
■ハード面
・SASでRAID0+1 ファイバーチャネル使えるならそれに越したことはないけど。
=> ディスクの読み込み速度が上がって結果的にMySQLの更新・参照・集計早くなります。
=> バックアップできます。三世代管理くらいまではしたほうが幸せになれるかも。
=> RAIDはライトキャッシュとBBUのついているものを使用 なるべくキャッシュは多い方がいいです。
2GとかつけれるのもあるけどRAIDカード選びは慎重にね。
ディスクはシークタイムがあるから10000rpmのもので秒間16コミットしかできない
ライトキャッシュ積むといっぱいコミットできます
・レプリケーション
=> レプリケーションしているとは思うけど、なんとなくしてなさそうな節があるのでやって見て下さい。
スレーブサーバに参照を掛けるとスレーブの台数分だけ参照はバンバン早くなります。
ただし、マスターと完全同期ではないので入金処理等精度の必要な部分はマスターを使って下さい。
アプリケーション側でのスレーブ参照制御が面倒なら間にLVSでもなんでもいいからロードバランサー仕込むと吉
・memcacheサーバ
=> 80G程度ならサーバ10台以内で構築できると思う
更新はライトスルーでMySQLにも書いて単純参照はmemcacheからすると涙でるほど早い。
但しきちんと両方更新されたか確認、制御する仕組みは必要。
ソフト面に続く
845 = :
■ソフト面
・設計の見直し
=> 詳細知らないので絶対とは言えませんが、MySQL用にテーブル設計、運用設計見直した方がいいと思います。
単一テーブル80Gは異常に思えます。
同一テーブルを複数作って分割・分散したり非正規化してみたり。
内部の詳しい人に相談して下さい。詳細知らないと設計はできません。
・インデックスの見直し
=> 当然ですがインデックスの付け方と発行クエリでMySQLの速度は1000倍違うこともあります。
複合インデックス、プライマリ、単一ユニーク、複合ユニーク気を付けながらexplainしてチューニング。
・クエリの見直し
=> これもexplainしながらチューニング 色々調べてみてください。
=> 拡張インサート、INSERT IGNORE等を使うと便利な局面もあるかもしれません。
=> 集計は、トリガを使ってインサート時に集計値をインクリメントしたりすると負荷がさけれます。
=> DELETEは実行コストが高いので、削除フラグを付けて対応する。一日一回纏めてDELETE処理する等
・MyISAM、InnoDB
=> 参照はMyISAM、更新はInnoDB。
ライトスルー、レプリケーションと合わせて使えばパフォーマンス全然違います。
MyISAMはライトロックが有効かもしれません。デッドロックに気をつけて。
・コンパイル
=> MySQLはソースからICCでコンパイル。速いっす。
・文字コード
=> できればUTF-8。一番苦労しなくて済みます。MySQLの内部コードもUTF-8。
・チューニング
=> ケースバイケースなんでなんとも言えませんが
tmp_table_size
max_heap_table_size
は同じ値にしないとダメですよー
query_cacheをしてみてください
禁断のチューニング
innodb_support_xa = OFF
innodb_flush_method = O_DIRECT
sync_binlog = 0
innodb_flush_log_at_trx_commit = 2
innodbを使用している場合上記設定だとディスクIOがガンガン減るので更新負荷がガクンと下がります。
ただし、データの保存性は最悪。
予期せぬマシンダウンがあれば復旧できない場合もあります。
・専門のコンサル
=> 実現までの早さと質が必要ならMySQLに習熟してる会社にコンサル依頼するのが一番早いような気が・・・
KLABさんにでも頼んでみたら？とふと思いました。
私も規模が大きくなるに連れて運用に悩まされ、夢の中のトイレで自分のションベンの放物線を眺めている時でさえMySQLの事を
考えていた時期が三ヶ月ほどありました。
データもいっぱい壊しました。いっぱい怒られました。あぁ思い出したらトイレに行きたくなってきたのでこれくらいで。
846 = :
追記：あっSUNが買収してオープンソースでなくなるんじゃなかったっけ？
847 = :
>>844-846
実例を入れて膨らませて、本にしてくれませんか。絶対買います。
849 = :
>>844
ありがとう、めっさ参考になった。
850 = :
>>844-845
ちょっと、ブログかなんかに書いておくれよ
みんなの評価 : ☆
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- 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 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- 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 総合 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 ○
トップメニューへ / →のくす牧場書庫について