並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 29 件 / 29件

新着順 人気順

innodbの検索結果1 - 29 件 / 29件

  • MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

    MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全11回のシリーズで解説します! 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第10回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 1回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください! ★ 第1回 トランザクション分離レベル ★ 第2回 ロ

      MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
    • explainだけじゃわからない!MySQLのindexの考え方 - BASEプロダクトチームブログ

      はじめに こんにちは、バックエンドエンジニアのSakiです!バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL(InnoDB)についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しや

        explainだけじゃわからない!MySQLのindexの考え方 - BASEプロダクトチームブログ
      • RDBの主キー、UUID使った方がいいの?(DDD, CleanArchitecture対応)

        結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは? MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd

          RDBの主キー、UUID使った方がいいの?(DDD, CleanArchitecture対応)
        • Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 | Amazon Web Services

          Amazon Web Services ブログ Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 本記事は、Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1 を翻訳したものです。 Amazon Aurora MySQL 互換エディション バージョン 2 (MySQL 5.7 互換)は 2024 年 10 月 31 日に標準サポートの終了が予定されています。Amazon Aurora MySQL バージョン 2 の標準サポートの終了タイムラインについて

            Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 | Amazon Web Services
          • MySQL/Aurora/TiDBロック入門 – 第2回ロックモニターの読み方【動画解説付】|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

            MySQL/Aurora/TiDBロック入門 – 第2回ロックモニターの読み方【動画解説付】 MySQL とその互換 DB のロックやトランザクションの挙動を紹介する入門シリーズ、「第1回 トランザクション分離レベル」 では READ COMMITTED や REPEATABLE READ でどういう挙動になるか紹介しました。 第2回目の今回は MySQL InnoDB のロックモニターの読み方、使い方について解説します。MySQL のロック機構を理解するツールとして便利なのでぜひご一読ください! ★ 第1回 トランザクション分離レベル ★ 第2回 ロックモニターの読み方 ★ 第3回 ロック読み取り、共有ロックと排他ロック ★ 第4回 インテンションロック ★ 第5回 レコードロック ★ 第6回 ギャップロック ★ 第7回 ネクストキーロックと降順インデックス ★ 第8回 共有ロックで発生

              MySQL/Aurora/TiDBロック入門 – 第2回ロックモニターの読み方【動画解説付】|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
            • [Software Design連動企画] 実践クエリチューニング | gihyo.jp

              この記事は、『Software Design 2024年6月号』(2024年5月17日発売)の第1特集「SQLチューニングする前に知っておきたい 実行計画&インデックスのしくみ」の連動企画です。ぜひ本誌特集1もお読みください。 適切なインデックスを設計する インデックスの調整によるクエリの高速化は、RDBMSを使用する際の数あるチューニングテクニックの中でも最もお手軽なものです。テーブルのカラムの定義を変えるわけではないので、クエリの結果に違いが生じず、アプリケーションを変更する必要性がないからです。適切なインデックスを付与するだけでチューニングが済むというのは極めて効率的です。それでは適切なインデックスとはどのようなものでしょうか。本記事では、まずインデックスを設計する際に重要なポイントを解説します。 インデックスとSQL構文 「どのカラムの組み合わせに対してインデックスを作成すべきか」

                [Software Design連動企画] 実践クエリチューニング | gihyo.jp
              • Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート2 | Amazon Web Services

                Amazon Web Services ブログ Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート2 本記事は、Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 2 を翻訳したものです。 最初のパートでは、 Amazon Aurora MySQL互換エディション v2 から v3 へのアップグレードの事前チェックが失敗する原因となる最も一般的な問題を説明しました。この投稿ではアップグレードが長引いて失敗する最も一般的な原因について説明します。 クラスターにプリ

                  Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート2 | Amazon Web Services
                • 私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT【イベントレポート】 - Findy Tools

                  公開日 2024/05/24更新日 2024/05/24私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT【イベントレポート】 近年データベースが急速に進化し、開発にも大きな影響を与えています。そこでファインディでは「私たちはなぜNewSQLを使うのか TiDBを選定・導入した5社が語る選定と活用」と題したイベントを開催。PingCAPの日下さん、LINEヤフーの佐伯さん、アイスタイルの鈴木さん、DMM .comのpospomeさん、コロプラの曽我さん、さくらインターネットの江草さんをお招きし、NewSQLの一つである TiDBについて語っていただきました。 ■パネリスト 日下 太智さん / @ksk_tic PingCAP株式会社 プロダクトマネージャー / シニアソリューションアーキテクト SIerにて国内外問わずEC/小売/製造/サービス/メディア/出版など様

                    私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT【イベントレポート】 - Findy Tools
                  • Binary logging optimizations in Amazon Aurora MySQL version 3 | Amazon Web Services

                    AWS Database Blog Binary logging optimizations in Amazon Aurora MySQL version 3 The binary log (binlog) in MySQL is used to capture database modifications on a MySQL server in a logical format known as “events”. These database modifications can include DCL statements (such as CREATE USER or GRANT), DDL statements (CREATE TABLE, ALTER TABLE) and DML statements (INSERT, UPDATE, DELETE). When such a

                      Binary logging optimizations in Amazon Aurora MySQL version 3 | Amazon Web Services
                    • Amazon Aurora MySQL3におけるバイナリログの最適化 | Amazon Web Services

                      Amazon Web Services ブログ Amazon Aurora MySQL3におけるバイナリログの最適化 本記事は、2024年5月17日に公開された Binary logging optimizations in Amazon Aurora MySQL version 3 を翻訳したものです。 MySQLのバイナリログ(binlog)は、MySQLサーバ上のデータベースの変更を”イベント”と呼ばれる論理フォーマットでキャプチャするために使用されます。これらのデータベース変更には、DCL(CREATE USERやGRANTなど)、DDL(CREATE TABLE、ALTER TABLEなど)、DML(INSERT、UPDATE、DELETEなど)が含まれます。そのような変更がMySQLでコミットされると、サーバは 2-phase commit(2PC)を用いてトランザクションのバ

                        Amazon Aurora MySQL3におけるバイナリログの最適化 | Amazon Web Services
                      • 2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx

                        MySQL クラウド向け InnoDB チューニング。仮想サーバーで使う場合のチューニングのポイントを解説しました。DB TECH SHOWCASE SAPPORO 2015 での発表資料です。

                          2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
                        • 2PC between Binlog and InnoDB

                          Exploring the Power of Turbo Streams & Action Cable | RailsConf2023

                            2PC between Binlog and InnoDB
                          • PostgreSQLでのトランザクション分離レベルの使い分けを考えた - やる気がストロングZERO

                            標準としてのトランザクション分離レベルは一応把握してたけど、MySQLやPostgreSQLとか、実装によって結構事情が異なっててそのあたりあまり理解できてなかったのでPostgreSQLにおいてのトランザクション分離レベルを学び直した。 ※参考にしたのはこのあたり postgeSQLのトランザクション分離レベルについて www.postgresql.jp www.postgresqlinternals.org トランザクションで発生する問題(ダーティーリードやファントムリードの具体的なサンプルなど) postd.cc 結論「どういう時にどうすればいいか?」 「基本的にはデフォルト(read committed)指定で良い」について 「不整合が起こる可能性がある場合にrepeatable readを明示的に指定する」について 「repeatable readを明示的に指定する場合、クエリ実

                              PostgreSQLでのトランザクション分離レベルの使い分けを考えた - やる気がストロングZERO
                            • mysql の CHECKSUM TABLE が 自動テストのDBロールバックする時に便利だった - Qiita

                              はじめに 去年は、言語バージョンアップにおけるE2Eテストの考え方とアプローチ方法についてを書きました。 今回は、「DBの差分とロールバック」 に関して書きたいと思います。 DB Diff を実際に使ってみた結果 前回の記事では、「DB Diff」というツールを使うことで、比較とロールバックを自動で行うことができると書いていました。 ★E2Eで検証するデータ種類によって比較方法 新規登録で同じデータが登録される。 → 「どのテーブルに変更が加わったのか?」は DBデータファイルの更新日時等から自動取得させる。 → 登録されたDBデータの差分の比較。( DB Diff ) → 比較後にテスト実行前の状態に戻す( DB Diff ) とある問題が発生し、本格的な導入を断念することにしました。 レコードが多いテーブルの比較を行う場合に時間がかかり、テスト実行後のデータロールバックに時間がかかりす

                                mysql の CHECKSUM TABLE が 自動テストのDBロールバックする時に便利だった - Qiita
                              • Cloud SQL Enterprise Plusのメンテナンスはどのように実現されているか

                                はじめに Cloud SQLにはEnterprise Plusというエディションがあります。その特徴の1つとして計画メンテナンス時のダウンタイムの短さがあります。本稿ではこのメンテナンス時間の短縮がどのような仕組みで実現されているかを解説します。マニュアルなどではこのメンテナンスの方式のことを「ダウンタイムがほぼゼロの計画的メンテナンス(Near-zero downtime planned maintenance)」と呼んでいます。そのままでは少々長いので本稿では以降、ニアゼロダウンタイムと記載します。 Cloud SQL Enterprise Plusを使うだけであればメンテナンス時の利用できない時間が短いのだなという理解でも十分です。その中で実際に何が行われているか興味がある方のための解説です。 ニアゼロダウンタイムの仕組み詳細 これ以降の説明はCloud SQL Enterprise

                                  Cloud SQL Enterprise Plusのメンテナンスはどのように実現されているか
                                • Railsアプリの処理を100倍以上に高速化して得られた知見 | Recruit Tech Blog

                                  はじめまして。2019年4月から妊娠・出産アプリ『Babyプラス』の開発チームにJOINした濱田です。 『Babyプラス』のバックエンドはRailsで実装されているのですが、とあるCSV生成処理がとても遅かったので100倍以上に高速化しました。この過程でRailsアプリの処理高速化に関する以下の知見が得られたので、具体例を交えて共有します。この知見は、ActiveRecordを使用してMySQLなどのRDBMSからデータ抽出をする様々な場面で活用できると思います。 いわゆる「N+1問題」を起こさないのは基本 「ActiveRecordインスタンスの生成コスト」はそれなりに高い pluckはjoinsと組み合わせることで他テーブルのカラム値も取得できる 前提: DBスキーマとデータ規模 今回の処理高速化に関わるモデルのDBスキーマとデータ規模は以下の通りです。なお、これらは本エントリ向けに少

                                    Railsアプリの処理を100倍以上に高速化して得られた知見 | Recruit Tech Blog
                                  • Percona XtraBackup REDOログのアーカイブ機能について | スマートスタイル TECH BLOG

                                    はじめに MySQL8.0.17 新機能紹介:Redo ログのアーカイブについて – スマートスタイル技術ブログ ただし、現時点でこの機能に対応しているのは MySQL Enterprise Backup のみであるため、Percona XtraBackup や MariaDB Enterprise Backup ではまだ使用することができない点には注意してください。 既に弊社ブログでMySQL8.0.17の新機能、REDOログのアーカイブについては紹介したところではありますが、Percona XtraBackupが対応しましたので、そちらの方を紹介する記事になります。また、Percona XtraBackup 8.0.34-29で追加された–-redo-log-arch-dirオプションについても紹介させていただきます。 以下、Percona XtraBackup公式ドキュメントを参考に

                                      Percona XtraBackup REDOログのアーカイブ機能について | スマートスタイル TECH BLOG
                                    • XAMPPでのinnodb_strict_mode=OFF設定 - Qiita

                                      レンタルサーバーもPHPが7.3が当たり前になってきてくれたのでXAMPPを新しくしたらDBに不具合が出たのでちょっと調べた記録。 XAMPP 10.4.8-MariaDB あれこれ文句を言われているXAMPPですが、Windows環境で使ってる分には大変気楽に設定(もほぼ必要無いけど)出来て良い物です。 ですが今回少し古いMySQLからのmysqldumpでのバックアップがXAMPP環境で戻せなかった(エラーが出た)ので解決しました。 エラーの内容は・・・ ERROR 1118 (42000) at line 657: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inl

                                        XAMPPでのinnodb_strict_mode=OFF設定 - Qiita
                                      • RDBのインデックスアンチパターンとB-tree入門 | 株式会社CAM

                                        |はじめに こちらは CAM advent calendar 2023 の 5日目の記事です。 こんにちは、普段CAMでバックエンドの開発を担当しているHiraと申します。 この記事では、リレーショナルデータベースにおけるインデックスのアンチパターンを、その根幹であるB-treeの概念から深掘りして理解していきます。 |目次 ・ B-treeとは ・ 基礎知識 -B-treeインデックスの構造 ・ 値と参照の保存 ・ インデックスを用いたアンチパターン -インデックスショットガン -カーディナリティが低いカラムに対してインデックスを貼る -複合インデックスにおけるアンチパターン ・ まとめ |B-treeとは B-treeは、1970年に考案されたデータ構造で、多くのリレーショナルデータベースのインデックスに採用されています。(参考: https://dl.acm.org/doi/10.1

                                          RDBのインデックスアンチパターンとB-tree入門 | 株式会社CAM
                                        • MySQL5.7→8.0へ向けて Amazon Aurora のブルー/グリーンデプロイの素振りをしたので備忘録を残す|背番号8

                                          どうも、背番号8です。 現在、Funds のデータベースは Amazon Aurora 上で稼働しておりますが エンジンが MySQL5.7 となっておりまして、いい加減 MySQL8.0 へ上げましょうよ、というので着々と準備を進めております。 バージョン移行に際しては Amazon Aurora のブルー/グリーンデプロイを利用する方向で動いており、検証のために素振りを行ったので備忘録を残そうと思います。 MySQL5.7を利用していることのリスク改めてお話することでもないですが MySQL5.7 はすでに公式サポートが終了(EOL)しており、控えめに言っても見逃せる状況ではありません。 MySQL5.7を利用していることのリスク 影響調査と対応もたもたせずにササッと上げてしまいたいところですがメジャーバージョンのアップグレードには破壊的変更を含むのが世の常です。 これに対しては、公式

                                            MySQL5.7→8.0へ向けて Amazon Aurora のブルー/グリーンデプロイの素振りをしたので備忘録を残す|背番号8
                                          • MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

                                            MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全11回のシリーズで解説します! 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第10回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 1回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください! ★ 第1回 トランザクション分離レベル ★ 第2回 ロ

                                              MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
                                            • MySQLデータを復活させる方法 - Qiita

                                              こんにちは。 CYBIRD Advent Calendar 2022 16日目担当の @utamakura です。 サイバードに入社して6年目になる、サーバ寄りのエンジニアです。 普段はモバイルゲーム・Webサービス開発をメインで行っていて、兼務で社内運用ツール開発、DBA業務も行っています。 15日目は @kanacha さんによる『unity1week「そろえる」の参加記録』でした。 プカプカ浮かぶアヒルがかわいいです。実際にゲームをプレイできますので、そちらも是非ご覧ください! はじめに モバイルゲームやWebサービスでは、データベースのユーザデータ、ログデータの保持は最重要課題です。 ユーザデータ、ログデータが万一にも消去されない為にも、セキュリティ対策を徹底したり、チーム運用ルールを制定したり、データベースストレージのRAID構成を選択したり、定期的に外部領域にバックアップを保存

                                                MySQLデータを復活させる方法 - Qiita
                                              • MySQLパフォーマンス向上のためのプロビジョニングIOPSの活用とその結果 - ENECHANGE Developer Blog

                                                概要 最近、最新のアクションカメラを購入してYoutube用に動画編集してるCTO室のKazです 今回、MySQLのマイグレーション時、Index有効クエリを高速化するため、ボトルネックを特定してそれを解消しました。 結果 Index有効化において 適切なメモリ量を確保し、MySQL Workbenchのパフォーマンスレポートを確認することで、システムのボトルネックを特定しました。その結果、プロビジョニングIOPSを利用することにより、特に時間を要していたテーブルのインデックス有効化の時間を大幅に短縮し、システム全体の効率化を図ることができました。 インデックス有効化の実行時間の比較 項目 時間 プロビジョニングIOPS利用前 約178.94分 プロビジョニングIOPS利用後 約74.3分 時間の短縮量 約104.64分 短縮率 約58.5% Import先DB 項目 詳細 インスタンスク

                                                  MySQLパフォーマンス向上のためのプロビジョニングIOPSの活用とその結果 - ENECHANGE Developer Blog
                                                • MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.6.5 redo ログ

                                                  redo ログは、不完全なトランザクションによって書き込まれたデータを修正するためにクラッシュリカバリ中に使用されるディスクベースのデータ構造です。 通常の操作中、redo ログは、SQL ステートメントまたは低レベルの API コールによって発生したテーブルデータを変更するリクエストをエンコードします。 予期しないシャットダウンの前にデータファイルの更新を終了しなかった変更は、初期化中、および接続が受け入れられる前に自動的にリプレイされます。 クラッシュリカバリにおける redo ログの役割の詳細は、セクション15.18.2「InnoDB のリカバリ」 を参照してください。 デフォルトでは、redo ログはディスク上で ib_logfile0 および ib_logfile1 という名前の 2 つのファイルによって物理的に表されます。 MySQL は、redo ログファイルに循環して書き込

                                                  • MySQL Shell Copy Instance ユーティリティの紹介 | スマートスタイル TECH BLOG

                                                    今回の記事は MySQL Shell 8.1 (Innovation release) で追加された新機能 Copy Instance ユーティリティ の紹介です。 リリースノートはこちら。 MySQL :: MySQL Shell Release Notes :: Changes in MySQL Shell 8.1.0 (2023-07-18, Innovation Release) ※注:2024/5月時点でリンク切れ It is now possible to copy an instance, schemas, and tables from one instance to another with the new MySQL Shell copy utilities. The copy utilities enable you to copy DDL and data betw

                                                      MySQL Shell Copy Instance ユーティリティの紹介 | スマートスタイル TECH BLOG
                                                    • 第106回 長期サポート版MySQL 8.4 LTS登場、PostgreSQL 17ベータ版など新リリース目白押し | gihyo.jp

                                                      OSSデータベース取り取り時報 第106回長期サポート版MySQL 8.4 LTS登場⁠⁠、PostgreSQL 17ベータ版など新リリース目白押し この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。 [MySQL]2024年5月の主な出来事 2024年4月30日にMySQL 8.4.0がリリースされました。このMySQL 8.4.0はMySQLのLTS(Long Term Support)リリースの第1弾です。MySQLのLTSは長期にわたって安定してシステムを運用していただけるよう、リリース後は機能追加を最小限に抑え、基本的にはバグ修正やセキュリティ・パッチのみを提供していくバージョンとなっています。なおLTSとは別に、3ヵ月ごとに新機能を追加していくイノベーション・リリースも用意されており、MySQL 8.1から8

                                                        第106回 長期サポート版MySQL 8.4 LTS登場、PostgreSQL 17ベータ版など新リリース目白押し | gihyo.jp
                                                      • N+1問題をFetch Modeで対策する | QUARTETCOM TECH BLOG

                                                        Symfony Advent Calendar 2020 15日目の記事です! N+1問題とは DBからEntityのコレクションを取得する時、都度都度クエリを発行してしまう構造になっていて、意図せずクエリ数が膨大になってしまいパフォーマンスが悪くなる現象を指します。 どのような状況で起こるでしょうか?実際にN+1問題が起こるコードを書いてみます。 クラス構成 N+1問題が起きやすい例として、「1対多のリレーションの先に、更に1対多のリレーションがある」という構造を作ってみます。(個人的にこの構造を指して「親-子-孫3代の形」と例えたりしてます) 今回は以下のようなクラスで作ってみました。 「チーム」に対して1対多で「メンバー」が所属し、また「メンバー」はそれぞれ1対多で「投稿(Post)」を持っている、と仮定します。 Entityのコード例 <?php namespace App\Ent

                                                          N+1問題をFetch Modeで対策する | QUARTETCOM TECH BLOG
                                                        • MySQL バックアップ 条件指定バックアップや差分バックアップの方法は? | ポテパンスタイル

                                                          MySQLのバックアップについて、コピペで使えるコマンドサンプルを紹介しながらまとめています。 以下、データベースとして、MySQLのサンプルデータベースEmployeesを使っています。 サンプルデータベースのインストール方法は、以下の記事を参考にしてください。 【関連記事】 ▶MySQLの入門には、GUIツールで慣れ、サンプルDBを使った学習が効果的 バックアップ実行コマンドmysqldumpの使い方 MySQLのデータバックアップには、mysqldumpコマンドを使用します。使い方は以下のとおりです。 mysqldump [OPTIONS] database [tables] mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...] mysqldump [OPTIONS] --all-databases [OPTIONS]

                                                          • MySQLで「無ければINSERT、あればUPDATE」を実現する方法 - Mobile Factory Tech Blog

                                                            こんにちは、駅奪取エンジニアの id:kimkim0106(旧: id:kaoru_k_0106)です。 今回の記事は、駅奪取でテーブルにレコードが「無ければ INSERT、あれば UPDATE」(いわゆる UPSERT)をする箇所で Duplicate entry が出ていたのを修正したり、未然に防ぐ実装をしたときに得られた知見です。 このような処理はよく使われますが、うまく実装しないとエラーが発生したりパフォーマンスの問題が生じたりします。 この記事では、自分が試した方法のメリット・デメリットについて説明します。 目次 前提条件 Duplicate entry とは 1. Duplicate entry が出たらトランザクション自体をやり直す 2. INSERT ... ON DUPLICATE KEY UPDATE 3. とりあえず INSERT して Duplicate entry

                                                              MySQLで「無ければINSERT、あればUPDATE」を実現する方法 - Mobile Factory Tech Blog
                                                            1