タグ

mysqlに関するhecatoncaleのブックマーク (6)

  • DB設計時のサイズ見積もり - よねのはてな

    ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ

    DB設計時のサイズ見積もり - よねのはてな
  • MySQLノウハウ

    いろいろなからメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),

    hecatoncale
    hecatoncale 2007/07/13
    あとで
  • Open Tech Press | MySQLデータのバックアップ方法

    2007年5月31日10:53 Tom-Adelstein、Bill-Lubanovic(2007年5月29日(火)) ファイルやディレクトリのバックアップは比較的簡単だが、データベースのバックアップとなると、いくつか特別な工夫を施す必要がある。ここではMySQLを取り上げているが、同じ原理はPostgreSQLやその他のリレーショナルデータベースにもあてはまる。 稿は、最近O’Reillyから出版された書籍『 Linux System Administration 』の抜粋。 MySQLサーバを休みなく稼働させ続ける必要がないなら、以下に示すような圧縮なしのオフラインバックアップ手法が手っとり早い。 MySQLサーバを停止させる。 # /etc/init.d/mysqld stop MySQLのデータファイルおよびディレクトリをコピーする。例えば、MySQLのデータディレクトリ/var

    Open Tech Press | MySQLデータのバックアップ方法
    hecatoncale
    hecatoncale 2007/06/01
    あとで
  • Google Code Blog: Google releases patches that enhance the manageability and reliability of MySQL

    Posted by Mark Callaghan, Software Engineer Though you may think of us as simply a company with a big search index, Google uses MySQL, the open source relational database, in some of the applications that we build that are not search related. We think MySQL is a fantastic data storage solution, and as our projects push the requirements for the database in certain areas, we've made changes to enhan

    hecatoncale
    hecatoncale 2007/04/27
    あとで中身をみる
  • MySQLのクエリを最適化する10のTips - PHPプロ!ニュース

    平素より「PHPプロ!」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ!」ですが、サービスの利用状況を鑑みまして、2018年9月25日(火曜日)をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日(火曜日)を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 件に関するお問い合わせはこちらよりお願いいたします。

  • Real Beat » Blog Archive » [MySQL] MyISAMとInnoDB

    Keep drinking, Keep listening to music, Go fuck yourself 今運用している某システム、MyISAMのある難癖によって非常に辛い目に遭っております。それはもちろんテーブルロック。これはもうMyISAMを選択した時点でどうしても避けては通れない道。そこんところ仕組みをちゃんと理解してないと、MyISAMのほうが速いって言うから選んだのに、なんだよ全然遅いじゃん!っていうか使い物にならないよウワァァァァンみたいなことになりがち。今のシステムでどうやってMyISAMかInnoDBかを分けたのかというと、単純に更新頻度だった。頻繁に更新されるテーブルはInnoDB、そうじゃなければMyISAM。参照が殆どならInnoDBを選択するメリットは何もないと思っていた。が、実は全然そうじゃなかった。 MyISAMが辛いのは、INSERT文実行時にテーブル

    hecatoncale
    hecatoncale 2007/03/08
    テーブルロックの弊害について
  • 1