[B! MySQL][DB] auientのブックマーク

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

auient 2023/12/12

リンク

Where狙いのキー、order by狙いのキー

11. I'm yoku0825 ● とある企業のDBA ● オラクれない ● ポスグれない ● マイエスキューエる ● 家に帰ると ● 嫁の夫 ● せがれの父 ● 馬鹿だからかわいいわけじゃなくて、かわいいイルカがたまたまバカだった 12. はじめに ● サンプルデータは MySQLのサンプルデータベース(worldデータベース)からインデックスを全て取っ払ったものです ● http://dev.mysql.com/doc/index-other.html ● コードはgithubに上げてあります ● https://github.com/yoku0825/yapc_2014 ● すごく…ウンコードです… 13. はじめに ● 原則、MySQLは1つのテーブルにつき同時に1 つのインデックスしか使いません ● Index mergeとかあるけどアレは例外だし狙ってやっても速くなる

auient 2022/11/05

リンク

MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス技術戦略部ブログ]

株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDB DB設計インデックスこんにちは、羽山です。今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な

auient 2022/09/18

リンク

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（ドラフト）: 単調増加であるタイムスタンプとラ

auient 2022/06/16

リンク

PlanetScaleとは何か、なぜ外部キー制約をサポートしていないのか

PlanetScaleとは PlanetScaleはMySQLのマネージドサービスです。内部の実装には元々YouTubeのために開発されたMySQLのクラスタリングシステムであるVitessが使用されています。 Vitessの開発に携わってらっしゃるSugu SougoumaraneさんがCTOとして在籍しており、スケーラブルなデータベースを構築するためのサービスとなっています。すでにSlack, Square, GitHubなどの企業で採用されているそうです。この記事ではPlanetScaleのどういった点が優れているのか、これまでMySQLが抱えていた問題点をどのように解決しているのかといったことをまとめます。その中でタイトルにもつけましたが、なぜ外部キー制約をサポートしていないのかといった点も交えて説明します。これまでのMySQLの問題点大量のレコードが存在するテーブルの

auient 2022/03/28

リンク

データベース設計の際に気をつけていること - 食べチョク開発者ブログ

皆さんこんにちは、エンジニアの西尾です。新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。データベースはシステムの土台です。土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。データベース設計には”これだ！”という正解はないと思っています。サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。その他もろもろの背景により、データベース設計の仕方も変わってきます。このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。アンチパターンと呼ばれるものも時と場合によっては正解になります。

auient 2020/06/16

リンク

MySQL のサブクエリって、ほんとに遅いの？ | DevelopersIO

こんにちは、みかみです。今日のクラスメソッドのAWSおみくじ、RDS（t1.micro）でしたー！（昨日は Aurora！＠＠ｖはじめに前職＠アプリ開発時、MySQL のクエリチューニングをさせていただく機会がありました。ユーザー入力のキーワードで全文検索 → 見つかったレコードを返すのですが、所要時間、約3分。。 Apache タイムアウトして画面真っ白。。。（泣きそうでした＞＜。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリの

auient 2017/06/04

mysql
db

リンク

MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ

こんにちは、サービス開発部の荒引 (@a_bicky) です。突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。次数を b とすると、

auient 2017/04/18

mysql
db

リンク

挿入と参照ロックに疲れ果てた俺たちは - ichirin2501's diary

なかったらINSERTしたいし、あるならロック取りたいやん? from ichirin2501 www.slideshare.net 出来事 @ichirin2501 とりあえず何も考えずこの前のロックの話をSlideshareにあげてくれ！！— 柴崎優季 (@shiba_yu36) 2015, 8月 22 はじめにこれは先日の社内勉強会で発表したもので、MySQLで特定の問題を解決したいときのノウハウ話です。特定の問題とは、アプリを書いてると「データがなかったINSERTしたい、あるなら排他ロックしつつ取得したい」という要望があったりします。例えば、あるユーザーアクションで初期値もパラメーターで渡されるケースで、データがないならそのままINSERT、既にデータがあるなら取得して状態に依存して更新処理を行いたい場合などです。見かけのロジックは単純に見えますが、MySQLでこれを実現しよう

auient 2015/08/23

mysql
DB

リンク

[Q&A]MySQL開発でやってしまいがちな致命的ミス | Yakst

Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。本発表はSQLアンチパターン著者のBill Karwinさんの発表です。オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている

auient 2014/08/11

mysql
db

リンク

MySQLを使ったアプリケーションを作るエンジニアが知るべきMySQLの内部構造とは？ | Yakst

MySQLを使ったアプリケーションを作るエンジニアが知るべきMySQLの内部構造について、データベースコンサルティング会社PalominoDBを経営するLaine Campbell氏による回答。MySQLを知るためには何をポイントに学習すればよいのかがよくわかる、DBAや開発者にとっても役立つ内容。 1. ストレージエンジンストレージエンジンと、永続性、ロック機構、トランザクション処理の振る舞いや分離レベルといったストレージエンジンの基礎となる動きについての理解なしに、MySQL自体やモデルデータのコードをいじるべきでない。それに加えて、InnoDBのクラスタ化されたプライマリキーや、MyISAMの全文検索インデックスのようなコア要素も、極めて重要な情報だ。 2. インデックスのコンセプト特に以下のような点について。カバリングインデックス連結インデックスインデックスを使ったソート

auient 2013/12/17

mysql
db

リンク

Devsの常識、DBAは非常識

1. MySQL Admin が見た Devs の常識、 DBA は非常識 2013/09/14 yoku0825@MyNA PHP Conference 2013 2. ＼こんにちは！／ ● yoku0825 ● とある企業の DBA ● MySQL 歴 5 年くらい ● オラクれない ● ポスグれない ● 嫁の夫 ● せがれの父 ● 日本 MySQL ユーザ会 (MyNA) のスベり担当 3. ＼しゃべること！／ ● 日常的に MySQL のソースコードに触れる変態 DBA がフツーの Devs に投げた愛のマサカリ集 ( のつもり ) ● ウチの開発言語は PHP > Java >> Ruby らしいです ● ウチでは DBA がサーバーの構築、 Devs が設計・テーブル構築・運営、 DBA はトラブルシュートや改善提案 ( 運用 ) 、というサイクルで回しています。

auient 2013/09/14

DB
mysql

リンク

/.Jに聞け：PostgreSQLとMySQL、それぞれの優位性は？ | スラド IT

フリーのデータベースとしてどちらも名高いPostgreSQLとMySQL。それぞれにはどのような優位性があるのか？という質問がQA@ITにて投げかけられている。確かに複数のDBに対応するORマッパーが普及する現在、どちらを選択するかで迷うことも多いだろう。回答でほぼ完璧な答えが記載されているような気もするが、/.J読者の皆様はどう思う？ちなみにタレコミ子はみんな使っているからという理由でMySQL派です。

auient 2012/09/17

リンク

MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記はてな支店

MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という

auient 2011/06/20