SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.2.15 WITH (共通テーブル式)
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL :: MySQL 8.4 Reference Manual :: 15.2.20 WITH (Common Table Expressions)
SAVEPOINT, ROLLBACK TO SAVEPOINT, and RELEASE SAVEPOINT Statements
note の Aurora MySQL を v2 から v3 へアップグレードしました｜tic40
note ではメインデータベースとして Aurora MySQL を採用し、日々発生する膨大なトラフィックを処理しています。Aurora MySQL v2 (MySQL 5.7 互換) の標準サポートは2024/10/31 に終了するため、これを機に v3 (MySQL 8.0 互換) へのアップグレードを行いました。 アップグレードは無事に完了しましたが、いくつかの問題にも直面しました。これらを共有することで、これからアップグレードを検討している方へ参考になればと思います。 事前に検討した課題アップグレード後に致命的な問題が起きたらどうするかv3 へのアップグレード後に v2 へ切り戻すことは容易ではなく、スナップショットなどからの復元が必要になります。データをロールバックすることになるため、ユーザ影響が極めて大きく避けたい事態です。 そのため、基本的に切り戻しはできないという前提でアッ
MySQL で SELECT COUNT(DISTINCT) VS SELECT COUNT(*) FROM (SELECT .. GROUP BY ..) AS t - blog.nomadscafe.jp
とあるMySQLのslowlogに残っていたところから見つけたクエリの書き換え。 サービスのどこで使われているものかまで詳しくみていないんだけど CREATE TABLE `category2item` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `category_id` int(10) unsigned NOT NULL, `subcategory_id` int(10) unsigned NOT NULL, `item_id` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `subcategory_id` (`subcategory_id`,`item_id`), KEY `picture_id` (`item_id`), KEY `category_id` (
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up
第196回 MySQLのexplicit_defaults_for_timestampオプションによって意図せずデータとテーブル定義変更をしてしまう現象について | gihyo.jp
MySQL道普請便り 第196回MySQLのexplicit_defaults_for_timestampオプションによって意図せずデータとテーブル定義変更をしてしまう現象について MySQLのオプションでexplicit_defaults_for_timestampというオプションをご存知でしょうか？ これはTIMESTAMP型の特定の非標準動作を有効にするかどうか、およびTIMESTAMP型のカラムでNULL値の処理を有効にするかどうかを決定するオプションになります。 先日、筆者が担当しているMySQLの運用において、このオプションによってデータおよびテーブル定義が意図しない形で書き換わってしまったことがありました。今回は同じような人が現れないように、このオプションについて解説します。 なにが起こったのか mysql> SHOW CREATE TABLE ts_t1\G *******
MySQL 8.0 の INSTANT DDL について | スマートスタイル TECH BLOG
MySQL 8.0.12 はマイナーバージョンアップですが、ALTER TABLE でカラムを追加する際のアルゴリズムに「INSTANT」が追加されました。 MySQL 8.0: InnoDB now supports Instant ADD COLUMN | MySQL Server Blog ALGORITHM=INSTANT とは？ 従来の「COPY」や「INPLACE」と異なり、メタデータの更新だけ行うことで高速かつ負荷をかけずにカラムの追加などが行えるようになりました。 ただし、使える範囲は限定的で下記のような操作のみになります。 インデックスオプションの変更 テーブル名の変更 SET/DROP DEFAULT MODIFY COLUMN virtual column の追加、削除 カラム追加（制限あり） カラム追加であっても、以下のような制限があります。 INSTANTアルゴリ
MySQLリリースノートで(略)勉強会8.0.30を開催しました - sakaikの日々雑感～(T)編
MySQL 8.0.30 のリリースノートをみてわいわい言う勉強会を開催しました。 mysql.connpass.com ここ数回は18時から開催していたところ、今回19時からの開催にしてみましたが、個人的には半端な時間だなぁという印象でした。皆さんにも尋ねたところ、まさに十人十色のご都合があり、お話を聞かせてもらいたい方もいっぱいいて、みんなが合う時間帯を見つける難しさを感じました。とはいいながらも時間を工面して参加してくださった皆さん、本当にありがとうございました！ あと、アレです。「車座になってわいわい言うような、顔の見えるイベントをやりたい」という趣旨でカメラオンを（案内ページでは）お願いしていたものですが、オンラインイベントにそれを求めるのは無理なのではないかという思いに、最近傾きつつあります。表情や反応が見えたほうがコミュニケーションとしての情報量は多いのだけど、本質は「技術的
MySQLのInstant ADD COLUMNをちゃんと調べてみる - y-asaba@hatenablog
この記事は裏freee developers Advent Calendar 2018の21日目の記事です。 freee株式会社でプロダクト基盤本部本部長をしています浅羽と申します。プロダクト基盤は文字通りプロダクトの基盤を作っており、SRE、分析基盤、アカウントアグリゲーション基盤を作っているチームになっています。コードを書く時間を減らして組織づくりにフォーカスしていますが、とはいえサービスを良くするためには技術も素振りする必要があると思っています。ということで、組織的な話ではなく技術的な話を書こうと思います。 サービスを運営しているとデータベースがだんだん大きくなってきて、RDBMSの性能がスローダウンするような場面があると思います。その引き金としてクエリが遅くなったり、大きめのテーブルに対してADD COLUMNをしてしまうなどがありえそうでしょうか。freeeではRDMBSはMyS
MySQL :: MySQL 8.0: InnoDB now supports Instant ADD COLUMN
Instant DDL has been one of the most requested InnoDB features for a very long time. With ever larger and rapidly growing datasets the ability to do DDL instantly is a must have feature in any web scale database. Developers constantly need to add new columns to meet the constantly changing business requirements. The ability to add ADD COLUMNs instantly is the first in a series of DDL statements
MySQLのバックアップって結局何使うべきか（2020年12月 ver） - istyle Tech Blog
この投稿はアイスタイル Advent Calendar 2020 の17日目の記事です。 はじめまして、アイスタイルでインフラ・DBAをやっているiwasakikです。 アイスタイルに入社して約1年半が経つのですが、日々新しい発見が得られる毎日を過ごしております。 今回はMySQLのバックアップに関する記事を書かせていただきます。 業務上MySQLの運用に関わる事が多いのですが、バックアップというのは取得されていて当たり前なんだけど、設定するのに手間かけない・負荷をかけないというのが大事だと考えています。 そこでMySQLのバックアップとしてどの手法を利用するのが良いのかについて、全てではないのですが複数のツールを比較・検証してみました。 結論、それぞれのバックアップ手法にメリット・デメリットがあるのですが、その詳細は後半お楽しみに！ 目次 検証したMySQLバックアップ手法について my
Percona XtraBackup for MySQL
All of Percona’s open source software products, in one place, to download as much or as little as you need.
MySQL5.6→5.7のアップデートで意図せぬスロークエリが発生した
何が起きていたのか クエリのTypeがrangeからフルインデックススキャンに変化していた 原因 range_optimizer_max_mem_sizeというパラメータが追加されていた 範囲オプティマイザで使用可能なメモリを制御するには、range_optimizer_max_mem_size システム変数を使用します。 ・値0は、「制限なし」を意味します。 ・0より大きい値を指定すると、オプティマイザは、範囲アクセス方法を検討する際に消費されるメモリを追跡します。指定された制限値を超えそうになると、範囲アクセス方法は放棄され、代わりにテーブルのフルスキャンを含む他の方法が検討されます。これは最適ではない可能性があります。このような場合、次のような警告が発生します（Nは現在のrange_optimizer_max_mem_sizeの値）。 Warning 3170 Memory capa
Three bugs in the Go MySQL Driver
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
テーブル最適化(や大量のDELETE)をほぼ無停止で行う | Gumu-Lab.
MySQLだとDELETEがとても重いです。10000件程度なら余裕ですが、100000件、1000000件にもなると手のつけようがないレベルです。その間MyISAMだとテーブルロックがかかるし、DELETEしすぎると今度は断片化してOPTIMIZE TABLEでもしないと速度低下が始まります。 OPTIMIZE TABLEやALTER TABLEはものすごく時間がかかることがあるんですよね。今回DELETEしようとしたテーブルはWebでの表示に必須の部分でして、どうせならWebをできるだけ落とさずにやってみるかという挑戦でした。 今回DELETEするのは27000000件くらいです。無理です。 処理を一度にできないと踏んだので、DELETEを増加量より多いLIMITで走らせればだんだんと減っていくのではないかと考え、実行。 ごり押しでLIMIT指定で絞ったDELETEを走らせた結果900
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL 5.7からMySQL 8.0へのバージョンアップ - MySQLを継続してお使いいただくために
GitHub - trilogy-libraries/trilogy: Trilogy is a client library for MySQL-compatible database servers, designed for performance, flexibility, and ease of embedding.
mysqlの frm ibd からテーブルを復活させたい！ - Qiita
my.cnfの場所を調べる - Qiita
