はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン
こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ
InnoDBの特性など考慮しつつ、ゲーム向けのDBやSQLを設計する上でのヒントや、注意するポイントなどです。Read less
ストレージエンジンの話 ~InnoDBのredo logをざっくり理解する~ - shallowな暮らし
こんにちは。id:shallow1729です。最近Database Reliability Engineerというお仕事を始めたのでデータベースの勉強をしたりMySQLのソースコードを読んだりしています。仕事でMySQLが標準で用いているInnoDBのソースコードを読む機会があったのでなんかアウトプットしたいなと思いつついきなりコアな話するのもなって思ったのでざっくりとストレージエンジンの話をしようかなと思います。とはいえストレージエンジンは本当にいろいろな仕事をしていて全部を書こうとするとものすごい事になりそうだった(+僕も分かってない部分が多い)ので、とりあえず第一回はredo logというやつを中心にストレージエンジンを追っていこうと思います。なるべく一般的なデータベースの設計の話を軸に置きつつInnoDBの場合の話もしていこうと思います。読者としてはMySQLのようなリレーショナル
一般論ですが、どんな基盤ソフトでもCPUスケールを上げようとすれば、何らかの排他制御を細かく行うことになるのでCPUのパイプライン処理にブレーキをかけるアトミックな処理が増えて、バージョンが上がるとある程度はシングルスレッドの処理は重くなっていきます。前エントリのような言語の高度化により遅くなる事情もあります。（中には、Redisのように並列を捨てて排他処理を完全排除する潔い逆振りプロダクトもありますが。） とはいえ、「これは（条件付きとはいえ）急に遅くなりすぎだろ！」と私も思うバージョン（回避策はある＆一開発者の一存ではどうにもできない）があるので遡って何点か挙げて注意喚起したいと思います。 これらはある程度限られた条件で発生するので世間では怪奇現象扱いされている可能性もあります。 何故こんなことになるのかというと、基盤となるmysqld側の変更に上手くついていけなくなってるか、性能上メ
こんにちは、shallow1729:detailです。今回は先日MyNA会というイベントで発表したMySQLの標準のストレージエンジンであるInnoDBのMVCCのガベージコレクションについて書こうと思います。発表自体もアーカイブされているので以下から見る事ができます。 「日本MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会-」 公開版 - YouTube まず前半ではMVCCに関連するデータ構造を見ながらガベージコレクションの重要性やlong-running transactionの問題点について解説します。後半では実際のガベージコレクション(purge)の処理をソースコードレベルで追いながら、ユーザーに提供されているパラメーターを解説をします。 これまでに比べると踏み込んだ話題なのであまり基礎的な事は解説しません。知らない単語が多いかもしれないですが、適宜調べな
MySQLの新製品「HeatWave」はInnoDBの最大400倍高速、テラバイト級を超える大規模データを分析可能なインメモリデータベース。スクエニやSCSKがその性能を検証［PR］
しかもHeatWaveはスケールアウトによる規模拡大が可能で、テラバイト級からそれを超える大規模データにも対応。 Oracle Cloud Infrastructureの備えるオーバーヘッドの小さなベアメタルサーバやネットワークを基盤としたスケールアウト機能により、サーバ台数とともにプロセッサコア数が増えても、ほぼリニアな性能向上を実現しています。 さらに、実行されたクエリと実行時間を学習データとして蓄積されていくため、HeatWave自身がインメモリデータベースにおけるデータの最適な配置を学習し、提案する機能も新たに備えるようになりました。 SQLを判別、最適なデータベースエンジンへ自動投入 この強力なデータ分析機能を、通常のMySQLとの違いをほとんど意識することなく利用できるのも、HeatWaveのもう1つの大きな特長でしょう。 HeatWaveはInnoDBとHeatWaveのデー
MySQL InnoDBにおけるPKにUUIDを使ったINSERTのパフォーマンスの調査 - CubicLouve
下記の記事を見て、PKにUUIDを使った際に内部的にどうなっているのかを確認してみました kccoder.com 比較対象として、PKにULIDを使った場合も調べてみました。 github.com ULIDはUUIDと互換性がある、ソート可能な識別子です。 MySQLのバージョン % mysql --version mysql Ver 8.0.19 for osx10.14 on x86_64 (Homebrew) スキーマ mysql> SHOW CREATE TABLE innodb_auto_increment\G *************************** 1. row *************************** Table: innodb_auto_increment Create Table: CREATE TABLE `innodb_auto_incr
MySQL 8.1シリーズにおけるInnoDB Clusterとリードレプリカの融合（ただしMySQL Serverは8.0でOK）
MySQL本体の新機能ではないのだが、MySQL ShellとMySQL Routerのイノベーションリリース（バージョン8.1）によりInnoDB Clusterに対してリードレプリカを追加することができるようになったので、今回はそのことについて解説をしていこうと思う。 InnoDB Clusterとは このブログではInnoDB Clusterとは何かということをそもそもまだ解説していなかったように思う。詳しいことはおいおい別の投稿で触れたいと思うが、InnoDB ClusterというのはMySQL Serverのグループレプリケーションを核にしたクラスタリング機能のことだ。MySQL Shellを用いてかんたんに構築でき、なおかつMySQL Routerを介して接続することにより、インスタンス障害が生じたときに自動的に接続先を振り替えることができる。イメージ的にはこんな感じ。 グルー
OSSデータベース取り取り時報 第59回オープンソースカンファレンスOnline、KDDIにおけるMySQL InnoDB Cluster事例、PostgreSQLのオンラインイベント紹介 この連載では、OSSコンソーシアム データベース部会のメンバーが、さまざまなオープンソースデータベースの毎月の出来事をお伝えしています。 オープンソースカンファレンスOnlineから 2月以降、オンライン開催となっているオープンソースカンファレンス（OSC）の近況です。 OSC Online/Nagoyaの続報 5月30日に開催されたOSC Online/Nagoyaは、朝10:00から18:00まで、最大5トラックのセミナーがずらっと並ぶ充実した構成となりました。参加者も事前エントリが500名を超えていましたので、オンラインでも例年の通常開催と変わらない規模となりました。OSSコンソーシアムでは、オー
こんにちは、GMOアドマーケティングのK.Mです。 最近は久しぶりにMySQLを使ってます。 そういえばMySQLといえば、バージョン5.7からInnoDBの全文検索機能に日本語パーサーが搭載されとても使いやすくなったと聞いていたので、本日はそれを試してみたいと思います。 以前はサービスで本格的な全文検索をやりたいと思ったら、Elasticsearchなど専用の全文検索エンジンを立てたりとミドルウェア構成が一段リッチになるような印象もありましたが、もう少しお手軽に、既存RDBMSからSELECTしてくるくらいのイメージでスモールスタートしたいようなケースも結構ありそうです。 そういったときに検討できる一つの選択肢になるんじゃないかと思っています。 既存テーブルを検索してみます MySQL5.7から日本語パーサーとしてN-gramとMeCabが使えます。特にN-gramの場合、デフォルトで有
In InnoDB Data Locking – Part 1 “Introduction” we’ve described the difficulties Lock System tries to solve using metaphor of people trying to concurrently edit spreadsheets. While it might be useful metaphor to get some intuitions about the problem, to talk about solutions it helps to know at least a little about the “reality” this metaphor maps to. In this post I’ll talk about how statements we’v
InnoDBをチューニングする際に、真っ先に確認するものといえばInnoDBバッファプールがあります。これは頻繁にアクセスされたテーブルデータやインデックスデータをキャッシュし、リクエストを高速に処理するための重要な機構です。基本的にはバッファプールは大きな値を設定するようにガイドされています。データサイズがすべてバッファプールサイズに収まるように設定すると安定したサービスの提供が可能です。 バッファプールサイズよりもデータサイズが大きい場合は、ディスクへのアクセスが頻発して運用しているサービスに影響があることもあります。しかし、サービスが頻繁にアクセスするデータは決まっていて（過去のデータにはほとんどアクセスしない）、そのデータがすべてバッファプール上にあるために問題なくサービスを運用できることもあります。このように、サービスの特性によるワーキングセットが重要になります。 今回は、バ
MySQL 8.0.22 で innodb_log_writer_threads の効果を見てみる - Qiita
これは MySQL Advent Calendar 2020 23 日目のエントリです。 昨日は atsuizo さんの「MySQLのデータ投入順序とデータファイルサイズのお話」でした。 そして、↓の記事の続きでもあります。 MySQL を使って EC2 r6g.large vs r5.large（mysqlslap 対決）をやってみた 前回は MySQL Community Server をインストールした AWS の EC2 インスタンスを使い、Graviton2 プロセッサと Intel プロセッサで mysqlslap 対決をしてみましたが、その延長で、innodb_log_writer_threadsの効果を確かめてみました。 innodb_log_writer_threadsとは MySQL 8.0.22 で追加された InnoDB の設定項目（パラメータ）です。 innodb
This blog is in reference to our previous ones for ‘Innodb Performance Optimizations Basics’ 2007 and 2013. Although there have been many blogs about adjusting MySQL variables for better performance since then, I think this topic deserves a blog update since the last update was a decade ago, and MySQL 5.7 and 8.0 have been released since then with some major changes. These guidelines work well for
MySQLのInnoDBとMyISAMのパフォーマンス比較をしてみましたー 対象のMySQLのバージョンは5.7と8.0です。 結論としては、 INSERTはMyISAMの方が早い SELECT・UPDATE・DELETEは 8.0ではInnoDBの方が早い 5.7ではSELECT・DELETEはMyISAMの方が早い。UPDATEはInnoDBの方が早い という結果でしたー！ なお、MySQLのバージョンごとのサポート期限は以下のようになっています。 MySQLバージョン MySQL AWS RDSのMySQL AWS AuroraのMySQL 5.7 2023年10月31日 2023 年 10 月 2024 年 10 月 31 日 (Aurora バージョン2) 8.0 2026年4月30日 未定 未定 (Aurora バージョン3) 検証条件 MySQL5.7-MyISAMで、1万件
こんにちわ。せじまです。 2021-07-09、日本MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会- でお話させていただくことになりました。勉強会等でお話させていただくのはずいぶん久しぶりで、オンラインイベントでは初となります。 資料を読み返してると「興味のある方は、予め、関心のある補足資料等にざっと目を通しておいていただいた方が、よりわかりやすくなるかも」と感じたので、イベント開催一週間前ですが、事前に資料を公開させていただくことにしました。
この記事は「MySQL Advent Calendar 2019 21日目」です。 これまた大遅刻となってしまって申し訳ございませんでした;(´◦ω◦｀): これも言い訳はダメだぞ自分！ さて、今年中にどうしても書き残して置きたかった内容があったのですが、ありがたくも「Adovent Calenderに書いていいよ！」というお話しをいただいたので…書かせていただきます。 題して「MySQL InnoDB Cluster 反省会」。 何もMySQLを知らない人間が、いきなり MySQL InnoDB Cluster Group Replication を導入した、そんなお話です。 前提 InnoDB Clusterを採用した理由 採用する前にやったこと 反省会（マネジメントチックな話） MySQLはコミュニティのものである 複数バージョン間レプリケーションがサポートポリシー変更 反省会（技術
DevOps Topologies 10 years on: what have we learned about silos, collaboration, and flow? - Matthew Skelton, Conflux
Tuning MySQL/InnoDB Flushing for a Write-Intensive Workload
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
この記事はMySQLのカレンダー | Advent Calendar 2023 - Qiitaの19日目の記事です。 MySQLのredoログには何が書かれているのだろうか？ そんな疑問を解決するために私はアマゾンの奥地へと旅立つことにしました。 MySQLはSQLをパースし、実行計画を立てたあと、実際にストレージ(メモリ含む)でデータを処理する部分はプラガブルなストレージエンジンに実装を移譲する設計になっています。 しかし、処理をストレージエンジンがトランザクションをサポートしないことも選択できるため、クラッシュリカバリのための機構を実装していない可能性もあります。 そのため、レプリケーションにも利用されるバイナリログがWrite Ahead Loggingされていて、クラッシュリカバリやPITRにもバイナリログが主に使われています。(と、筆者は理解しています。). なので、運用上はバイ
※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/02)です。 ※ 情報が古い可能性もありますので、ご留意ください。 設定値 ログバッファ→ログファイル ディスクフラッシュ ====================================================================== 0 毎秒 毎秒 1 (初期値) COMMIT時 COMMIT時 2 COMMIT時 毎秒 innodb_flush_log_at_trx_commit が0に設定された時は、ログ バッファは1秒に一回ログ ファイルに書き込まれ、ディスク操作へのフラッシュはログ ファイル上で行われますが、トランザクション コミットの際には何も行われません。この値が1(デフォルト)の時は、ログ ファイルは各トランザクション コミットの時にログ ファイルに書き込まれ
思い出せるうちに思い出せる範囲で… 例によって世に出る頃には全く違うことに取り組んでいるので、忙しくしてると何も書かずに終わってしまうのですが、こんなご時世、年末年始休暇があっても何も用事がなく折角なのですこし書き残します。本来は本家開発者のブログで英語で書くべきなんですが、込み入った話を英語で書く労力をかけるくらいなら次の問題解決にかけたほうがいいので、とりあえず日本語で書き残します… 私がMySQL界を離れている間にリリースされた8.0になってlog_sysのデザインが新しくなり、スケールが良くなったのですが、既存のハードを利用する大半のユーザーには、未だ荒かった実装のせいでデメリットの方が大きかったと思います。2019末くらいには悪い挙動と原因はある程度分かっていましたが、修正リリースは2020後半になってしまいました。 既存のスペックのハードウェアと、CPUコア多数搭載の最新ハード
for i in {1..100000}; do mysql -u root -e "INSERT INTO test.users set uuid=uuid(), id=uuid();"; done その他: innodb_buffer_pool_instances: 1 (単純化のため) 最適化の動作確認 次の順に操作を行い最適化/断片化の様子を確認します. ランダムInsert mysqldump optimize ランダムInsert MySQLが苦手とされるランダムInsertを領域管理の面から確認して行きたいと思います. ランダムInsert後の初期状態のディスク容量およびbuffer poolの状態を確認します. $ sudo ls -lah /var/lib/mysql/test/users.ibd -rw-r-----. 1 mysql mysql 44M 12月 23
MySQL 8.0 におけるJSON型のpartial update、およびそれに対するInnoDBの最適化について | GREE Engineering
HOMEInfoMySQL 8.0 におけるJSON型のpartial update、およびそれに対するInnoDBの最適化について こんにちわ。せじまです。 InnoDB に関する話をします。今回は大半が MySQL Server Blog や WorkLog のまとめ記事ですので、ゆるふわと言っていいでしょう。 JSON型の partial update に対する最適化というと、 binlog や replication にも関連するのですが、それについては今回は触れません。 はじめに 今回の内容は、MySQL Server Blog を熟読されている方であれば、すでにご存知のことが多いでしょう。ただ、「結局のところ、JSON型の partial update は、 InnoDB Adaptive Flushing においても有効なのか？」というところが疑問に残った方もいらっしゃるかも
MySQL8.0.27や8.0.28あたりのmemory/innodb/hash0hashやut0new.hなどの話 | GREE Engineering
こんにちわ。せじまです。 先日、プライベートで新しいPCを買ったので試しにVisual Studio 2022(version 17.7.2)でMySQL8.0.34をデバッグビルドしようと思ったら、sql_main がC2678でビルドできなくなってました（2023-08-29時点）。 Hyper-V上でen_USなWindows11開発環境を立ち上げて試してもC2678が発生したので、日本語版のWindowsに限った問題でもなさそうな気がします。 https://developercommunity.visualstudio.com/ を見ると、コンパイラ周りで "Fixed - Pending Release" な件がいくつか見受けられたので、しばらく様子見しようかなと思っています。 MySQL8.1.0や8.0.34をデバッグビルドする話を書こうかと思っていたのですが、今回は別の話
Photo by Kat Stokes on Unsplashこんにちは。仮想通貨の損益計算ツール「Gtax」、仮想通貨の確定申告サポート「Guaridan」を提供するAerial Partnersのエンジニアインターンの伊藤です。 今回は、Aerial Partnersのチームが実際にどのような技術を用いてブロックチェーンの社会実装を進めているかをお伝えするために、僕が最近取り組んでいた、大量のレコードを捌くDB処理の実装において直面した問題についてお話させていただきます。 InnoDBのロックアーキテクチャはややこしい！例題です。以下のような操作において、一体どのような原因でデッドロックが発生してしまうのでしょうか。 テーブル内容 > SHOW COLUMNS FROM t1;+-------+---------+------+-----+---------+-------+| Fie
【迷子】docker mysql InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size 704 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages! - Qiita
【迷子】docker mysql InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size 704 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!RailsMySQL初心者Docker
Mroonga から InnoDB FTS への乗り換えを考えてみた - mita2 database life
このエントリーはMySQL Casual Advent Calendar 2019 の7日目です。 実は、毎年 12 /7 日書いてます。 mita2db.hateblo.jp mita2db.hateblo.jp -- 昨日は、@SHINOHARATTT さんでした。 ポケモンを題材にして論理設計を学ぶ というエントリーでした。楽しく学べて良いです！ qiita.com -- 本エントリーではMroonga と InnoDB FTS の比較を軽くしてみたいと思います。 InnoDB FTS に乗り換えるモチベーション 耐障害性を高めたい mroonga ストレージエンジンは クラッシュセーフではありません。運が悪いと障害時に直前にコミットした内容が失われる可能性があります。 ラッパーモードでもテーブル本体はInnoDBなため、クラッシュセーフですが、インデックスはクラッシュセーフではあり
InnoDB のロック機構について
n 番煎じネタですが、一度やってみたかったので手元で検証してみました。 特段新しいものは無いと思いますが、インテンションロックと各種ロックタイプを網羅的に挙動検証する記事は自分の観測範囲にはなかったはず？ 図を用意できたら読みやすかったと思うのですが、怠慢したので innodb_status_output_locks の出力でご容赦ください データセット今回使うデータセットです mysql> show global variables like ‘version’; + — — — — — — — -+ — — — — + | Variable_name | Value | + — — — — — — — -+ — — — — + | version | 5.7.26 | + — — — — — — — -+ — — — — + 1 row in set (0.00 sec)mysql>
In this blog series, I’d like to introduce you gently to the topic on which I was working last 2 years, which is improving how InnoDB locks data (tables and rows) in order to provide illusion to clients that their queries are executed one after another, while in reality there is a lot of concurrency. I hope to start from a simplified view of the situation and challenges, and gradually introduce mo
InnoDBデータベースでmysqldumpする時は、single-transactionとskip-lock-tablesのオプションをつけよう | Masyus Work
MySQLでInnoDBのデータベースをダンプしようとした時の話。 mysqldump -uhogehoge -pfugafuga -h masyus.work > dump.sql シンプルに書くとこんな感じのコマンドになるかと思うが、実はちょっとしたLOCKの罠があったので解説してみる。検証したMySQLバージョンは5.7.26、データベースはInnoDBを使用。 暗黙で--lock-tablesが有効になっている もっと細かく言うと、 --opt というオプションがデフォルトで有効になっている。--optは複数のオプションを一括で有効にするオプションで、詳細は端折るがその複数のオプションの中の1つが--lock-tablesというわけだ。 参考） https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldu
MySQL（InnoDB）をデフォルトのトランザクション分離レベルのRepeatable-Readで運用していると、ワークロードによってはデッドロックが頻繁に発生して頭を悩ますことがあると思います。解決策としては、デッドロックを引き起こしている原因のSQLがどのような行ロックを取得したか確認して、デッドロックが起こらないようにSQLを修正します。 このほか、行ロックの待機が大量に発生して高負荷になり、サービスに影響が出てしまうこともあると思います。 今回は、そういったときに便利な「InnoDBの行ロック状態を確認する方法」を紹介したいと思います。実行環境にはMySQL 8.0.23を使用しています。 MySQL 8.0での調査方法 まずは、MySQL 8.0から追加されたperformance_schemaのテーブルを使って、あるSQLがどのような行ロックを取得しているか確認する方法を紹介
doublewrite とは？ InnoDB が備わっている「データ二重書き込み」によるデータ保護機能。最初から有効になっている。1 この機能はトランザクションログとは別なので混同しないように。 MySQL Server での説明 https://dev.mysql.com/doc/refman/5.7/en/innodb-doublewrite-buffer.html MariaDB Server での説明 https://mariadb.com/kb/en/library/xtradbinnodb-doublewrite-buffer/ Percona Server での説明 https://www.percona.com/doc/percona-server/5.5/performance/innodb_doublewrite_path.html SSD/HDD 混在環境のために d
はじめに みなさんこんにちはメリークリスマス🎄 ついにアドベントカレンダー最終日！！！ 現在SODAでwebエンジニアをしているtoshikiです。(3記事目で謎の自己紹介) CTOからflexispotのデスクを譲り受ける代わりにテックブログ3記事執筆するという約束を果たすべく、SODAのAdvent Calendar 2023で3枠担当することになり、この記事をもって無事プレゼントの配達が完了しました🎅(sorenani) 今日はクリスマス当日ということで、自分自身理解が曖昧だったMySQLのストレージエンジンであるInnoDBのロック周りの挙動をMySQLの公式ドキュメントを読みつつ調査してまとめてみました。 この記事でわかるInnoDBのロックの種類 共有ロックと排他ロック インテンションロック ギャップロック ネクストキーロック 検証環境 MySQLのVersion mysq
MySQLの壊れたInnoDBファイル(.ibd)からのデータサルベージ / Restore corrupted (broken) InnoDB data from .ibd file - 雑な hinananoha
この記事の対象 この記事は、MySQL Serverが突然の死を迎えた上に、以下のような重症症状が出た方向けの記事です。 MySQLサーバが以下のようなエラーを吐いて起動に失敗する 2022-06-16T11:30:47.188361Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 11:30:48 UTC - mysqld got signal 11 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. Thread pointer: 0x0 Attempting backtrace. You can use the following information t
MySQL の InnoDB をオンメモリで使ってみる - SO Technologies 開発者ブログ
こんにちは。 ATOM事業部の田村です。 今回は、MySQL の高速化の手段として、InnoDB エンジンをオンメモリで使った場合のパフォーマンスについて調査してみました。 はじめに MySQL には InnoDB エンジンだけではなく、他にもいくつものストレージエンジンがあります。 その中でも MEMORY エンジンは、その名の通りデータをメモリ上に持つため、処理が極めて高速という特徴があります。 ただし InnoDB とはいろいろ違う部分があり、InnoDB で使えていた SQL がそのまま通るわけではありません。 単に「高速化したい場合は InnoDB の代わりに MEMORY エンジンを使う」というわけには行かず、使い方・使い所をそれなりに考えてやる必要があります。 （詳細は Web 上に良質な記事が見つかるのでここでは省きます） MEMORY エンジンが真価を発揮するのは、キャッ
First we will talk about some of the other internal users of the technology that underpins the InnoDB Clone. MySQL Enterprise Backup (MEB) is an enterprise offering that provides backup and recovery for MySQL. Among various types of backups available, the following two types are of interest to us: Full Backup – A backup that backs up the entire MySQL instance – all the tables in each MySQL databas
こんにちは、内定者アルバイトの浅野です。普段は、スマホアプリ「モンスターストライク」（以下モンスト）のサーバサイドの開発に携わっています。今回は、モンストの開発環境をInnoDB memcached pluginを使って改善した取り組みについてご紹介します。 開発環境におけるタイムトラベラー機能モンストでは、次のイベントで利用するデータなどを確認するために、テスト用の環境において管理ツールでタイムトラベル機能（別名 タイムトラベラー）を提供しています。 タイムトラベルの機能は、キャッシュとRubyのGemであるtimecopを利用することで提供しています。 タイムトラベラーの仕組みタイムトラベルがどのように動作するか説明します。 管理画面よりタイムトラベルしたい日時をセットすると、キャッシュにタイムトラベルする日時がセットされます。このキャッシュを使ってTimecop.travelを実行す
エンジニアの小張です。多くのデータを扱うアプリケーションにとって、ユーザーが求めるデータを返すまでの速さは生命線とも言えます。 試行錯誤を重ねデータの蓄積量が増えれば増えるほど、アプリケーションが使いづらくなってしまったら、悲しいですよね。。。 今回はそんなレスポンス速度向上に必須の知識であるインデックスについて、構造からおさらいしていきたいと思います。 インデックスとは、 データベース上でのSELECT、WHEREなどの操作による データの集計・検索の高速化に貢献する技術の1つです。 ここでは、MySQLで使用されるInnoDBのインデックスについて説明します。 B+木(B+Tree)について MySQLのInnoDBエンジンで使われるインデックスは、B+木というデータ構造で実装されています。 InnoDBのインデックスは、以下の種類があります。 クラスタインデックス セカンダリインデッ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
MVCCとInnoDBでの実装について - shallowな暮らし
InnoDBのすゝめ（仮）
MySQLバージョンアップによるInnoDB性能劣化可能性事件簿
InnoDBのMVCCのガベージコレクションについて - shallowな暮らし
第59回 オープンソースカンファレンスOnline、KDDIにおけるMySQL InnoDB Cluster事例、PostgreSQLのオンラインイベント紹介 | gihyo.jp
MySQL InnoDB の全文検索機能をサクッと試してみました
MySQL :: InnoDB Data Locking - Part 2 "Locks"
第101回 InnoDBバッファプールの状態を確認するさまざまな方法 | gihyo.jp
InnoDB Performance Optimization Basics
MySQLのInnoDBとMyISAMのパフォーマンス比較をしてみました
NAND Flash から InnoDB にかけての話（仮） | GREE Engineering
MySQL InnoDB Cluster 反省会 - ASMのきもち
Dive into InnoDB from redo logs
InnoDB redo logを解読している話 - tom__bo’s Blog
"innodb_flush_log_at_trx_commit" について - 元RX-7乗りの適当な日々
MySQL 8.0 の InnoDB の log_sys周り の話
MySQL InnoDBの領域最適化 - Qiita
MySQL InnoDBのギャップロックによるデッドロックを解明する
MySQL :: InnoDB Data Locking - Part 1 "Introduction"
第145回 InnoDBの行ロック状態を確認する［その1］ | gihyo.jp
InnoDB の DoubleWrite 技術をみる - Qiita
MySQL(InnoDB)における各種ロックの挙動を調べてみた
MySQL :: InnoDB Clone and page tracking
InnoDB memcached Pluginを活用して開発環境を改善する
【MySQL】InnoDBのインデックス