[MySQL] ステータス取得系の SQL まとめ | バシャログ。
夏休みまだ取れてないよ～・・・夏終わっちゃうよ～・・・みなさん、こんちには nakamura です。 コンテンツ DB への更新・参照等は日々使うので割りと覚えやすいですが、パフォーマンスチューニング等行う際にテーブルや MySQL 自体のステータスを取得する SQL ってしょっちゅう使うわけではないので結構忘れがちですよね～。今日はその辺りの SQL 文を備忘録も兼ねてまとめてみようと思います。 テーブル関連 テーブルの一覧を取得。 show tables; テーブル構造を取得。 describe table_name; ; describe にはショートカットが用意されています。 desc table_name; CREATE TABLE 文を取得。 show create table table_name; テーブルの状態を取得。 ; 全てのテーブルを表示 show table st
![[MySQL] ステータス取得系の SQL まとめ | バシャログ。](https://cdn-ak-scissors.b.st-hatena.com/image/square/20c0b0df62783283e7ba333774006e31f6235c74/height=288;version=1;width=512/https%3A%2F%2Fbashalog.c-brains.jp%2Fimages%2Fdb01.jpg)
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - （ひ）メモ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
「Linux-DBシステム構築／運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか？ - kazuhoのメモ置き場
松信さんがやってくれました。 ずいぶん前からデータベースの「正しい」構築と運用方法についてまとめた本はないかなーと思ってました。自分はこれまで、様々なネットワークアプリケーションのプログラミングやデータベースの設計、チューニングを行ってきています*1が、問題が解決できたようには見えても、果たしてそれが最適な解決策だったのか不安に感じることがありました。それは、体系的な知識に欠けているからです。だから、網羅的な教科書がほしいなぁって思ってたんです。 とあるインターネットでこの前、松信さんから「いま書いてる」って話を聞いて、一部を見せていただいたりしたんですが、つい昨日、手元に届きました。やったね☆ 名前は「Linux-DBシステム構築／運用入門」。「入門」と銘打たれているものの、基礎的な知識から、なぜそうなるのか、どう応用すればいいのか、といった点まで広くカバーしている*2、全方位的な隙のな
「MySQL，PostgreSQLとFirebirdの性能をユーザー会メンバーが徹底比較，判明...
「更新とJOINが多ければMySQL，シンプルなSELECT主体ならPostgreSQLが向いている。ストアド・プロシージャでシングル・コネクションならFirebirdは非常に速い」---6月23日に開催された「オープンソースカンファレンス2007.DB（OSC2007.DB）」で，各オープンソースDBのコミュニティのメンバーによる性能比較が披露され，従来の一般的なイメージとは異なる“意外な結果”が明らかにされた。 オープンソースカンファレンスは，オープンソース関連コミュニティが主催するイベントで，OSC2007.DBはデータベース関連のコミュニティが集まったイベントである。性能比較セッションを担当したのは，日本MySQLユーザ会の堤井泰志氏，日本PostgreSQLユーザ会の片岡裕生氏，Firebird日本ユーザー会の木村明治氏。「あくまでボランティアによる性能比較であって，最速，最新マ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://japan.internet.com/busnews/20110909/6.html
