mysql

なぜスタートアップはMySQLを選び続けるのか

スタートアップがMySQLを選ぶ理由は「慣習」ではない MVP開発に必要な条件 ORマッパーとの相性 採用と学習コスト スケールは後から考える 注意点:万能ではない なぜ他のDBに置き換わらないのか 結局、何を選んでいるのか スタートアップがMySQLを選ぶ理由は…

PHPとMySQLが切り離せない関係になった理由

PHPとMySQLは偶然の組み合わせではない PHPが解決した「HTMLは保存できない問題」 MySQLが「状態」を持たせた なぜ他の言語では起きなかったのか レンタルサーバが普及を加速した WordPressが関係を固定化した 注意点:現在は必須ではない なぜ今も語られる…

LAMPスタックがWebを作った本当の理由

LAMPは単なる技術構成ではない Webはもともと「更新できないもの」だった MySQLが「保存」を可能にした PHPが「ページ生成」を実現した Apacheが「公開」を簡単にした Linuxがコスト構造を変えた なぜこの4つの組み合わせが強かったのか 注意点:現在は同じ…

なぜMySQLは世界一使われるDBになったのか

MySQLが普及した理由は「性能」ではない 2000年代のWebは特殊な環境だった 当時のサーバ事情 PHPとの相性が圧倒的だった なぜ他のRDBMSではなくMySQLだったのか WordPressが決定打になった スタートアップ文化との一致 注意点:普及率と適性は別問題 なぜ今…

MariaDBが生まれた本当の理由

MariaDBは「互換DB」ではなく思想の分岐点 きっかけはOracleによるSun買収 MySQLの創始者が離脱した理由 なぜ名前が「MariaDB」なのか MariaDBが目指したもの 実際に起きた分岐 現場で起きる誤解 なぜ企業は判断に迷うのか 注意点:気軽に混在させない では…

Oracleに買収されてMySQLはどう変わったのか

Oracleに買収されてMySQLは「別物」になったのか 買収前のMySQLは「RDBMSらしくなかった」 昔のMySQLの特徴 なぜそれで人気になったのか Oracleが変えたMySQLの方向性 「速いおもちゃ」から「業務用RDBMS」へ なぜ厳格化したのか MariaDBが生まれた理由 開発…

新人が必ず遭遇するMySQLエラーランキング

新人がハマるMySQLエラーランキング 第7位:Unknown column 第6位:Table doesn't exist 第5位:Duplicate entry 第4位:Lock wait timeout exceeded 第3位:Data too long for column 第2位:Incorrect datetime value 第1位:Cannot add or update a child…

Cloud SQL / RDSで起きるMySQLバージョン問題

Cloud SQL / RDSで起きるMySQLバージョン問題 マネージドサービスは「固定」ではない よく起きる症状 認証方式の変更 SQLの挙動が変わる問題 インデックスが急に効かなくなる なぜ気づきにくいのか 事前にやるべきこと マネージドサービスの誤解 Cloud SQL /…

MySQLレプリは混在OK?バージョン互換の現実

MySQLのレプリケーションはバージョン混在できるのか レプリケーションの仕組みを整理する 原則:上位互換のみ安全 それでも止まる理由 1. SQLモードの違い** 2. 文字コードと照合順序** 3. binlog形式の違い** 実際に起きる事故 事前に必ず確認すること 切…

MySQL移行はダンプかレプリか?安全性の違い

MySQLでダンプ移行とレプリケーション移行の違い ダンプ移行とは何か レプリケーション移行とは何か 一番の違い:時間の扱い 実務で起きる事故 バージョンアップ時の注意 どちらを選ぶべきか 最後に重要なこと MySQLでダンプ移行とレプリケーション移行の違…

オプティマイザは別物?MySQLバージョン差の罠

オプティマイザはMySQLのバージョンごとに別物 オプティマイザとは何をしているのか バージョンごとに何が変わるのか 実際に起きる典型的な問題 なぜ開発環境では起きないのか バージョンアップ時の危険な思い込み 対策:必ず見るべきもの ヒント固定は最終…

同じSQLなのに遅い?MySQLの実行計画が変わる理由

