タグ

mysqlに関するouestのブックマーク (267)

  • アップグレードしたいとき見るべきドキュメントは? - 41から始めました

    この記事はMySQL Advent Calendar 2023 25日目の記事です。 はじめに 1.どのバージョンにアップグレードするのか決める アップグレードパス ※アップグレード先のバージョンとOSのコンパチを確認する 2.新機能・追加・非推奨・削除された機能を確認する。 ドキュメントには無いけど… 3.レプリケーションを使用している場合 4.OSごとにアップグレード手順を確認→手順書作成 論理アップグレードとインプレースアップグレード 4-1.論理アップグレードの方法 インストール バックアップとリストア mysqldump MySQL Shellのダンプロードユーティリティ mysqlpump 4-2.OSごとのアップグレード方法(論理以外) Unix/LinuxWindows その他のアップグレード 4-3.MySQL Serverが8.0.15以前はmysql_upgrad

    アップグレードしたいとき見るべきドキュメントは? - 41から始めました
  • 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
  • ぼくたちはMySQL 8.1とどう生きるか

    2023/08/28 MySQL Innovation Day Tokyo 2023 https://www.oracle.com/jp/events/mysql-day/

    ぼくたちはMySQL 8.1とどう生きるか
    ouest
    ouest 2023/09/03
    8.0.34 と 8.1.0 は兄弟
  • Percona Playback で 本番 MySQLに流れているクエリを試験環境でリプレイする - mita2 database life

    データベースのバージョンアップの際、アプリケーションの網羅的なテストが可能であれば良いのですが、どうしても難しいケースがあります。 そのような場合、リプレイツールで番環境に流れているクエリを、試験環境でリプレイ(再現)し、動作確認を取る方法もあります。 リプレイツールを探す MySQL の クエリ リプレイができるツールを探してみました。 Percona Tookit に pt-log-player というツールが含まれていたのですが、いつのまにか、なくなってました。。。 2013年にリリースされた、percona tookit 2.2 で削除されてしまったようです。 We removed pt-query-advisor, pt-tcp-model, pt-trend, and pt-log-player. Granted, no tool is ever really gone: i

    Percona Playback で 本番 MySQLに流れているクエリを試験環境でリプレイする - mita2 database life
  • varcharとtextの違い(mysql innodb) - lxyuma BLOG

    mysqlの可変長文字列を扱う、varchar型とtext型の違いの話。 古い情報が混在していたので、ちょっと整理してメモ。 myisamの頃の話 sizeが違う 行の中身がdataか(varchar)、dataへのポインタか(text) 参照挟むので、performanceの違いがあった(varcharが早い) 今 net でぐぐって、ひっかかる情報の大半がこの話。 最近のinnodbの話 最大sizeは一緒。64kb(但し、TINYTEXT型、MEDIUMTEXT型、LONGTEXT型は名前の通り違う) varcharもtextも、中身は同じ仕組み(BLOB field / off page column) 行にdata入れるのも、外部(overflow page)への参照にするのも、行フォーマット次第(row format) 5.6で行formatのdefault は COMPACT

    varcharとtextの違い(mysql innodb) - lxyuma BLOG
  • MySQLとOracleの実行計画を比較してみた - ASMのきもち

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

    MySQLとOracleの実行計画を比較してみた - ASMのきもち
  • Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話

    こんにちは。 KINTO テクノロジーズの DBRE チーム所属のp2skです。 DBRE(Database Reliability Engineering)チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち(@_awache)による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を是非ご覧ください。 今回の記事は、データベースに関する課題解決の事例として「Aurora MySQL でレコードが存在するのに

    ouest
    ouest 2023/05/22
    MySQLクライアントのバージョンかぁ
  • Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ

    この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ

    Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ
    ouest
    ouest 2023/01/05
    インデックスは効果あるのか...
  • どのようなケースでインデックスマージが利用されるのか検証する - Mobile Factory Tech Blog

    この記事はモバイルファクトリー Advent Calendar 2020 8日目の記事です。 はじめに こんにちは、エンジニアの id:mp0liiu です。 MySQLでは基的にクエリを実行する際インデックスは1つしか効きませんが、インデックスマージという仕組みによって複数のインデックスを使った検索結果をマージし、その和集合や共通集合を効率よく取得できる場合があります。 とはいっても具体的にどのようなケースでインデックスマージが利用されるのかわかっていなかったので、MySQLの公式ドキュメントを見つつ実際にテーブルを作って検証してみました。 記事では検証した結果を基にインデックスマージが利用される具体的なケースをいくつか紹介します。 検証に使った環境は以下の通りです。 Ubuntu 18.04 MySQL 5.7.32 事前準備 まず検索対象のテーブルを作ります。 CREATE TA

    どのようなケースでインデックスマージが利用されるのか検証する - Mobile Factory Tech Blog
  • ローカル開発環境でMySQL5.7を使っているときにtable_open_cacheを少なくすると、なぜLost connection to MySQL serverが起きなくなるか - $shibayu36->blog;

    最近ローカル環境でMySQL 5.7 + Railsの開発をしていると、たまにMysql2::Error: Lost connection to MySQL server at 'reading initial communication packet'というエラーが出て困っていた。これについては、mac osx におけるファイルディスクリプタの上限 | ++頭道++を見ると、table_open_cache=400と設定することで起きなくなるとされている。 ただ、いまいちその原理が分かってなかったので軽く調査してみた。この辺りについては自分は詳しくないので、正確性の保証はできない。 なぜLost connection to MySQL serverのエラーが起きるのか tail -1000 /opt/homebrew/var/mysql/$(hostname).err | grep Wa

    ローカル開発環境でMySQL5.7を使っているときにtable_open_cacheを少なくすると、なぜLost connection to MySQL serverが起きなくなるか - $shibayu36->blog;
  • MySQLからPostgreSQLに移行する際のTips - そーだいなるらくがき帳

    このエントリーは Classi developers Advent Calendar 2022の18日目。 ネタはなんでもいいよ!とのことなので、Claasiに全く関係なく、MysqlからPostgreSQLに移行する際の注意点を書く。 なお、まだRDSにPostgreSQLがなかった頃のような昔の記事だがこちらに無いことを書いていく。 soudai1025.blogspot.com soudai1025.blogspot.com MySQL から PostgreSQLにデータ移行する際の注意点 MySQLとPostgreSQLは互換性がもちろんありませんので、細かいところで違いが発生します。 よく踏むデータ移行の注意点は以下の通り。 timestampやdatetimeを移行する先はtimestamp型になるが、timestamp型はタイムゾーン付きと無しがある timestamp wi

    MySQLからPostgreSQLに移行する際のTips - そーだいなるらくがき帳
  • WHERE 条件のフィールドを UPDATE するのって,明示的にロックしてなくても安全?全パターン調べてみました! - Qiita

    WHERE 条件のフィールドを UPDATE するのって,明示的にロックしてなくても安全?全パターン調べてみました!MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも, MVCC アーキテクチャの恩恵で, SELECT と UPDATE は基的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ,排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ,これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で,更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離

    WHERE 条件のフィールドを UPDATE するのって,明示的にロックしてなくても安全?全パターン調べてみました! - Qiita
  • MySQLで発生し得る思わぬデッドロックと対応方法

    はじめに この記事は実際の業務で発生した MySQL のデッドロックとそのいくつかの回避方法や対応方法を(テーマは変えて)手元で実行できるコードを用いて解説する記事です。具体的には「トランザクション張っておけば大丈夫」と思ってませんか? バグの温床になる、よくある実装パターンの記事で紹介されている「1on1 チャットサービス」で紹介されているデッドロックとデータベースレイヤでは同じ状況だったのですが、記事で紹介されている方法とは別の方法でデッドロックを回避する必要があったため、同じ状況に遭遇した人の助けになればという思いで記事を書きました。また、こちらの記事が無ければ私自身も現象を理解するのにもっと苦労したと思うので、この場を借りてお礼申し上げます! 出金サービス履歴登録サービスを例に考える コードと説明が https://github.com/shuntagami/withdrawal_

    MySQLで発生し得る思わぬデッドロックと対応方法
  • 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(ドラフト): 単調増加であるタイムスタンプとラ

    Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
  • 第158回 Invisible Columnsの使いどころ | gihyo.jp

    MySQL 8.0.23では、新たな機能としてInvisible Columnsが導入されました。この機能は、あるカラムを「存在はしているけれども明示的に指定しない場合は参照しないカラムとして扱う」ことができるようになっています。今回はこのInvisible Columnsの機能について見ていきましょう。 なお、似た機能である、invisible indexesについては第110回 Invisible Indexesを使って気軽にチューニングを始めてみるで紹介しておりますのでそちらをご参照ください。また、今回利用しているMySQLのバージョンは8.0.26となります。 Invisible columnsのあるテーブルの作成 Invisibleなカラムのあるテーブルを作成するには、InvisibleにしたいカラムにINVISIBLEをつけてCREATE TABLE文で実行するか、ALTER

    第158回 Invisible Columnsの使いどころ | gihyo.jp
    ouest
    ouest 2022/02/04
    Invisible Columns
  • MySQLのibdataから個別のテーブルデータをリストアする

    2018-12-03 in MySQLバックアップは取っていてもリストアできないと宝の持ち腐れですね。 ibdataのコールドバックアップは取っていて、サクッと一部のテーブルのデータのみリストアする方法です。 稼働中のMySQLを止める必要がないので、一部のテーブルだけ復旧したい場合や、とりあえず昔のテーブルの状況を見たい場合などに利用可能です。 データベース全体のリストアではないので、リストアの時間を短縮したいときに使えるかと思います。 やり方としては公式のドキュメントに書いてある通りなのですが、もうちょっと細かくやり方を見ていきます。 innodb_file_per_tableがONになっていて、テーブル毎にibdataが作成されていることが前提になります。 大まかな手順は下記のようになります。 復旧したいデータベース・テーブルがない場合はあらかじめ作成しておく該当テーブルへの変更をL

    ouest
    ouest 2022/02/04
    ibd ファイルからのリストア。大量にデータがある場合は、データを入れ直すより早いので、サーバー移行時なども使えるのではないかと思っている。
  • 受取期限の過ぎたデータをMySQL上から削除する話 | GREE Engineering

    こんにちわ。せじまです。今回は地味で泥臭い話をします。ただ、割と平易な内容かと思いますので、初学者の方にもオススメです。 はじめに ゲームでは、受取期限のついたログインボーナス的なものがよくあります。ユーザが期限までに受け取らないと、ユーザからそのデータは不可視になりますが、必ずしも、不可視になった瞬間にデータベースから直ちに削除される、というわけでもありません。バッチジョブか何かで、ガベージコレクションのように削除するケースが多いのではないでしょうか。 また、論理削除という概念もあります。論理削除についてはいろいろ意見や考え方があるかと思いますので、ここでそれについては論じませんが、「削除フラグが立ってユーザから不可視になった後、三ヶ月以上経過したデータを削除したい」みたいなことは、ゲームに限らず、しばしばあるんじゃないかなと思います。 こういった、ユーザから不可視になってしばらく経過し

    受取期限の過ぎたデータをMySQL上から削除する話 | GREE Engineering
    ouest
    ouest 2022/01/12
    DELETE 時にセカンダリインデックスを使用するとロック競合する場合があるので、プライマリキーで DELETE する
  • MySQLとインデックスと私

    2021/05/24 サイボウズ開運研修 動画が以下のサイトからリンクされています - https://blog.cybozu.io/entry/2021/07/20/100000 - これに矢印を書きながらぐりぐりやっていたわけなので、資料単体だとわかりづらいと思います…

    MySQLとインデックスと私
    ouest
    ouest 2021/07/30
    ネクストキーロックをすごく理解できる
  • MySQL Parameters

    MySQL Parameters Version: Difference only Include plugins

    ouest
    ouest 2021/06/11
    いろんなバージョンの変数などを比較確認できる
  • MySQL 8.0 への移行が完了しました ~さようなら全ての MySQL 5.7~ - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo

    MySQL 8.0 への移行が完了しました ~さようなら全ての MySQL 5.7~ - Cybozu Inside Out | サイボウズエンジニアのブログ