タグ

InnoDBに関するsomemoのブックマーク (5)

  • 長年の議論に終止符 -- MySQL、MariaDB、PostgreSQLのオプティマイザ/エクゼキュータ比較 - interdb’s blog

    https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、4つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記:オプティマイザについては省略してますが、こんながでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 *念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、

    長年の議論に終止符 -- MySQL、MariaDB、PostgreSQLのオプティマイザ/エクゼキュータ比較 - interdb’s blog
  • PostgreSQLユーザのためのMySQLバイナリログ・レプリケーション講座 - interdb’s blog

    Original Streaming Replication搭載のPostgreSQL9.0リリースが近づき、MySQLとのレプリケーション比較が今後ますます盛んになると思われるので、PostgreSQLユーザ向けにMySQLの説明を行う。 参考->MySQLユーザのためのPostgreSQL:WALログとレプリケーション講座 なお、なぜ最初に延々とバイナリログを説明するかといえば、MySQLのレプリケーションでマスタからスレーブに送るのは、バイナリログのデータだからである。 [レベル:1] MySQLのバイナリログ MySQLにはWALログに直接対応するものはない。理由はMySQLがマルチストレージエンジンだからである。 マルチストレージエンジンについては後述するのでここでは簡単に説明すると、 MySQLはトランザクション機能ありのInnoDB型というテーブルや、トランザクション機能なし

    PostgreSQLユーザのためのMySQLバイナリログ・レプリケーション講座 - interdb’s blog
  • QA@IT サービス終了のお知らせ - @IT

    平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識

    QA@IT サービス終了のお知らせ - @IT
  • 大規模ソーシャルゲーム「ドラゴンコレクション」運営の最前線で得られたノウハウ ~チューニングと運用、18のポイント~

    大規模ゲーム運営のポイント:データベースのチューニング データベースのチューニングについて、正延氏は次の7つのポイントを挙げました。 1:net_slave_timeoutは短くする スレーブサーバでは、しばしばレプリケーションが行われなくなっていることがあります。これは何らかの原因でマスターとスレーブ間のコネクションが失われたためですが、MySQLはこのことを認識しません。しかも、レプリケーション通信が行われない場合のコネクション再接続時間が、標準で3,600秒と非常に長く実質的ではありません。net_slave_timeoutの時間を短くすることで、レプリケーションが止まってもすぐに再開できるようになります。 2:max_binlog_sizeは小さくする max_binlog_sizeはバイナリログがローテーションされるサイズのしきい値を指定しますが、標準で1GBが設定されています。

    大規模ソーシャルゲーム「ドラゴンコレクション」運営の最前線で得られたノウハウ ~チューニングと運用、18のポイント~
  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

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

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