開発スピードアクセル全開ぶっちぎり！日本よ、これがMySQL 5.6だッ！！
米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC（リリース候補版）が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている！正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは？などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか？と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB
前書いた書きかけのメモを発見したので加筆して載せてみます。ちなみにこの話はMysql(InnoDB)利用時限定です。 モデルのcountメソッドは SELECT count(*) AS count_all FROM `blogs` のようなSQL文を発行します。このようなSQL文では、基本的に主キーインデックスによる全索引検索が行われます。通常、インデックスだけを読み込む全索引検索のほうが、テーブルだけを読み込む全表検索よりもI/O回数が少なくなるため高速になりますが、InnoDBの主キーインデックスは他の列値と直結している仕様で(この場合は)余計な列値を読み込むことになるため、あまり高速になりません。主キー以外のインデックスを利用した方が高速になるようです。 実際に試してみた rails2.3.2(たぶん), mysql5.0.77で試しました。 適当なrailsプロジェクトを作成し、s
このセクションでは、MyISAM テーブル（.MYI および .MYD の拡張子）に対して myisamchk を使用する方法について説明します。ISAM テーブル（.ISM および .ISD の拡張子）に対しては、isamchk を使用してください。 MySQL バージョン 3.23.14 以降、REPAIR TABLE コマンドで MyISAM テーブルを修復できるようになっています。 See 項4.5.5. 「REPAIR TABLE 構文」。 テーブル破損の症状としては、クエリが予期せず中断したり、以下のようなエラーが発生します。 tbl_name.frm is locked against change Can't find file tbl_name.MYI (Errcode: ###) Unexpected end of file Record file is crashed
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
MySQLの昇順ソートの問題 それは、昇順でソートすると、基準カラムがNULLの場合、それが先頭に来ることだ。実装としては正しいかもしれないが、NULLが最後に来てほしい場合もある。 しかし、MySQLには(少なくとも4.1系には)それを指定するオプションがない。よって、昇順にソートすると次のようになる。 例：面接に予約した学生を予約日順に昇順ソートする SELECT students.id,held_date_time FROM students LEFT JOIN interviews on students.interview_id = interviews.id ORDER BY held_date_time; +----+---------------------+ | id | held_date_time | +----+---------------------+ | 2
MySQL サーバーは、その操作に関する情報を提供する多くのステータス変数を保持します。 これらの変数およびその値は、SHOW [GLOBAL | SESSION] STATUS ステートメントを使用して表示できます (セクション13.7.7.37「SHOW STATUS ステートメント」を参照してください)。 オプションの GLOBAL キーワードはすべての接続にわたって値を集計し、SESSION は現在の接続についての値を表示します。 mysql> SHOW GLOBAL STATUS; +-----------------------------------+------------+ | Variable_name | Value | +-----------------------------------+------------+ | Aborted_clients | 0 |
MySQL サーバーは、その操作を構成する多くのシステム変数を保持します。 各システム変数にはデフォルト値があります。 システム変数は、コマンド行のオプションを使用するか、オプションファイルでサーバー起動時に設定できます。 これらのほとんどは、実行時に SET ステートメントを使用して動的に変更できます。これにより、サーバーを停止して再起動しなくても、サーバーの操作を変更できます。 式でシステム変数値を使用することもできます。 グローバルシステム変数のランタイム値を設定するには、通常、SYSTEM_VARIABLES_ADMIN 権限 (または非推奨の SUPER 権限) が必要です。 セッションシステムランタイム変数値を設定する場合、通常は特別な権限は必要なく、すべてのユーザーが実行できますが、例外があります。 詳細は、セクション5.1.9.1「システム変数権限」を参照してください シス
限りなく眠気を誘うPHP Internalsのセッションから逃げる。こっちの 講師はMySQL.comの人。講演慣れしていて、ずっとまともでプロフェッショナルな 感じ。午前中を逃したのが惜しいが、詳しいプレゼン資料は後日公開される らしい。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならないSHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通rnd と rnd_next の割合Key_reads : Key_read_requests 、ディスクから読まれた回数：総回数 この割合が1:100より悪くなったら要注意Key_write_requests:Key_writes 総書き込み要求回数：ディスクに書き込ま れた回数 キャッシュの効果などMax_used_con
経緯は自分でもまったく分からないのですが、気づいたらMySQLのrootアカウントを削除してしまいました。普段は開発中のDBに対してselect, update, insert, deleteのみを許した限定的な権限のユーザでゴニョゴニョしていたので、いざ新規テーブルを作成しようかと思ったらrootでつなげない→途方に暮れる、ということになったわけです。 よくある事例としては「rootのパスワードを忘れました」ということはあるかと思うのですが、「rootアカウント自体を削除してしまいました」という事例はなかなか聞きません。と、いうわけで地味に対応が困ったのですが、何とか復旧できたのでそのメモを記しておきます。OSはFedora5です。 まず、起動しているmysqldを停止させます。Fedoraだと(*) /etc/init.d/mysqld stop で、停止します。 (*) 起動パスなど
「更新とJOINが多ければMySQL，シンプルなSELECT主体ならPostgreSQLが向いている。ストアド・プロシージャでシングル・コネクションならFirebirdは非常に速い」---6月23日に開催された「オープンソースカンファレンス2007.DB（OSC2007.DB）」で，各オープンソースDBのコミュニティのメンバーによる性能比較が披露され，従来の一般的なイメージとは異なる“意外な結果”が明らかにされた。 オープンソースカンファレンスは，オープンソース関連コミュニティが主催するイベントで，OSC2007.DBはデータベース関連のコミュニティが集まったイベントである。性能比較セッションを担当したのは，日本MySQLユーザ会の堤井泰志氏，日本PostgreSQLユーザ会の片岡裕生氏，Firebird日本ユーザー会の木村明治氏。「あくまでボランティアによる性能比較であって，最速，最新マ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
