Don’t Start Using Your MySQL Server Until You’ve Configured Your OS
Whenever you install your favorite MySQL server on a freshly created Ubuntu instance, you start by updating the configuration for MySQL, such as configuring buffer pool, changing the default datadir director, and disabling one of the most outstanding features – query cache. It’s a nice thing to do, but first things first. Let’s review the best practices we usually follow in Managed Services before
こんにちは、エンジニアの川本です。 主にBUYMAの決済・配送を担当しているチームでバックエンドの開発をしています。 この記事は Enigmo Advent Calendar 2023 の 20 日目の記事です。 個人開発でPlanetScaleというMySQL互換のサーバーレスデータベースを使用しているのですが、特筆すべき仕様として外部キーのサポートがありません。 planetscale.com 外部キー制約はDBレベルで強い整合性を担保できる便利な手段ですが、PlanetScaleではその機能が利用できないので、アプリケーションレベルで整合性を担保する必要があります。 MySQLの外部キーのオプションにはいくつか種類がありますが、これらが使えない場合にアプリケーション側ではどのように担保すればよいのでしょうか？ 今回は、Railsを例にしてアプリケーション側でMySQLの外部キーに相当
下記の記事のように複数行に対する UPDATE は BEGIN の無い 1 文でもデッドロックすることがあります。 UPDATE1文だけでもデッドロックするという話 - tmtms のメモ これを見て思ったのですが INSERT であればバルクではない 1 行だけでもデッドロックすることがあります。 次のようなテーブルを用意します。 create table s ( sid int not null primary key ); create table t ( id int not null primary key, sid int not null, foreign key (sid) references s (sid) ); 次のクエリでデッドロックします。 insert into t values (1,1); 実際に試してみます。次のように INSERT を並列にたくさん実行し
エンジニアの小張です。多くのデータを扱うアプリケーションにとって、ユーザーが求めるデータを返すまでの速さは生命線とも言えます。 試行錯誤を重ねデータの蓄積量が増えれば増えるほど、アプリケーションが使いづらくなってしまったら、悲しいですよね。。。 今回はそんなレスポンス速度向上に必須の知識であるインデックスについて、構造からおさらいしていきたいと思います。 インデックスとは、 データベース上でのSELECT、WHEREなどの操作による データの集計・検索の高速化に貢献する技術の1つです。 ここでは、MySQLで使用されるInnoDBのインデックスについて説明します。 B+木(B+Tree)について MySQLのInnoDBエンジンで使われるインデックスは、B+木というデータ構造で実装されています。 InnoDBのインデックスは、以下の種類があります。 クラスタインデックス セカンダリインデッ
こちら↓について、Aurora で軽く遊んでみたらいくつか途中でハマったのでメモを残しておきます。 【衝撃】AWSのRDSがデータを失わないBlue/Greenデプロイに対応しました（DevelopersIO） 2022/11/30 追記： GA になっているのに「ベータ版」と書くのも厭味ったらしいので（？）タイトルから削りました。 （正直、本当に「ベータ版」だと思っていました… 続編とあわせて読み進めると勘違いした意味が分かるのでは、と… ） 1. Aurora MySQL v1 のクラスタを用意 「あれ？ 2022/09/27 で新規クラスタは作れなくなったんじゃ…？」と思うかもしれませんが、これを書いている 2022/11/29 時点ではまだ作れます。 なお、データは Sakila Sample Database を入れてみました。 MySQLのSakila Sample Datab
MySQL Transactions - the physical side | Die wunderbare Welt von Isotopp
So you talk to a database, doing transactions. What happens actually, behind the scenes? Let’s have a look. There is a test table, and we write data into it inside a transaction: CREATE TABLE t ( id serial, data varbinary(255) ) START TRANSACTION READ WRITE INSERT INTO t ( id, data ) VALUES (NULL, RANDOM_BYTES(255)) COMMIT The MySQL test instance we are talking to is running on a Linux machine, an
ISUCON10 予選に参加しました - ishikawa_pro's memorandum
ISUCON10予選に参加したので、今日は参加報告と振り返りです。 isucon.net 昨年が初参加だったので今回が２回目の参加です。 ギリギリまで参加登録してなくて、twitterで残り100チーム切ったとかの報告があって、慌てて参加登録して滑り込みセーフな感じでした。(480番だった) 会社の同期5~6人と今年も出たいねと言っていましたが、僕以外だれも参加登録してなかったため、誰と出るかで揉めるのが嫌だったので、今回はこっそり１人で参加しました。 去年の自分のブログ見ながらやること思い出して作業してたので、今年もやったこと書き留めておきます。 使った言語と結果 昨年は、Goやってみたかったので事前にGoの勉強をしてGoで参加しました。 今年は、慣れた言語がいいなと思って、普段業務で使っているNode.jsで参加しました。 大体過去問みるとkoa.jsが多かった気がしてたので、今年もk
ISUCON10予選問題で EC2 c6g.2xlarge vs c5.2xlarge をやってみる - Hateburo: kazeburo hatenablog
少し前にISUCON10予選問題のスコアアップに取り組んでいたので、その成果を使い、EC2 Graviton2 インスタンスとIntel CPUのインスタンスでスコアを比較してみます。 ISUCON10予選問題チャレンジをしていた時のスレはこちら ISUCON10予選のベンチマーク、Macbook Pro上で、23000まででるようになった。Xeon Gold 6148 x2上だと37000。— kazeburo. (@kazeburo) 2020年10月28日 ここではISUCON10予選時のように複数台用意するのではなく、1台のサーバでGoのアプリケーションとMySQLを動作させ、同じサーバ上からベンチマークを実行しています。 準備 初期データを作る際のdockerコンテナでarm64対応していないものがあるため、Intel CPUのインスタンスで作成してscpする方法を取りました。
2020/03/25 MySQL Casual Talks Online(beta) Vol.1 https://mysql-casual.connpass.com/event/171277/
Epoch-based {Logging, Checkpointing, Index} - nikezono
#長編 皆さん，初めまして．NTT SICの中園 (nikezono) です． この記事は 自作DBMS Advent Calender 2020 の 18 日目の記事です． この記事では，前日にご紹介したLineairDBを実装するうえで用いたインメモリDBの最適化手法について解説します． ３つの最適化があり，それぞれ{Logging, Checkpointing, Index}についての話になります．3日に分けようかと一瞬思いましたが，どれも小粒なのでまとめました． 未執筆のリンク先 が多く含まれる記事になるかと思いますが，随時書いていきます． 記事の構成 1. インメモリDBの性能上の問題 1. a Logging 1. b Checkpointing 1. c Index 2. 銀の弾丸? Epoch Framework 3. Epoch Frameworkを使った最適化手法3種
1. Copyright © GREE, Inc. All Rights Reserved. NAND Flash から InnoDB にかけての話（仮） Takanori Sejima 2. Copyright © GREE, Inc. All Rights Reserved. 自己紹介 ● わりと MySQL のひと ● 3.23.58 から使ってる ● 前職の頃、十数年前は、 MMORPG の DB の設計などもやってました ● むかしは Resource Monitoring も力入れてやってました ● 一時期、ハードウェアの評価をガッツリやってました ● 稀に Linux の TCP プロトコルスタックについて調べたりもします ● さいきんはわりと MySQL よりなのかも 2 3. Copyright © GREE, Inc. All Rights Reserved. ● 時代
Dockerを使ってPHP+MySQLの試験環境を作るために、どうしようもなく転びまくった記録です。 ほかの時期だったり、使えるもののバージョンが変われば、また違った展開になると思います。 2020年5月時点で利用可能なDockerの最新版を使うべくアノ手コノ手でインストールに至るまでの一例です。 最終的にどうなったか AWSのEC2にあるFaro Sourceというところが提供するOptimized AWS CentOS 7.6.2 (X86, 64bit)を使いました。 このインスタンスはインスタンス料金とは別にソフトウェアライセンス料金がかかるようですのでご注意くださいまし。 本当にタマタマこの組み合わせでうまくいっただけで、それ以上何も感想はないです。 いろいろ使ったもの 開発端末OS Windows10 Pro 64bit Docker for Windows 2.2.0.5 V
Google SpannerとMySQLのトランザクションの違い - GMOインターネットグループ グループ研究開発本部
こんにちは，S.T.です。今回はGoogle Spannerを検証します。Spannerは関係データベースのデータ構造を持ちトランザクション処理に対応した分散データベースです。リアルタイムにトランザクション処理を行うようなアプリケーションのデータストアとしての利用も考慮されています。また，PostgreSQLのインタフェースの実装も進められており，アプリケーションから一般的なRDBと同様に使えるようになる日も近そうです。 そこで，今回はSpannerのトランザクションの挙動をMySQLのInnoDBと比較し，挙動の違いによる落とし穴がないかどうかを確かめます。具体的には，トランザクション分離レベルやロックの範囲について検証します。結論から言うと，何も考えずに単にRDB置き換えるだけでは大怪我をしそうだが，特性を理解していればそう大差ない実装でいけると言えそうです。また，Spannerの肝で
AWS re:Invent 2022 で発表の Torn Write Prevention と Optimized Write とは - サーバーワークスエンジニアブログ
カスタマーサクセス部 佐竹です。 本ブログでは、AWS re:Invent 2022 で発表されたアップデートである「Torn Write Prevention」と RDS における「Optimized Write」について記載します。 はじめに AWS Announces Torn Write Prevention for EC2 I4i instances, EBS, and Amazon RDS Amazon RDS Optimized Writes enables up to 2x higher write throughput at no additional cost New – Amazon RDS Optimized Reads and Optimized Writes Doublewrite Buffer Doublewrite Buffer の問題 Torn Write
エラーから学ぶMySQL InnoDBのレコード長制限 MySQL(InnoDB)にはデータ型やカラム数など様々な制限がありますが、レコード長にも制限があることはご存知でしょうか？ データベースに新しいテーブルやカラムを追加するとき、データの上限や使い方を考えてデータ型やインデックスを設計していると思いますが、レコード長を意識して設計している方は意外と少ないかもしれません。 今回、MySQL5.6環境で発生したエラーからレコード長の制限について学ぶことができたのでご紹介したいと思います。 この記事はアイソルート Advent Calendar 23日目の記事です。 こんにちは。 クラウドソリューショングループのakahane.tです。 昨日はnamiki.tさんの「【ノーコード】Amazon Honeycode で Todo リストを作ってみた」でした。 アジェンダ はじめに きっかけ 調
MySQL 8.0 では InnoDB関連が強化されていますが、ここでは AUTO_INCREMENT に対象を絞って検証してみたいと思います。 MySQL :: MySQL 8.0 Reference Manual :: 1.4 What Is New in MySQL 8.0 MySQL 8.0 からは AUTO_INCREMENT のカウンター値はREDOログに書き込まれるように変更になりました。 そのため、いくつかの挙動でMySQL 5.7と異なる動きをします。 サーバーを再起動しても AUTO_INCREMENT の値がリセットされなくなりました。 MySQL 5.7 まで存在していたテーブル定義の AUTO_INCREMENT の値がサーバーの再起動でリセットされてしまうバグが解消されました。 検証 MySQL 5.7とMySQL 8.0 で 0 件のテーブルで AUTO_IN
Backup/Restore Performance Conclusion: mysqldump vs MySQL Shell Utilities vs mydumper vs mysqlpump vs XtraBackup
A little bit ago, I released a blog post comparing the backup performance of different MySQL tools such as mysqldump, the MySQL Shell feature called Instance Dump, mysqlpump, mydumper, and Percona XtraBackup. You can find the first analysis here: Backup Performance Comparison: mysqldump vs. MySQL Shell Utilities vs. mydumper vs. mysqlpump vs. XtraBackup However, we know the backups are just the fi
コスト削減のため Redis の sorted sets で実装していたランキング処理を MySQL に移行しました - Mobile Factory Tech Blog
駅メモ！チームエンジニアの id:yumlonne です。 この記事では Redis の sorted sets で実装していたランキング処理を MySQL に移行した仕組みを紹介します。 背景 駅メモ！には複数のランキングがあり、Redis の sorted sets を使うことでパフォーマンスの高いランキング処理を実現していました。 中にはリリースからの全期間に渡るデータを利用するランキングもあり、Redis のメモリ使用率は日に日に増えていく一方でした。 何度か Redis をスケールアップしてメモリを増やすことで対応していましたが、根本的に対応しなければ今後も Redis をスケールアップもしくはスケールアウトさせ続けるしか選択肢がなく、コストが増え続けてしまう状況でした。 調査したところ、一部のランキングがメモリ使用率の 2/3 程度を占めていることが判明しました。 そこで、その
あけましておめでとうございます。この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。2023年もOSSデータベース取り取り時報をよろしくお願いいたします。 ［MySQL］2022年12月の主な出来事 2022年11月のMySQLの製品リリースはありませんでした。 クラウド版のMySQLであるMySQL HeatWave Database Serviceでは、レプリケーション機能の強化が行われ、お客様のご要望の多かったリードレプリカが追加されました。参照処理の負荷分散用のMySQLサーバーを18台まで追加でき、ロードバランサーとして機能するエンドポイントを利用可能となっています。 またAmazon RDSなどMySQLサーバーと完全互換ではないクラウド・データベースからのレプリケーションの際は、これまでは中間サーバーにて非互
Improve query performance using Optimized Reads on Amazon RDS for MySQL and Amazon RDS for MariaDB | Amazon Web Services
AWS Database Blog Improve query performance using Optimized Reads on Amazon RDS for MySQL and Amazon RDS for MariaDB Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale MySQL and MariaDB deployments in the cloud. Developers are often required to run complex queries in MySQL and MariaDB environments to create a dashboard or run simple ad hoc reports. Furtherm
目次 目次 とある日 MySQL のバックアップ方法 各バックアップ方法のおさらい mysqldump — データベースバックアッププログラム mysqlpump — データベースバックアッププログラム MySQL Shellのダンプロードユーティリティ バックアップやってみた mysqldump mysqlpump MySQL Shell ついでにファイル容量調べた まとめ 〆 参考資料 とある日 Twitterで「mysqlpump」が話題になってました。 ?「DBのdumpとrestoreで40分かかってて大変なんです」 自分「dumpとrestoreの方法は?」 ?「mysqldumpで…」 自分「とりあえずdをpにしてもらっても良いですか？」 ?「10分になりました！」 みたいな事があってニヤリとした。 10分で終わる様になったので、30分かけてなぜ早くなるのかを説明した。— k
Aurora Serverless v2: The Good, the Better, and the Possibly Amazing - Jeremy Daly
Aurora Serverless v2: The Good, the Better, and the Possibly Amazing Aurora Serverless v2 Preview is here, and it looks very promising. I share my initial thoughts and results of some experiments I ran on this major upgrade. Three years ago at re:Invent 2017, AWS announced the original Amazon Aurora Serverless preview. I spent quite a bit of time with it, and when it went GA 9 months later, I publ
InnoDB のフラグメンテーションについてドキュメントを読んだメモ。 なおいずれも MySQL8 系のドキュメントを参照している。また Issue Tracker やソースコードまでの深堀りはしていおらず、基本的にドキュメントから分かる範囲だけをまとめている。 フラグメンテーションについて MySQL :: MySQL 8.0 Reference Manual :: 15.11.4 Defragmenting a Table より。 ランダムな INSERT や DELETE をしているうちに、だんだんと page のなかで「確保されているが使用されていない」領域が増えていく フラグメンテーションが大きくなると読み取り性能が劣化する可能性がある 次のような場合に偏っているいると考えられる 「本来あるべきデータサイズ」よりも「実際使われているデータサイズ」が大きい場合 「本来」とは何かが難
本記事の目的 本記事では MySQL(InnoDB) の SQL 性能調査・改善のために、実行計画の主要な確認ポイントを整理します。 また、SQL の重要な要素であるインデックスについても基本を簡単におさらいします。 なお、MySQL 実行計画の各種項目の意味は公式サイトに記載があるが、ぱっと見た時にどれが SQL の性能において重要度が高いのか少しわかりずらかったりしたので、今後のためにも記事に残すことにしました。 SQL パフォーマンスまわりで参考になった書籍や記事も最後に紹介していますので、ぜひそちらも合わせて参考にしてみてください。 インデックスとは インデックスはデータベースの中で特有の構造を持ち、CREATE INDEX 文で作成可能です。 SQL の性能に関わる重要な要素です。 データベースのインデックスは、分厚い紙の辞書から特定の用語を検索することに似ています。あらかじめ順
皆さんは、UPSERT処理という言葉をご存知でしょうか。UPDATEとINSERTを合わせた言葉で、INSERTをする際に、すでにそのデータが存在していない場合はINSERTを行って、その行がある場合はUPDATEを行うという処理になります。 今回は、MySQLでUPSERT処理を実現する方法を紹介していきたいと思います。 検証環境 今回はdockerで建てたMySQLを使用します。以下のコマンドでdockerを建ててローカルからアクセスをします。 % docker run --platform linux/x86_64 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:latest アクセス方法は以下の通りになります。 % mysql -uroot -pmy-secret-pw -h127.0.0.1 -P3307 執筆時
こんにちは。サイオステクノロジー OSS サポート担当 山本 です。 今回は以前紹介した監視ツール Prometheus が収集するためのデータを出力するツール Exporter について、いくつかの Exporter を例にして導入手順を確認してみたいと思います。 Prometheus の概要については、過去記事 を参照してください。 ■Exporter について Exporter について少しおさらいしておきます。 Exporter は特定の URL にアクセスされた時に、導入したマシンで収集したデータ群 metrics を出力するツールです。Prometheus の本体でこの metrics のデータを収集・蓄積する形で、Prometheus は監視を行います。 つまり、Exporter の出力する metrics の内容がそのまま Prometheus の監視内容となります。 出力
Table of Contents cat head tail wc grep cut paste sort uniq awk tr fold sed Real-life examples Going further: for loops and xargs Summary Going further Text processing in the shell One of the things that makes the shell an invaluable tool is the amount of available text processing commands, and the ability to easily pipe them into each other to build complex text processing workflows. These comman
2022年7月13日にカラーミーショップで提供開始した「副管理者機能」のアップデートにあたって、従前の挙動を変えずにデータベーススキーマの構造を変える必要がありました。また、サービスの提供を停止することなく、スキーマの構造の変更を進める必要がありました。 この記事では、サービスを停止せずにデータベースの構造を徐々に変更するデータベースリファクタリングをどのように進めたかについて紹介します。 「データベースリファクタリング」とは データベースリファクタリングについて体系的に述べた書籍として"Refactoring Databases"があります。この本では、データベースリファクタリングのさまざまなパターンにおいて、スキーマの変更、データマイグレーション（既存データの移行）、アプリケーションの変更それぞれをどのように進めるべきかについて解説しています。ここでは、"Refactoring Dat
こんにちは、インフラエンジニア の 加藤(@kuromitsu_ka)です。 この記事は Enigmo Advent Calendar 2021 の 24 日目の記事です。 今回は、オンプレミスのMySQLを、Auroraへ移行する際、困ったことと対応したことを記載します。 移行方式をざっくりいうと、オンプレミスのMySQLより取得した、論理バックアップ(mysqldump)とバイナリログを使用してAuroraへ移行しました。移行のため、リストア環境と、リストア後のデータのチェック環境を構築したので先にその説明を記載して、困ったところと対応を記載していきます。 リストア環境 オンプレミスMySQLサーバから取得した、バックアップファイルをAuroraへ適用する環境を作りました。EC2のMySQLと、Auroraとでレプリケーションを貼り、EC2のMySQLにデータを投入してリストアしました
いよいよ、昨年11月から、Amazon Aurora 8.0がリリースされ、8.0への移行の日が差し迫ってきました。 Spacelyでは、現在、Aurora MySQL5.7を利用していますが、8.0移行の前準備として、最近の最適化の仕組みを学びはじめました。 筆者が知っている時代よりも、最適化プロセス(オプティマイザの機能)がかなり高機能なものになっており、今まで思い込んでいた、勝手に作られるTemporary Tableが遅いとか、サブクエリが遅いとか、INよりEXISTSが早いとか・・・・・そういった固定観念を一気に拭うときがやってきたようです。インデックスが貼られていないと遅すぎてサーバーがマシンごとヒートアップする・・・というのも近い将来には見なくなる光景かもしれません・・・ 今回は、Optimizer関連の変数を確認しながら最適化について学びます。 MySQL初心者や忘れてしま
Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databasesを読む(その4 THE LOG MARCHES FORWARD) - CubicLouve
4 THE LOG MARCHES FORWARD ここでは、永続状態、実行状態、レプリカ状態で常に一貫しているように、データベースエンジンからどのようにログが生成されるかを説明する。(3つの状態があるってことか) 特に、コストが高い2PC(2 phase commit)のプロトコルを使わずに、効率的に一貫性を保つ実装方法を述べる。 (データ指向アプリケーションデザイン p 386あたりを参照する) まず、クラッシュリカバリー時におけるコストの高いredo処理を回避する方法を示す。 次に、通常の運用時と、実行状態とレプリカ状態の維持の方法を説明する。 最後に. リカバリー処理の詳細を示す。 補足の資料を用意してあります。 spring-mt.hatenablog.com 4.1 解決策の全体像 : 非同期処理 セクション3で説明したように、Auroraではデータベースをredoログストリー
MySQLでは、さまざまなアプローチでのクエリチューニングが存在します。WHERE条件のカラムにインデックスが存在しない場合にインデックスを追加するなど、簡単なチューニングでも大きな改善は見込めます。 今回は、LIMIT OFFSETにて問題になるクエリについて、以下の2つのチューニング方法を紹介します。 読み取り行数を減らすアプローチ 読み取りページ数を減らすアプローチ サンプルのテーブルとデータ、クエリを元に、具体例にて説明します。 前準備 以下のようなテーブルを用意します。 mysql> SHOW CREATE TABLE test\G Table: test Create Table: CREATE TABLE `test` ( `id` int NOT NULL AUTO_INCREMENT, `k` int NOT NULL DEFAULT '0', `c` text, PRI
INSERT...SELETC でauto_increment値が飛ぶ話 - amamanamam
環境 CREATE TABLE `t2` ( `id` int NOT NULL, `id2` int NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`), KEY `id2` (`id2`) ) mysql> select version(); +--------------+ | version() | +--------------+ | 8.0.28-debug | +--------------+ 1 row in set (0.00 sec) mysql> select @@auto_increment_increment; +----------------------------+ | @@auto_increment_increment | +----------------------------+ | 1 | +----------
概要 関わる機会があって必要だったのでメモ。 ただしこの操作については公式ドキュメントで、推奨していない操作であるため、本当はするべきではない。 mysql データベース内の MySQL システムテーブルを MyISAM から InnoDB テーブルに変換しないでください。これはサポートされていない操作です。これを行うと、mysql_install_db プログラムを使用してバックアップから古いシステムテーブルをリストアするか、再生成するまで、MySQL は再起動されません。 該当ドキュメント またこれを行う際にログをNFSマウントを使って共有するのはよくないことらしい。 NFS ボリューム上でデータファイルやログファイルが使用されるように InnoDB を構成することは、適切ではありません。それ以外の場合は、ファイルがほかのプロセスによってロックされ、MySQL で使用できなくなる可能性
今起きた事を話すMySQL5.6の timestamp型で、こんな感じの default指定のない timestamp型の create tableを書いた場合 create table xxxxx ( id bigint(20) unsigned auto_increment not null comment 'ID' , created_at timestamp comment '作成日時' , updated_at timestamp comment '更新日時' ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SQLBoilerのちょっとしたTips集
はじめに SQLBoilerは、スキーマに合わせたORMを生成するツールです。 READMEにも書かれていますが、意外と気づきづらい部分があったりするので、使い方から、ちょっとしたTips、ハマりポイントをまとめます。 少しでも参考になれば幸いです。 前提 MySQL SQLBoiler v4.16.1 生成したコードはmodelパッケージに配置されているとします テーブルは以下を想定 CREATE TABLE `teams` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `users` ( `id` int(11) NOT NULL AUTO_
多対一リレーションの設計手法によるパフォーマンスの違いを確認した - Mobile Factory Tech Blog
この記事はモバイルファクトリー Advent Calendar 2020 15日目の記事です。 エンジニアの yokoi0803 です。DB設計をしていて多対一のリレーションを見たり、設計したりする機会が何度かあって、その度にどう設計するかで悩んでます。 多対一のリレーションはいくつかの設計で実現できますが、その選定の際の指標を得るため、今回はパフォーマンスの観点から設計の比較をしてみたいと思います。 多対一のリレーションを表現する3つの設計 あるテーブルが複数のテーブルに対して多対一で紐付くケースについて、ここではくじ引きとその景品を表現するためのDB設計を想定します。 箱の中のくじそれぞれに景品が設定されており、景品には旅行券や果物など、様々な種類のものがあります。 こういった仕様の設計手法にはいくつか種類がありますが、今回は「ポリモーフィック関連」、「交差テーブルを用いた設計」、「親
はじめに 自分用にテーブルが断片化してるか否かを確認する方法を書いてみました。 もし他にこんなのあるよー、って話あれば教えてください。 SHOW TABLE STATUS Data_freeを見ると良い innodb_file_per_tableオプションが有効であるべき mysql> SHOW TABLE STATUS FROM test\G *************************** 1. row *************************** Name: t1 Engine: InnoDB Version: 10 Row_format: Dynamic Rows: 0 Avg_row_length: 0 Data_length: 98304 Max_data_length: 0 Index_length: 16384 Data_free: 0 Auto_incre
Reduce downtime with Amazon Aurora MySQL database restart time optimizations | Amazon Web Services
AWS Database Blog Reduce downtime with Amazon Aurora MySQL database restart time optimizations When using Amazon Aurora MySQL-Compatible Edition for operating your relational databases in the AWS cloud, one of the key requirements is to verify that it is highly available during planned and unplanned outages. As database administrators, you should perform occasional database maintenance. This can b
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外部キー制約が使えない場合のRailsの実装方法 - エニグモ開発者ブログ
https://blogs.oracle.com/mysql-jp/post/still-using-myisam-it-is-time-to-switch-to-innodb-jp
INSERT 1文だけでもデッドロックするという話 - ngyukiの日記
【MySQL】InnoDBのインデックス
Aurora の Blue/Green デプロイで少し遊んでみた - Qiita
InnoDB Clusterよ、お前は何者なんだ
NAND Flash から InnoDB にかけての話（仮）
Dockerを使ってLAMP開発環境を整えるまでの奮闘記 - Qiita
エラーから学ぶMySQL InnoDBのレコード長制限｜ 開発者ブログ ｜ 株式会社アイソルート
MySQL 8.0 の AUTO_INCREMENT について
第89回 MySQL ＆ PostgreSQLの2022年の主なニュース | gihyo.jp
今日は、話題になってたMySQLのバックアップ方法について比較してみたの日。 - 今日はなにの日。
InnoDB のフラグメンテーションがよくわからなかった
MySQL SQLパフォーマンス改善 -実行計画の確認ポイント-
第191回 MySQLでUPSERT処理を実現する | gihyo.jp
Prometheus の Exporter について | SIOS Tech. Lab
Balthazar – Text processing in the shell
サービスを停止せずにデータベースリファクタリングする - Pepabo Tech Portal
オンプレミスMySQLをAuroraへ移行する際に、困ったこととその対応 - エニグモ開発者ブログ
MySQL 5.7で学ぶMySQLの最適化 (環境設定とパラメータ理解) - spacelyのブログ
第200回 LIMIT OFFSETに関するMySQLクエリチューニング | gihyo.jp
MyISAM から InnoDB への移行の注意点 - Qiita
MySQL5.7のtimestamp型でInvalid default valueが出るエラーの対処メモ | 7me
【MySQL】テーブルの断片化を確認しよう - 41から始めました