MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
MySQL 5.7.6のgenerated columnは関数インデックスの夢を見るか
MySQL 5.7.6-m16で導入されたgenerated columnについてメモ。タイトルでしゃらっと関数インデックスとか言っているけれど、俺はその機能を知らない。 MySQL :: MySQL 5.7 Reference Manual :: 13.1.14 CREATE TABLE Syntax generated columnはあるカラムの値に関数を噛ませた結果をカラムとして実体化できたり、実体化せずに毎回計算できたりするカラム定義のことらしくて、 mysql57> CREATE TABLE t1 (num int, val varchar(32)) Engine = MyISAM; Query OK, 0 rows affected (0.01 sec) mysql57> INSERT INTO t1 SET num = 1, val = 'one'; Query OK, 1
MySQL で utf8 と utf8mb4 の混在で起きること - tmtms のメモ
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた
Uber-migrated-pg-to-mysql.md Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog のまとめ Posgresqlだと pgは追記型なので少しの更新でも多くのdiskへのwriteがおきる カラムを一つ更新しただけで多くのindexの書き換えが起こる よって、replicationはWALを送るので更新が多いとWALが大量に送られる repcliationでは物理的なdiskの変更を送る DC間でレプリするときつい bugがあってreplica間でMVCCの不整合が起きる masterとreplica同じdisk上のデータ構成を共有するのでupgradeがつらい cache readはsyscallとosのpage cache経由なので重い 1コネクション1プロセス
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
MySQLゆるふわ運用のためのアグレッシブ開発 ～ データを増やさないための設計と運用方針について(主にパーティション活用の話)
MySQLゆるふわ運用のためのアグレッシブ開発 ～ データを増やさないための設計と運用方針について(主にパーティション活用の話)
CIEN Pattern で複雑な集計をカジュアルに行う #mysqlcasual | Born Too Late
この記事は MySQL Casual Advent Calendar 2013 の 17 日目です。 前日は @Yuryu さんの MySQLにMHA を導入してハマったところでした。 今日は、私が CIEN Pattern (シャンパターン) と名付けた SQL のイディオムをご紹介します。 これは複雑な集計をカジュアルに行うためのもので、私は日常的に使っています。 イディオムの紹介とか言いつつ、大半は前に社内で書いた便利ツール (オープンソースでない) の紹介だったりします。 本日ご紹介するイディオム ここでいう「複雑な」というのは、例えば「掲示板に書き込んでいるユーザのうち 20 台男性のユニークユーザ数・30 台女性のユニークユーザ数・全体のユニークユーザ数・全体の投稿数を SQL 一発で全部集計したい」みたいなヤツです。 「サブクエリ 7 重にもネストしている上相関サブクエリだ」
Devsの常識、DBAは非常識
1. MySQL Admin が見た Devs の常識、 DBA は非常識 2013/09/14 yoku0825@MyNA PHP Conference 2013 2. ＼こんにちは！／ ● yoku0825 ● とある企業の DBA ● MySQL 歴 5 年くらい ● オラクれない ● ポスグれない ● 嫁の夫 ● せがれの父 ● 日本 MySQL ユーザ会 (MyNA) のスベり担当 3. ＼しゃべること！／ ● 日常的に MySQL のソースコードに触れる変態 DBA がフツーの Devs に投げた愛のマサカリ集 ( のつもり ) ● ウチの開発言語は PHP > Java >> Ruby らしいです ● ウチでは DBA がサーバーの構築、 Devs が設計・ テーブル構築・運営、 DBA はトラブルシュートや改 善提案 ( 運用 ) 、というサイクルで回しています。
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編） こんにちは nob です。 前編 これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） の記事から１年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を（システム編）としてお届けいたします！ 今回の（システム編）で紹介するツボは 4 つです。（クエリ編）のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 （ツボ１）Load Average < (1 + (cpu数-1)/3) （ツボ２）Checkpoint Age が水平線になったら要注意 （ツボ３）MyISAM は無いよね監視 （ツボ４）万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL
Amazon RDS(MySQL)でTimezoneを変更する | DevelopersIO
ども、大瀧です。 RDSにするか、DB on EC2にするかを検討する際によく挙がるのが、Timezoneをどうするかという話。AWSのサービスは基本的にはUTC(世界標準時)で提供され、RDSも例外ではありません。 「世界展開を狙うサービスであれば当然UTCで！」となるのですが、既存システムをAWSに移行する案件などでは「アプリの改修ができないので、移行前とTimezoneを合わせたい」ケースが多いと思います。 EC2であれば、OSのTimezone設定をちょちょいと変えるだけで対応できるのですが、RDSは直接インスタンスにログインできないため、ちょっとした工夫と注意が必要です。 概要 今回はRDS MySQLを対象に、Timezoneを変更する方法をご紹介します。 RDSでユーザーに提供される"Masterユーザー"は、MySQLのrootユーザーとは異なりSUPER権限(管理者権限)
MySQLのfrom_unixtime(), unix_timestamp()をPerlから使うモジュール作った - Cside::Weblog
2013-05-21 MySQLのfrom_unixtime(), unix_timestamp()をPerlから使うモジュール作った perl 集計バッチやなんかを書くときに、MySQLのDateTime型（%Y-%m-%d %H:%M:%S）とUNIX timeを相互に変換したくなるときがある。要するにMySQLでいうfrom_unixtime()関数、unix_timestamp()関数にあたるものが欲しい。ので、それらをPerlで使えるやつを書いた。https://metacpan.org/module/Time::Format::MySQL use Time::Format::MySQL qw(from_unixtime unix_timestamp); print from_unixtime(time); #=> 2013-01-11 12:03:28 print unix_t
Amazon RDSで仮想DBインスタンスを作成する | イーライセンスシステムズ技術ラボ
この記事では、Amazon RDSを用いた仮想DBインスタンスの作成方法を説明します。 【作業概要図】 Amazon RDSとはAmazon RDS(Amazon Relational Database Service)とは、AWSの仮想DBサービスです。AWSでは、EC2で仮想マシンを作成し、その上にMySQLなどのDBサーバを構築することもできますが、 元からDBサーバとしてセットアップされたインスタンスを構築することが可能です。RDSを用いる利点としては、以下のような点があげられます。OSのレイヤーが隠蔽されるため、EC2以上にインフラの知識がなくてもDBサーバが構築できます。 (ただし、利用するRDBSの設定については、相応の知識が必要です)バックアップや、遠隔拠点間の冗長化を容易に構築することができる。その他、EC2で得られるスナップショットなどのメリットを享受することができる。
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLテーブル設計入門
Webエンジニアに知ってほしいRDBアンチパターン
ふつうのWeb開発者のためのクエリチューニング
DBスキーマもバージョン管理したい！
MySQLの冗長化 2013-01-24
Rds徹底入門
MySQLバックアップの基本
