また、このOSSコンソーシアムのセミナー枠の後、日本OSS推進フォーラムによるOSS鳥瞰図の紹介と、オープンソースソフトウェア協会の公開ミーティングが続きます。 ［MySQL］2024年の重大ニュースと2024年12月の主な出来事 MySQLの2024年の重大ニュースをピックアップしてみました。なお12月のMySQLのバージョンアップはありませんでした。 2024年MySQL重大ニュース 2024年のMySQLのニュースとして最も重要なものは、仕様変更や機能追加などを行わず、バグ修正のみをメジャーリリースから8年にわたって提供するLTS（Long-term Support）のリリースです。ほかにもいくつかニュースを取り上げてみました。 MySQL 8.4がLTSリリースとして提供開始 この連載の第92回でご紹介したMySQLの新しいリリースモデルのうちの、最初のLong-Term Supp
この記事は、LayerX Tech Advent Calendar 2024 の7日目の記事です。 tech.layerx.co.jp こんにちは。バクラクビジネスカード開発チーム エンジニアの iwamatsu です。 何か書くことないかな〜と頭を悩ませていたところ、見たことのない不思議なデッドロックに出くわしたので、今回はそれについて書こうと思います。 実行環境 バージョン: MySQL 8.0.39 ストレージエンジン: InnoDB トランザクション分離レベル: REPEATABLE READ 発生した事象 以下のようなユーザーテーブルがあるとします。 CREATE TABLE `users` ( `id` INT NOT NULL, `name` VARCHAR(255) NOT NULL, `lucky_color` VARCHAR(255) NOT NULL, PRIMARY
概要 RDB（リレーショナルデータベース）を運用していると、複数のトランザクションが同じデータに同時アクセスしようとする場合に「デッドロック」が発生することがあります。デッドロックとは、あるトランザクションが必要とするリソースが別のトランザクションによってロックされ、さらにそのトランザクションも他のリソースのロック解除を待っているため、互いに進行できなくなってしまう状態を指します。
タダです. DB マイグレーションなどで ALTER TABLE ステートメントを実行する機会は多いと思いますが,自分は ALGORITHM 指定した実行形式を意識して使ったことがこれまでありませんでした.今回実行形式に触れる機会があったので学んだメモをまとめます. ALTER TABLE ステートメントにおける実行形式 MySQL において ALTER TABLE ステートメントの実行形式は3つあります. COPY INPLACE INSTANT COPY COPY は新しいテーブル定義で一時テーブルを作成し,既存データをコピーして入れ替えます.ALTER TABLE ステートメント実行中テーブルをロックするため,実行中は書き込みがブロックされます.大規模テーブルへのロックがかかると,サービス利用に影響も出てしまうのでメンテナンスも必要になります.利用するケースとして主キーの削除やデータ
こんにちは。MySQLは秋の季語とする一派が世に存在していることを知り、私もMySQLに関わる記事を書いてみようと筆を取ることにしました。 さて、リレーショナルデータベースをバックエンドとするWebアプリケーション開発において、特定の条件に合致するレコードがN件だけ存在するかどうかを確認するロジックは頻出といえます。プログラマとして一度は書いたことがあるのではないでしょうか？ この記事ではそのような件数カウントを行うためのクエリが引き起こした性能劣化と、その改善アプローチについて紹介していきます。 なお、本記事の内容はMySQLを前提としており、アプリケーションコードの例はRuby on Railsを用いますが特別な前提知識は必要ありません。コードの雰囲気だけ感じ取っていただければと思います。 ありがちなコード if query.count == n の問題 冒頭で述べた通り、特定の条件に
MySQLではレプリケーションがよく利用されます。また、アプリケーションは負荷分散のために、ソースだけでなくレプリカを参照系として利用することも多いです。しかし、レプリケーションは遅延するリスクがあります。そのため、アプリケーションは高負荷やロングトランザクションによる想定外の遅延が起こることを考慮して、設計や実装を検討しなければなりません。 MySQLでは遅延レプリケーションをサポートしています。遅延レプリケーションとは、ソースよりもレプリカへの適用を指定した時間だけ意図的に遅らせることができる仕組みです。ステートメント単位ではなく、トランザクション単位で遅延を発生させます。ソースへのトランザクション実行から指定した時間後に、レプリカに対してそのトランザクションを適用することになります。トランザクション内の各ステートメントは待機時間なく実行されます。 今回はこの遅延レプリケーションの設定
こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし
タダです. MySQL で実行されているプロセスを確認するときは SHOW PROCESSLIST を叩いて確認してきました.MySQL8 のドキュメントを見ていると別の方法で確認する方法を知ったのでこの記事でまとめます. SHOW PROCESSLIST の代替テーブル さて本題ですが,SHOW PROCESSLIST の代替として processlist テーブルが有ることを知りました.ドキュメントによるとパフォーマンスが向上するとあるので, processlist テーブルを使用していくと良さそうです. これは、デフォルトの SHOW PROCESSLIST 実装とは異なり、mutex を必要とせず、パフォーマンス特性が向上します dev.mysql.com dev.mysql.com processlist テーブルは peformace_schema の中にあります.実際に SE
これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの
MySQLやPostgreSQLといったRDBMSからデータを引いてくるとき、扱うデータの規模によっては、1000件ずつLIMITをかけて順に引いていくということがある。 以前slow queryが出たらよくやっていたのを思い出して、ふとこのあたりってどういう根拠があってやっているのだっけ、自分が知っている他に効能があったりするのかな、と思ってSlackに書き込んだところ、同僚の id:onk に教えていただいた。その内容に加えて軽く調べた内容をまとめてみる。 Web系の話です。みなさまの知見がありましたら教えてください。 TL;DR 刺さる*1から 刺さったら困るから あたりまえ 詳細 もともとSlackに書いた原文は以下の通り(MySQL前提で書いているけどPostgresといった他のRDBMSにも適用できる話。): DB引くとき、Perl時代(？)によく1000件単位でchunkin
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
データベースアップグレード後の性能劣化、イヤですよね。 去る2023年某日、弊社ではAmazon Aurora MySQL 互換エディション 2 (MySQL 5.7 互換) から Aurora MySQL 互換エディション 3 (MySQL 8.0 互換) にアップグレードしました。当時の背景やアップグレードに関する知見は以下の記事をぜひ読んでみてください。 blog.smartbank.co.jp ソフトウェアバージョンアップをするとき、旧バージョンが抱えていた問題の解決などの恩恵を我々は期待します。しかし時には予期せぬデグレーションに遭遇することもあります。我々のMySQL 8.0へのアップグレード前後においてもいくつかの問題に遭遇しました。 本記事ではそんな問題の一つ、MySQL 8.0のオプティマイザが選択したセミジョイン最適化が性能劣化を引き起こした事例と解決方法について紹介し
オラクルはリレーショナルデータベース「MySQL」の新バージョンとなる「MySQL 9.0」をリリースしました。 MySQLは現在、数カ月ごとにリリースされ積極的に新機能が追加されるイノベーションリリース（Innovation Release）と、長期で安定して利用されることを想定して2年ごとにリリースされる長期サポート（LTS：Long Term Support）版の2つに分かれてリリースされています。 現在のLTS版は今年（2024年）4月に登場したMySQL 8.4です。 そして今回リリースされたMySQL 9.0はイノベーションリリースに該当します。最新機能をいちはやく試したい開発者やユーザーのためのリリースです。 MySQL 9.0の主な新機能 MySQL 9.0のドキュメント「What Is New in MySQL 9.0」から、新機能「JavaScriptストアドプログラム
データベースのGUIクライアントツールってたくさんありますよね。 「漢は黙ってコマンド！」って方もいるかとは思いますが、私は便利なツールは用途に合わせて使いたい派です。 （もちろんコマンドを知らなくてもいいという意味ではないです） 今回はMySQLのおすすめクライアントツールのご紹介です。 Mac版 Sequel Ace ★オススメ 私個人的にはMacだとこれが一番使いやすいです。 軽くて大体の機能はついていますし、dumpなども取りやすいです。 https://sequel-ace.com ※以前はSequel Proを利用していましたが、 2021/06/01現在で、開発が止まっているため乗り換えました。 現状は後継アプリのSequel Aceの使用をおすすめします。 基本的にはSequel ProからフォークしたプロジェクトのようなのでUI/UXもほぼ同様に違和感なく使用できます。
はじめに こんにちは、バックエンドエンジニアのSakiです！バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL（InnoDB）についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しや
こんにちは。技術部プラットフォームグループのharukinです。 この記事では、私たちが提供するネットショップ作成・運用のためのECプラットフォーム「カラーミーショップ」のデータベースを、Amazon RDSのブルー/グリーンデプロイを利用し、MySQLのバージョン5.7.38から8.0.35へアップグレードした経験についてご紹介します。カラーミーショップにおいてはこれが初の試みでした。Amazon RDS固有のファーストタッチレイテンシーの解除方法や、ダウンタイム時間の計測についてもお伝えします。 Amazon RDSのブルー/グリーンデプロイを活用するメリットは、本番環境に準ずるステージング環境を構築し事前検証が可能であることです。ステージング環境は約1分で本番環境に昇格させることができ、昇格時に許容ダウンタイムを超えたり、レプリケーションやインスタンスの問題が生じた場合は、自動的にプ
SQL実行の流れ まずはSQLがどのような流れで実行されるのかを見ていきます。 SQL実行の流れは大まかに捉えると以下のようになります。 パーサ パーサでは、ユーザーから送信されたクエリを受け取り、その文法的な正確さを検証します。SQLクエリが正しくフォーマットされているか、必要な構文要素が全て含まれているかをチェックし、例えばFROM句で指定されたテーブルが存在するかどうかも確認します。 文法的なエラーがある場合、例えばカンマの欠落や存在しないテーブルの参照など、クエリはエラーとして返されます。 エラーがない場合は、クエリは「抽象構文木」というデータ構造に変換されます。これにより、データベースはクエリをより効率的に解析し、次の処理ステップに進めることができます。 オプティマイザ SQLクエリがパーサを通過した後、次にクエリの最適化を行うのが「オプティマイザ」です。オプティマイザの主な役割
今回答えを出したい問いはこちら！！ インデックスはどのような仕組みを以て、何を実現したいものなのか それを踏まえたとき、インデックスはどういう場合になぜ貼る方が良いのか。また、どういう場合になぜ貼らない方が良いのか 大体分かっているよって人はサヨナラって感じのおさらい記事だぜ！！！！それじゃいってみよー🎉 あと、おれは今回MySQLにしぼっていくぜ👶 ってわけでOracleとかに興味があるやつは引き返しな！ indexの概要 公式の見解としては「where句を使ったselectクエリの実行速度を向上させるために実装されている、各行へのポインターのような振る舞いをする仕組み」って感じ👶 The best way to improve the performance of SELECT operations is to create indexes on one or more of t
TL;DR TypeORMで発生していたスロークエリを改善 スロークエリを改善したらECSの負荷も減少 はじめに スロークエリを改善したら、ECSコンテナ側の負荷も下がってなんでだろ？と思ったので記事にしようと思います。 環境 TypeORM v0.3.20 Node.js v18.x バックエンドインフラ ECS on Fargate => Amazon Aurora MySQL 負荷改善の前と後 まずはどのくらい改善したのかを示します。 この時ECSコンテナ8台動いてました。(4vCPU 8GBMem) 改善前 改善後 改善前と改善後は一日前の同じ時間帯のものです。 ちゃんと動いてるのか不安になるくらい下がってました笑 どのような対応をしたのか スロークエリの出ていたクエリでMySQLの実行計画を確認しました。 TypeALL,index, Using Filesort等はなかったので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