MySQLについて、なぜ同じSQLでも実行計画が変わるのか 実行計画とは何か なぜ同じSQLでも変わるのか JOINで突然遅くなる理由 キャッシュも影響する 実行計画が変わるタイミング 実務で起きる典型的な事故 対処法:SQLを書き直す前に見るべきもの ヒント句(o…

MySQLの統計情報が性能を左右する

MySQLの統計情報(statistics)が性能を左右する理由 MySQLはデータを見て実行していない 実行計画が壊れる瞬間 なぜ統計情報は狂うのか ANALYZE TABLE の意味 再起動で速くなる理由 注意:毎日ANALYZEすればよいわけではない MySQLのパフォーマンス問題の本…

MySQL8.4で改善されたパフォーマンスの要点

MySQL8.4は「速くなった」のではなく遅くなりにくくなった まず前提:MySQLの遅さの多くはクエリではない InnoDBのロック競合の改善 統計情報(オプティマイザ)の改善 I/O処理の改善 パフォーマンススキーマの強化 注意点 なぜこの方向の改善なのか どう評…

MyISAMが消えた理由と使われなくなった背景

かつて主役だったMyISAMが見なくなった理由 MyISAMは何が優れていたのか しかし致命的な欠点があった ロック方式の違い クラッシュ耐性の問題 Webの使われ方が変わった なぜ完全に削除されないのか 注意点 InnoDBに移行すべきか MyISAMが消えた本当の理由 か…

InnoDBはいつから標準になったのか

MySQLで「エンジン」を意識しなくなった理由 MyISAMが標準だった時代 InnoDBの登場 なぜ最初からInnoDBではなかったのか 標準が変わったタイミング 何が変わったのか MyISAMが使われ続けた理由 リスクと注意点 今でもMyISAMを使う場面はあるか なぜこの変更…

MySQLのLIKE検索でインデックスが効かない理由

インデックスがあるのにLIKE検索が遅い理由 B-Treeインデックスは辞書と同じ なぜ英語では問題になりにくいのか インデックスが使われないもう1つの理由 EXPLAINで確認する よくある誤解 現実的な解決策 前方一致に変える FULLTEXTインデックス 検索専用カラ…

日本語検索が遅い原因はMySQL設定かも

日本語検索が遅いのはSQLではなくMySQL設定 日本語検索でインデックスが効かない理由 文字数ではなく「バイト長」で比較している COLLATIONが遅さを引き起こす よくある誤った対処 効率的な解決策 前方一致検索に変える ngram FULLTEXTを使う COLLATIONを見…

MySQL8.0のデフォルト文字コード変更の影響

MySQL8.0で突然「文字コード問題」が消えた理由 何が変わったのか なぜこれが大きな変更なのか 移行時に起きる典型的な問題 COLLATIONも変わっている なぜMySQLは変更したのか よくある誤解 リスクと注意点 どう対応すべきか この変更の本当の意味 MySQL8.0…

MySQLのCOLLATION(照合順序)とは何か

MySQLのCOLLATIONを理解しないと検索は壊れる COLLATIONは何を決めているのか _ci と _bin の違い 日本語で何が起きるのか LIKE検索が効かない本当の理由 ORDER BYが変わる理由 COLLATIONが複数存在する理由 よくある危険な状態 リスクと注意点 どう設定すべ…

文字コード問題はなぜDBで起きるのか

「文字コードの問題」はアプリのバグではない ブラウザからDBまでの流れを整理する UTF-8は1つではない 変換が発生する瞬間 なぜ表示時ではなく保存時に壊れるのか アプリケーションは文字を理解していない よくある典型的な事故 文字コードと検索の関係 リ…

絵文字で壊れるMySQLの正体

MySQLで絵文字を入れた瞬間に壊れる理由 なぜ絵文字だけが問題になるのか MySQLのutf8は本当のUTF-8ではない なぜアプリではなくDBで問題になるのか utf8mb4とは何か よくある失敗 なぜ昔のMySQLはutf8mb4ではなかったのか リスクと注意点 向いている構成・…

MySQLのutf8とutf8mb4の違いを本当に理解する

「utf8にしたのに文字化けした」の正体 MySQLのutf8は3バイト utf8mb4とは何か なぜこんな仕様になったのか もっと危険な問題:気づかないまま壊れる インデックス長制限との関係 接続文字コードの罠 移行時に起きるトラブル どう対応すべきか まとめ 「utf8…

「MySQLは簡単」という言葉が危険な理由

「MySQLは簡単」と言われる理由 最初は動く、そして後から壊れる データが増えた瞬間に起きること 制約を書かないと、何も守ってくれない 外部キーを使わない文化 インデックスも自動では最適化されない ORMを使っても解決しない なぜ「簡単」が危険になるの…

MySQLとPostgreSQLの思想が分かれた瞬間

同じRDBMSなのに、なぜこんなに違うのか PostgreSQLの前提:データが最優先 MySQLの前提:アプリケーションが最優先 GROUP BYが象徴する思想差 型変換の違い なぜ方向が分かれたのか 後から起きた逆転現象 現在の違い 開発で受ける影響 どちらを選ぶべきか …

MySQLはいつRDBMSらしくなったのか

MySQLは最初からRDBMSだったわけではない 初期MySQLの実態:トランザクションがない なぜそれで成立していたのか 転機:InnoDBの標準化 ACID特性の導入 それでも残っていた“昔の挙動” 第二の転換点:MySQL5.7 なぜ変化が必要だったのか 移行時に起きる混乱 …

なぜ昔のMySQLはいい加減だったのか

昔のMySQLは本当に“いい加減”だったのか MySQLが生まれた時代の前提 設計思想:止まらないことが最優先 GROUP BYの曖昧さ ゼロ日付とNULL なぜ問題にならなかったのか 変化:Webが業務システムになった いい加減だったのではなく、役割が違った 現在との違い…

MySQLが厳格化した背景とSQL標準の関係

MySQLはなぜ突然“厳しく”なったのか そもそもSQL標準とは何か GROUP BYが象徴する問題 なぜ昔のMySQLは標準に従わなかったのか 転機:企業利用の増加 STRICTモードとSQLモード なぜ厳格化は避けられなかったのか 開発者が受ける影響 よくある誤解:MySQLが使…

MySQL5.6と5.7は別物と言える理由

MySQL5.6までと5.7以降は“同じDB”ではない 最大の変化:SQLモードのデフォルト変更 なぜアプリケーションが壊れるのか STRICTモードの影響 日付の扱いも変わる インデックスと最適化の変化 文字コードと照合順序 5.6と5.7の思想の違い ORMやフレームワークへ…

古いMySQLの移行が地獄になる本当の理由

古いMySQLで作られたシステムを移行すると、なぜ壊れるのか 壊れるのは「データ」ではなく「前提」 新しいMySQLは“間違い”を許さない なぜ古いMySQLは寛容だったのか 移行時に起きる典型的なトラブル 1. GROUP BY問題** 2. 日付の扱い** 3. 文字コード** ORM…