タグ

MySQLに関するsatoshieのブックマーク (177)

  • Amazon RDS ブルー/グリーンデプロイを利用してMySQLのアップグレードをした話 - Pepabo Tech Portal

    こんにちは。技術部プラットフォームグループのharukinです。 この記事では、私たちが提供するネットショップ作成・運用のためのECプラットフォーム「カラーミーショップ」のデータベースを、Amazon RDSのブルー/グリーンデプロイを利用し、MySQLのバージョン5.7.38から8.0.35へアップグレードした経験についてご紹介します。カラーミーショップにおいてはこれが初の試みでした。Amazon RDS固有のファーストタッチレイテンシーの解除方法や、ダウンタイム時間の計測についてもお伝えします。 Amazon RDSのブルー/グリーンデプロイを活用するメリットは、番環境に準ずるステージング環境を構築し事前検証が可能であることです。ステージング環境は約1分で番環境に昇格させることができ、昇格時に許容ダウンタイムを超えたり、レプリケーションやインスタンスの問題が生じた場合は、自動的にプ

    Amazon RDS ブルー/グリーンデプロイを利用してMySQLのアップグレードをした話 - Pepabo Tech Portal
  • クエリのパフォーマンスチューニングの第一歩。実行計画や統計情報について入門する

    SQL実行の流れ まずはSQLがどのような流れで実行されるのかを見ていきます。 SQL実行の流れは大まかに捉えると以下のようになります。 パーサ パーサでは、ユーザーから送信されたクエリを受け取り、その文法的な正確さを検証します。SQLクエリが正しくフォーマットされているか、必要な構文要素が全て含まれているかをチェックし、例えばFROM句で指定されたテーブルが存在するかどうかも確認します。 文法的なエラーがある場合、例えばカンマの欠落や存在しないテーブルの参照など、クエリはエラーとして返されます。 エラーがない場合は、クエリは「抽象構文木」というデータ構造に変換されます。これにより、データベースはクエリをより効率的に解析し、次の処理ステップに進めることができます。 オプティマイザ SQLクエリがパーサを通過した後、次にクエリの最適化を行うのが「オプティマイザ」です。オプティマイザの主な役割

    クエリのパフォーマンスチューニングの第一歩。実行計画や統計情報について入門する
  • MySQLのインデックスの貼っていいとき悪いときを原理から理解したいよ😭

    今回答えを出したい問いはこちら!! インデックスはどのような仕組みを以て、何を実現したいものなのか それを踏まえたとき、インデックスはどういう場合になぜ貼る方が良いのか。また、どういう場合になぜ貼らない方が良いのか 大体分かっているよって人はサヨナラって感じのおさらい記事だぜ!!!!それじゃいってみよー🎉 あと、おれは今回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

    MySQLのインデックスの貼っていいとき悪いときを原理から理解したいよ😭
  • スロークエリを改善したらECSの負荷が爆下がりした話(TypeORM)

    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等はなかったので

    スロークエリを改善したらECSの負荷が爆下がりした話(TypeORM)
  • Blue/Green デプロイを使用した、RDS MySQL/PostgreSQLのアップグレード

    TL;DR RDS の メジャーバージョンアップグレード を行なった PostgreSQL 11.6 -> 15.5 MySQL 5.7.44 -> 8.0.36 PostgreSQLAWS CDK を利用した、自前での手動切り替えをベースにした Blue/Green デプロイによるアップグレードを行なった MySQLAWS コンソールから AWSが提供している機能である RDS Blue/Green Deployments による MySQL のアップグレードを行なった nginx の ngx_http_proxy_module を活用してサービスのダウンタイムを防止した はじめに 初めまして。株式会社ジーニーの GENIEE CHAT開発チームのマネージャーを担当しています。 今回は、データベースのメジャーアップグレードを行った際の手順やポイントなどを書いていこうと思います

    Blue/Green デプロイを使用した、RDS MySQL/PostgreSQLのアップグレード
  • MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス

    はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン

    MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
  • MySQL 8.0 : クエリーキャッシュのサポート終了 | Yakst

    役に立つ場面もある一方、スケーラビリティー上問題があるとされてきたMySQLのクエリーキャッシュが、MySQL 8.0で廃止されることになる。その背景と理由。 免責事項 この記事はMorgan Tocker氏によるMySQL Server Blogの投稿「MySQL 8.0: Retiring Support for the Query Cache」(2017/5/30)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 Reneが昨日、ProxySQLのブログにこう書きました。 MySQLのクエリーキャッシュはパフォーマンスを改善するためにあるが、それは重大なスケーラビリティー上の問題を抱えていて、深刻なボトルネックに簡単になってしまいかねない。 これは、MySQLチーム内でも確かに長い間言われてきたことです。今日の記事の題に入る前に、少しイントロダクションを書かせて

    MySQL 8.0 : クエリーキャッシュのサポート終了 | Yakst
  • MySQL 8.0.15 の前後で変わった文字列と DATE 型の比較について - それが僕には楽しかったんです。

    はじめに 前提条件 謎現象を再現する 8.0.15 以下 8.0.16 以上 原理 文献 おわりに はじめに そういえば、最近この手の記事を書いてないし何ならインプットもしてない事を思い出し、今日雑にテストしてたらたまたまハマった面白い挙動があったのでまとめる。 久々に MySQL と格闘した。 前提条件 こんなテーブルを作っておく。 create table hoge(t DATE); insert into hoge(t) values("2020-01-01"); mysql> desc hoge; +-------+------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------+------+-----+---------+-------+

    MySQL 8.0.15 の前後で変わった文字列と DATE 型の比較について - それが僕には楽しかったんです。
  • SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita

    データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH

    SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
  • MySQL アンカンファレンスを開催したい - tom__bo’s Blog

    MySQL アンカンファレンス開催したい。というかします。 概要 最近のMySQLはバージョニング方針も変わって、周辺ツールを含めた機能追加も着々とされている一方で、MySQL関連のイベントは減ってしまったような気がします。 コロナ以降、イベントが少ない気がするのは残念に思いつつも、最近の私には社外で活動できる余力がなく、社内にMySQLのプロ、その他DBのプロがたくさんいるので、なんとなく満足してしまっていました。 ですが、MySQL Advent Calendar 2023でいろいろなブログを一気に読んでいて、社内の会話だけで満足するのはもったいない。2024年はMySQLコミュニティのイベントに参加していきたいと思っていました。 オフラインで集まることも以前ほど慎重にならなくて良いので、MySQL Casualを開催することもできます(手を上げれば誰でも開催できると思っていますし、私

    MySQL アンカンファレンスを開催したい - tom__bo’s Blog
  • MySQLでUUIDv4をプライマリキーにするとパフォーマンス問題が起きるのはなぜ?(N回目)

    はじめに こんにちは、令和トラベルでバックエンドエンジニアをしている飯沼です。 MySQLでは、UUID (v4)などのランダム性の高いIDをプライマリキーに設定すると、パフォーマンスが低下すると言われています。私自身もこの問題については認識しておりアンチパターンとして避けて来ましたが、イマイチ理由を理解できず何度も調べていたので自分の理解を整理しました。 ※ この記事は令和トラベルのTech LT会で共有した内容を記事にしたものです。社外の方にもご参加いただけるTech LT会は connpass にて告知しています。 UUIDをプライマリキーにするユースケース そもそもUUIDをプライマリキーにするユースケースはどのようなものがあるのでしょうか? いくつかの観点から考えてみます。 パフォーマンス観点 大量の同時書き込みが発生するような状況でauto incrementを利用してIDを発

    MySQLでUUIDv4をプライマリキーにするとパフォーマンス問題が起きるのはなぜ?(N回目)
  • MySQL 5.7 から 8.0 にしたらテストが激遅になった - Qiita

    この記事は、株式会社カオナビ Advent Calendar 2023 の3日目です。 はじめに 株式会社カオナビの高橋(@kunit)です。 今回は MySQL バージョンアップ(5.7 -> 8.0) で起きた問題とそれに対してどのように対処したのかを書いていこうと思います。 何が起きたのか MySQL 5.7 から 8.0 にバージョンアップをするにあたって、CI およびローカル環境でテストができるように MySQL 8.0 のイメージを作成し、それをつかって各機能の担当者にテストを開始してもらっていたのですが、以下のような事が起きました。 接続を MySQL 5.7 から 8.0 に切り替えただけでテストの時間が3倍くらいかかるようになった そこを変更するだけで3倍遅くなるってやばいぞということで報告してくれた担当者と同じテストを自分でも実施してみると再現性があり、それが以下のどの

    MySQL 5.7 から 8.0 にしたらテストが激遅になった - Qiita
  • C#でMySQLからSELECTした結果を取り出したい - Qiita

    C#は素人なのと、あとコードは再現なので不適切なコードになっている可能性が高いです。 おそらくもっといい解法があるはずですが、調べた限りではよくわかりませんでした。 課題 テーブルAからSELECTする、テーブルBからSELECTする、その後ふたつのデータを色々やって最後にテーブルCにインサートする、みたいなことがやりたかったわけですよ。 コード側で色々と処理を行う必要があるため、JOINやINSERT SELECTではなく一度コード側にデータを引き取るのが前提です。 問題 ベストプラクティスがわからない。 適切なサンプルコードが見付からない。 信頼できるドキュメントはMicrosoft公式くらいしかないわけですが、そこに載ってるサンプルコードはどうにも役に立ちません。 https://docs.microsoft.com/ja-jp/azure/mysql/connect-csharp

    C#でMySQLからSELECTした結果を取り出したい - Qiita
  • VB.NETで書いたMySQLアプリが突然動作不能に - 南無ちゃんのブログ    https://namva.net

    昨日、とある方から電話があり、私が書いたアプリが動作しなくなった(エラー終了する)というのです。Linux(Ubuntu)上でMySQLサーバーが動作しており、Windows10パソコンからMySQLサーバーにアクセスするというシステムで、Windows10側のアプリはVB.NET 2019で書いています。 今日、電話で詳しく状況を確認すると、Windows10パソコン側でMySQL Workbenchを使ってMySQLにアクセスすると正常にデータベース(テーブル)にアクセスできるというので、ネットワークを含めハードウェアは正常に動作しており、データベースも正常に動作しているようです。 電話では、これ以上のことは分からないと判断し、詳しい状況確認のために、岡山市内まで車を走らせました。VisualStudioを使ってVB.NETアプリを起動してみると、Character set 'utf8

    VB.NETで書いたMySQLアプリが突然動作不能に - 南無ちゃんのブログ    https://namva.net
  • 【MySQL】 そうだ インデックス、使おう。 - Qiita

    2019.07.24 原則はカーディナリティの高いものから貼っていく を追記しました。 2019.07.24 実際のMySQLはB+tree構造を採用している を追記しました。 はじめに @hk206です。 最近になって初めてインデックスなるものを使い始めました。 これによってレコード検索が爆速になります。MAJIDE。 今まではしょぼい数のレコードのテーブルしか触ったことがありませんでしたが、 数百万、数千万のレコードを色々いじる機会がありまして...... 処理速度やばない?ってふと気になり、インデックスを使用してみました。 インデックスとはなんぞやってところからB-tree構造まで、広ーーーく浅く調べたのでまとめてみました。 知ってるよーって方も復習になればいいかなと。 インデックスとは インデックスは特定のカラムの、あるレコードをすばやく見つけるために使用されるものです。検索が爆速

    【MySQL】 そうだ インデックス、使おう。 - Qiita
  • Laravelのマイグレーションではtimestamp型のchangeが出来ない - Qiita

    エラー内容 Laravelのマイグレーションでtimestamp型のカラムに変更を加えようとすると以下のようなエラーが出る。 Unknown column type "timestamp" requested. Any Doctrine type that you use has to be registered with \ Doctrine\DBAL\Types\Type::addType(). You can get a list of all the known types with \Doctrine\DBAL\Ty pes\Type::getTypesMap(). If this error occurs during database introspection then you might have forgo tten to register all database t

    Laravelのマイグレーションではtimestamp型のchangeが出来ない - Qiita
  • Aurora MySQL version 3でTempTable溢れの振り返り

    9/11に開催された、【Chatwork × みてね勉強会】EKS&Aurora最新ノウハウでお話させていただいた、みてねSREの伊東の登壇資料です。

    Aurora MySQL version 3でTempTable溢れの振り返り
  • ridgepoleの紹介 - Qiita

    この記事は、UUUM Advent Calendar 2018 9日目です。 UUUMシステムユニットに入社して6ヶ月、赤根谷です。 今回は弊社で使っているridgepoleというgemの紹介をしたいと思います。 (先月に弊社のはてなブログで公開した内容とほぼ一致してしまうのですが、読んだという方はあまり多くないと思うので再利用してしまいたいと思います。) ブログとの大きな差分だけを読みたい方は 「弊社ブログ記事に追記」の箇所だけお読みください。バグをコミットして修正したよ、という話です。 それ以外の方は上から順番にどうぞ。 はじめに 弊社ではRailsを利用したプロジェクトが多いです。そして一部でマイングレーションツールとしてridgepoleというrubyのライブラリ(gem)を使っております。弊社で開発しているわけではありませんが、今回はそのgemの紹介です。 環境 なお弊社ではru

    ridgepoleの紹介 - Qiita
  • Laravelで"could not find driver"が出たときの対処法 - Qiita

    LaravelからMySQLに接続する 環境情報 ・PHP 7.1.23 ・CentOS Linux release 7.4.1708 (Core) ・MySQL 5.6.39 "could not find driver"が私を襲う 背景 元々sqliteで環境を作っていたが、あまりにサーバの動作が安定しないためMySQLにすることにした。 これが悲しみの正体である 良く書かれているようなコマンドは叩いた。

    Laravelで"could not find driver"が出たときの対処法 - Qiita
  • MySQLとOracleの実行計画を比較してみた - ASMのきもち

    まいえすきゅーえりたい ぽすぐれない おらくるってる(狂ってる)tomoです。 今日はいつものMySQLリファレンスを読むではなく、夏休みの宿題にしていたこれをやってみます。 MySQLOracleDBの実行計画を比較してみた さて同じようなテーブルで同じデータを載せて。 実行計画を取ってみた時、どのくらい情報量が違うのか簡単に違いを見てみましょう。 前提として、以下をご認識ください。 一方はOSSのDBエンジン、もう一方はガチガチ商用DBエンジンです。情報量が違うのは当たり前であって、良し悪しを比較したいのではありません。そして製品比較をしたいのではありません。いつも商用DBメインで使っているエンジニアが、OSSのDBにこうゆう情報も出してほしいな!というのをお願いしたいと思っていて、それを考える元ネタメモだと思ってください。 OSSでこれだけの情報出せるMySQLや、今回紹介しません

    MySQLとOracleの実行計画を比較してみた - ASMのきもち