タグ

関連タグで絞り込む (9)

タグの絞り込みを解除

InnoDBに関するwata88のブックマーク (13)

  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。


    InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして﹁COUNT()が遅い﹂というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い︵テーブルの行数を保持してる︶のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
    漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

  • MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ


    こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら﹁何でこんなにインデックスだらけなの？﹂みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数をbとすると、
    MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ

  • InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる！


    MySQL 5.1.38からMySQL本体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、﹁InnoDB使ってますよ！﹂もしくは﹁検証してるよ！﹂という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ？！という人が多いんではないかと思うのだが、実際はどうなのだろう？現在はRC版︵リリース候補版︶という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。 なお、以下の解説は現在の最新バージョンである、InnoDB Plugin 1.0.6を前提にしているので、将
    InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる！

  • (帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst


    MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた﹁InnoDBパフォーマンス最適化の基礎﹂という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
    (帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst

  • InnoDBのログとテーブルスペースの関係


    InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな？と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日本語に直すと﹁前もって書き込んでおくためのログ﹂とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を
    InnoDBのログとテーブルスペースの関係

  • MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst


    MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
    MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst

  • innodb_buffer_pool_sizeのチューニング：どれくらい割り当てる？


    結論としてはinnodbテーブルの全データ量だそうです。 ここ最近はデータベースサーバのリプレースの案件の担当をしているのですが、サーバのサイジングをしていてふと、﹁どれくらいメモリあれば足りるんだろう﹂と疑問に思いました。 よく﹁サーバの全メモリの50％から70％くらい﹂とか﹁80％﹂くらいとか言われますが、それはどちらかというとスワップしないための限界値を示すものであって、理想値ではないですよね。それでいろいろ調べてみたところ、なかなか日本語で良いまとめがなかったので、まとめてみようと思います。 目次 そもそもinnodb_buffer_poolとは？ 使用状況を確認する(SHOW ENGINE INNODB STATUSでの計測) 適切なinnodb_buffer_pool_sizeは？︵チューニング方法︶ そもそもinnodb_buffer_poolとは？ InnoDBmaint

  • MyISAMとInnoDBのどちらを使うべきか

    Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL

  • 【MySQL】AUTO_INCREMENTの値が増える、飛ぶ、欠番が発生する at softelメモ


    問題 auto_incrementの値が飛び飛びになるんですけど。 答え MySQL5.1.22以降、InnoDBのAUTO_INCREMENTの性能が向上しましたが、それに伴って、AUTO_INCREMENTの連番が飛ぶ場合が発生するようです。 プライマリーキー以外のユニークキーで重複してエラーとなる場合などです。 なお、MyISAMエンジンでは発生しません。 再現方法。1、テーブルを作ります。ストレージエンジンはInnoDBにします。 CREATE TABLE test1 ( id int PRIMARY KEY AUTO_INCREMENT, a int NOT NULL UNIQUE ) ENGINE = InnoDB; ２、1行入ります insert into test1 (a) values (1); +----+---+ | id | a | +----+---+ | 1
    【MySQL】AUTO_INCREMENTの値が増える、飛ぶ、欠番が発生する at softelメモ

  • 【MySQL】InnoDBのテーブルでAUTO_INCREMENTの連番が飛ぶ at softelメモ


    問題 InnoDBエンジンのあるテーブルに、insert into T select * from XXX 系のSQLを流すと、AUTO_INCREMENTの連番が余分に消費されて、次に挿入するレコードにはかなり飛んだ番号が付きました。 1,2,3,4,5,6,7,8,9,10 の10行が入った後で、次の行を入れると連番が16になっているなど。 なぜでしょう。 答え より単純な再現手順。 insertは2行のはずだが、連番が3進む。1つ余分に進む。 /* AUTO_INCREMENTのカラムを持つテーブルを作成 */ create table T ( id int primary key auto_increment, code varchar(10) not null ) engine=InnoDB; /* insert select をする. code 'a' と 'b' の行を追加す
    【MySQL】InnoDBのテーブルでAUTO_INCREMENTの連番が飛ぶ at softelメモ

  • MySQLがオンラインALTER TABLEでOOM Killerに殺されたはなし | GMOメディア エンジニアブログ

    こんにちは、DBAです。 MySQL5.6のオンラインALTER TABLEでハマった時のおはなしです。 5.6にはオンラインALTER TABLE関連のパラメーターに innodb_sort_buffer_size というものが追加されており(5.5以前はfast index creationが効く時に使われるパラメーターとして内部的に1Mでハードコードされていたものが、設定可能になった)、前にざっくり試したところ 大きくすれば一応それなりの恩恵は受けられそうなので大きくしたんですよ。 毎日の定期バッチで盛大にInnoDBのテーブルにバルクインサートをかけた後にALTER TABLEでインデックスをくっつけてRENAME TABLEでテーブルを切り替える…なんてことをやっているサービスには打ってつけだと思ったわけです（そもそもそのやり方の善悪について やがて DBAは 考えることを止めた

  • MySQLの新しいInnoDB ページI/O圧縮機能について解析してみた: hasegaw blog


    InnoDBにはデータの圧縮機能がありますが、パフォーマンスが低いことからあまり使われていません。ただ今年の Percona Live で Oracle MySQL, MariaDB, そして Percona Server が新しい InnoDB Compression を出してきました。これはFusion-ioの R&Dチームがフラッシュストレージ向けの MySQL 高速化の一環で開発したパッチが元になっています。ちなみに私は Fusion-io の社員ですのでこの発表をワクテカして待っていたのですが、折角コードが一般にリリースされたので、ソースコードを眺めて動作を調べることにしました。 参考にしたのは MySQL Server Snapshots (labs.mysql.com) にある MySQLwith InnoDB PageIO Compression のソースコード、および

  • MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ


    もう寒の入りを過ぎましたね。DBAのたなかです。GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました︵と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです︶ 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残　念　な　が　ら　腐　っ　て　お　り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス　ロ　ー　ク　エ　リ　ー　が　1　0　倍　く　ら　い　に　な　っ　た　ん　だ　け　ど　… と訴え、彼はその
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.