SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQLベースの分散インメモリDB「HeatWave」の最適化と運用自動化を支援する「MySQL Autopilot」、オラクルが発表 オラクルは、MySQLのデータベースエンジンに分散インメモリデータベース機能を搭載し、高速なデータ分析が可能な「HeatWave」向けの新機能として、機械学習による性能の最適化などを提供する「MySQL Autopilot」を発表しました。 Say hello to MySQL Autopilot, the in-memory query acceleration engine for @MySQL HeatWave Database Service in #OCI. https://t.co/u9aKiwoJCf pic.twitter.com/ec6sMJ1Fhs — Oracle (@Oracle) August 11, 2021 HeatWave
テーブルを作成するときにカラムに UNIQUE 制約をつけることでカラムに重複した値を格納することができなくなります。ここでは MySQL における UNIQUE 制約の使い方について解説します。 テーブルを作成したあとに UNIQUE インデックスを作成したり、作成したインデックスを削除する方法については「インデックスの作成」を参照してください。
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR この記事に書いた事 二分探索木のお話(前提知識) MySQLのInnoDBで利用されているB+木インデックスの構造と特性 (前提知識) MySQLのClusteredIndex,SecondaryIndexについて(前提知識) カーディナリティについて(前提知識) 実際の負荷対策 検出編 スロークエリ 検出編 その他のクエリ割り出しいろいろ クエリ・インデックスの最適化 explainの使い方と詳細 ケース別実践 単純にインデックスがあたっていないケース カーディナリティが低いインデックスが使われているケース 部分的にしかイ
2021/05/24 サイボウズ開運研修 動画が以下のサイトからリンクされています - https://blog.cybozu.io/entry/2021/07/20/100000 - これに矢印を書きながらぐりぐりやっていたわけなので、資料単体だとわかりづらいと思います…
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
はじめに この記事は、MySQL Casual Advent Calendar 2013 7日目の記事です。 〜 Casual に記事を書けばええんやでヽ(´ー｀)ノ 〜 私がMySQLで えっ？！ っと思った下記エントリーの挙動が何故そうなってしまうのかを書きたいと思います。 InnoDBで行ロック/テーブルロックになる条件 MyISAM はテーブルロック、InnoDB は行ロックが掛かるというのは有名な話じゃないかと。 ただ、最近知ったのですが、InnoDB だとしても必ずしも行ロックになるわけではなく、テーブルロックになる場合もあるようですね。 ... InnoDB であってもユニーク制約 or インデックスが張られているカラムで検索した場合以外はテーブルロックになってしまうようです。これは注意しないと思わぬところでテーブルロックになってしまって大変なことになりそう！ http://
はじめに結論 wait_timeout のデフォルト値はクライアントの接続モードによって変わる。 接続が対話型の場合は interactive_timeout のグローバル変数値 接続が非対話型の場合は wait_timeout のグローバル変数値 （対話型である）mysql コマンドのプロンプトで確認した設定値が、（非対話型の）プログラムでも同じであるとは限らないので注意！ wait_timeout とは 接続のアイドルタイムアウト秒数。 この秒数クライアントからの反応がない場合、MySQL サーバはクライアントとの接続を切る。 接続が切られた状態でクエリを送った場合、"Lost connection to server during query" や "MySQL server has gone away" のエラーが発生する。 #【ワナ】wait_timeout のデフォルト値（in
以前、このような記事を書きました。 Amazon Auroraクラスタへの接続にコネクションプーリングを使うときのフェイルオーバー対応 このときは、オンプレTomcat 8＋MySQL 5.5環境からAWS EC2上のTomcat8＋Aurora（MySQL互換）クラスタへの移行ということで、コネクションプールにDBCP2を使いましたが、色々問題があって調整が大変でした。 今回は、これをHikariCP（2.7.6）に置き換えて、どう変わるか試してみます。 Apache DBCP2接続での問題点 一言でいえば**「とにかく遅い」**です。 特に、「プールからコネクションを取得（借用）する処理が遅い」です。 そのため、 Auroraフェイルオーバー時の再接続に時間が掛かる フェイルオーバー後のWriterインスタンスへの再接続ができるようにするために異常コネクションの除去（Eviction）
DBのチューニングはインフラ環境、アプリのつくり等、その時の状況で調整する必要があります。今回はMySQLTunerというMySQLを診断してチューニングをアドバイスしてくれるツールを使って、実際にMySQLのチューニングを行いました。 MySQLTunerは警告項目に関してのみの情報は多いのですが、警告が出ていない項目に関する情報が少ないので、今回の診断結果をもとに詳しく解説していきます。 MySQLTunerのインストール まずはMySQLTunerをインストールしましょう。 MySQLTunerはPerlで作成されており、無料で利用できます。 インストールといっても、「サイトからzipファイルを取得して解凍するだけ！」といった至ってシンプルな作業です。 以下、インストールのサンプルコマンドです。 # cd /usr/local/src/ # wget -O MySQLTuner.zi
１つのトランザクションの中で、検索（SELECT文）を発行した時に、ロックをしたいことがあるかと思います。 というか、必要が生じました。 とある処理で、数値が不整合を起こす障害の原因調査をしたのですが、これが酷い。 処理自体は、あるテーブルの金額項目に対して、ユーザーが画面から入力した数値を加算するっていうものです。 仕様書に書いてるのは、こんな内容。 1．SELECT文でテーブルAからデータ抽出 2．1で取得した金額に、画面で入力した金額を加算 3．2の結果をテーブルAに上書きする。 1で取得した数値を加工して上書きするって仕様なんですから、SELECT文を発行する時にロックをかけないといけません。 しかし、この処理を実装したプログラマは違う考えがあったらしく、ロックを掛けなかったようです。 ...おい、ふざけるなよ。 というわけで、SELECT文の発行と同時に行ロックを実行します。 S
先週開催されたVLDB(Very Large Data Base)というDatabase分野のトップカンファレンスで松信さんがFirst authorの論文 MyRocks: LSM-Tree Database Storage Engine Serving Facebook's Social Graph が発表され、Best Industrial Paper Awardを受賞されました。 ↑ VLDB 2020 Awards - VLDB2020 Tokyoのスクショ 特にTwitterやブログ等で書いている人がいないようなので、この内容を紹介します。 VLDBはDatabase分野ではトップ中のトップカンファレンスで、新規のアーキテクチャやアルゴリズムが掲載されるものだと思っていました。 なので、VLDBにMyRocks論文が掲載されたと知って正直驚きましたが、内容を読んでみると松信さん
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説 こんにちは技術研究グループ・テクニカルディレクターの波多野です！ 普段は社内のインフラ、特にデータベース関連の技術的な問題を解決するのを仕事にしています。 弊社ではリレーショナル・データベースとしてはオープンソースの MySQL をとてもよく使っていますが、そんなオープンソースのデータベース界隈で最近よく目にするようになって来たのが 楽観的トランザクション(Optimistic Transaction) という技術です。今回はトランザクション処理の歴史的なところに触れながら、RocksDB に代表される楽観的トランザクションについて簡単に解説したいと思います はじめに MySQL を使っているとデフォルトでは REPEATABLE READ のトランザクション分離レベルになっていて、トランザク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
