※は十分に大きいため省略しています。また、どちらの表も各整数値型はsignedを想定しています。 データ挿入量が相当大きくない限りは、INTEGER型で足りるのであればINTEGER型で作ってしまって問題ないかもしれません。しかし、あとから足りなくなってデータ型の変更が必要になる可能性があるのであれば、最初からBIGINT型で作ってしまうことも検討したいところです。たしかにALTER TABLEでデータ型の変更は可能ではありますが、データ量の規模によっては時間がかかってしまうためです。だからといって、すべてをBIGINT型のカラムで作ってしまうのも無駄にデータ量が増えてしまうので、きちんと検討して決めることをおすすめします。 また、JOINに利用するカラムの場合は、データ型が違うと型変換が実行されるために実行が遅くなるので、極力データ型を合わせて利用したいところです。 BIGINTじゃ足り
RDS for MySQL DB エンジンのアップグレード - Amazon Relational Database Service
新しいバージョンのデータベースエンジンが Amazon RDS でサポートされている場合は、DB インスタンスをその新しいバージョンにアップグレードできます。MySQL データベースのアップグレードには、メジャーバージョンのアップグレードとマイナーバージョンのアップグレードの 2 種類があります。 メジャーバージョンのアップグレード メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれる場合があります。そのため、DB インスタンスのメジャーバージョンアップグレードは手動で実行する必要があります。メジャーバージョンアップグレードをスタートするには、DB インスタンスを変更します。メジャーバージョンのアップグレードを行う前に、「RDS for MySQL のメジャーバージョンのアップグレード」の手順を実行することをお勧めします。 マルチ
mysql57to8.md 確認すること メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。 基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある 最初に諦めること MyISAMを使いたい 8でも動くけど諦めろ、もう未来はない InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが… InnoDB memcached Pluginとか使ってるんだよね 諦めろ、未来はない これを機にアーキテクチャを見直しましょう PKが無いtableがあるんだよね すべてのtableにまずPKを付けるんだ このあと、DMSを使ったりとかなにをするにしても死ぬ そもそもデータモデルとして死
MySQL即効クエリチューニング ThinkIT Books 作者:yoku0825インプレスAmazon 最近クエリチューニングの仕事があったので、少し深めに知ろうと読んだ。 MySQLの内部構造がどうなっているかは置いておいて、どうすればクエリの問題を把握できるかが素早く知れる良い本だった。90ページくらいですぐ読めるのも良い。個人的にはHandler_%変数を使った調査、innotopによる状況可視化、sys.innodb_lock_waitsによるロック状況の可視化あたりが非常に参考になった。 ちなみにさらに内部構造に踏み込んで理解しようとするなら、以下の記事がおすすめ。 雑なMySQLパフォーマンスチューニング MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ Rails Developers Meetup 2018 で
これは MySQL Advent Calendar 2020 の2日目の記事である。 MySQL についての記事を期待した方には申し訳ないが、MariaDB のコードベースの相当部分は MySQL と共通なので、MariaDB も MySQL の仲間ということで許してほしい。実際、テストやデバッグに関する記述は MySQL でも通用するはずだ。 はじめに この記事の⽬的は、MariaDB の開発経験が無い者が初めて MariaDB にコントリビュートする際の指針を⽰すことにある。基本的なことは Contributing Code に書いてあるので、公式ドキュメントに書かれていない暗黙的な知識を記事の主眼とする。 MariaDB の内部構造について解説することはしない。Expert MySQL が参考になるのでそちらを見てほしい。また、Disk-oriented DB の一般論については、C
MySQL/MariaDB をデバッグする実践的方法を解説する。この記事ではデバッグを行うための準備を行い、具体的なデバッグの方法については (2) 以降の記事で説明する予定である。なお、一連の記事すべてにおいて MySQL 8.0.24 および MariaDB 10.5.9 を前提として解説する。 Building MySQL/MariaDB MySQL/MariaDB のそれぞれについて、ビルドする方法を簡単にまとめておく。以下の記述は筆者の開発環境 (Vagrant Box bento/ubuntu-20.04) を前提としたものである。 MySQL Boost 同梱版のソースを公式からダウンロードし展開する。GitHub から取得すると Boost のバージョンを合わせるのがかなり面倒なので、Boost 同梱版を使うのが吉である。 wget https://dev.mysql.co
この記事では、MySQL/MariaDB のバグを修正するための典型的な手順を、具体例を通して解説する。次の MariaDB のバグを例として取り上げるが、基本的なデバッグの手順は MySQL でもまったく同様である。 MDEV-24868: Server crashes in optimize_schema_tables_memory_usage after select from information_schema.innodb_sys_columns なお、MySQL/MariaDB のデバッグ方法についての包括的な解説を与えるのは、この記事のスコープ外である。デバッグ手法の詳細を知りたい場合は、以下の一連の記事を参照してほしい。 Debugging MySQL/MariaDB (1): Build and Test Debugging MySQL/MariaDB (2): DBU
Home » MySQL Basics » MySQL UUID Smackdown: UUID vs. INT for Primary Key Summary: This tutorial introduces you to MySQL UUID, shows you how to use it as the primary key for a table, and discusses the pros and cons of using it as the primary key. Introduction to MySQL UUIDUUID stands for Universally Unique IDentifier. UUID is defined based on RFC 4122, “a Universally Unique Identifier (UUID) URN Na
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
I am trying to get my mysql image running with utf-8 encoding. My docker-compose file looks like: version: '2' services: db: container_name: zoho-grabber-db-development image: mysql:5.7 environment: - MYSQL_ROOT_PASSWORD=topsecret - MYSQL_DATABASE=development - MYSQL_USER=devuser - MYSQL_PASSWORD=secure ports: - "3306:3306" command: mysqld --character-set-server=utf8 --collation-server=utf8_genera
はじめに バックアップって必要だよね ここまでに作った環境、これから使っていくことを考えると、何かあった時のためにデータのバックアップが必要。 Raspberry Pi 3にDockerをインストールしました Raspberry Pi 3のDockerでRedmineを立ち上げました まずは以下の記事を見ながらお勉強。 第10回 Docker環境におけるバックアップ／リストアの罠 (4/4) イメージは何があるかな。 RedmineとMySQLだけ。 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE redmine latest f2b5b69f9ad5 4 weeks ago 440MB hypriot/rpi-mysql latest 4f3cbdbc3bdb 2 years ago 209MB $ docker ps -a CO
社内のMySQLマスターのtcpdumpの様子。マスタ切り替えした後に切り替え先でクエリが流れているかをみる。単に3306ポートのパケットを流すだけでもよいが、接続確立に失敗しているがパケットは流れてくるという状況もあるので、SQL文が流れているかまでみるのがよい。 tcpdump -tttt -l -i eth0 -A -n -s 0 dst port 3306 | grep -iE "select|update|delete|insert" -tttt は人間に読みやすい形式のタイムスタンプを付与する -l は line buffered。パケット数の大きい環境で負荷を軽くする -A はアスキー表示 -n はIPアドレスの逆引きをしない。DNSリゾルバに負荷をかけないため -s 0 は出力をtruncateせずに全部だす -iはネットワークインタフェースを指定。複数のインタフェースがつ
最近、寒暖の差が激しいですがみなさん体調は崩されていないでしょうか？ こんにちわ。モニプラ for Facebookを担当しています高橋です。 サービス開始当初は問題なかったものの稼働が高くなりデータ量が多くなって クエリのパフォーマンスが悪化すること…よくありますよね？ 今回はクエリチューニングの基本的な手順とケース別に解決方法を解説したいと思います。 クエリチューニングの手順 1.スロークエリログで問題のクエリをあぶり出す まずはどのクエリが問題なのか特定する必要があります。 アプリケーション側でクエリの実行時間を測定し自前でログを出力しておくというのも手ですが、 お手軽にMySQLの設定で一定時間以上掛かったクエリをログに出力しておくことができます。 スロー クエリ ログ(MySQL 5.1 リファレンスマニュアル) mysqldを–log-slow-queriesオプションつきで起
概要 とあるプロジェクトで Rails 3.2 + MySQL 5.5 を利用してる。 管理画面の機能追加と改修をしているのだが、 ある機能の一覧ページが重くて開かないと報告を受けた！ 1台しかない MySQL サーバが落ちて、 サービスに支障が出たことが何度かあるらしい。 問題のページについて 問題のページはよくある、管理画面の一覧画面。 Ajax により、JSON で一覧情報を受け取って表にするページなのだが、 集計値も表に含まれており、この集計値の算出が遅い原因になっていた。 調査・再現 本番同等のDBを準備してもらい、問題の画面を開く。 数分待っても、JSON が返却される様子がなく、そのままタイムアウト。 MySQL のクライアントからshow processlist;で実行中の SQL を軽く覗いてみると、 集計値を出すための SQL が 15 〜 30 秒くらいかかっている。
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
mysqlにlocalhostで接続する場合、(おそらく)自動的にunix domain socket経由で接続しようとする。 dockerで起動した場合やローカルポートからproxyしてmysqlに接続しているような場合は、unix domain socketのファイルは存在しないため以下のようなエラーが発生してしまう。 $ mysql -h localhost --port 3306 -u root -ppass Warning: Using a password on the command line interface can be insecure. ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
