片手間MySQLチューニング戦略2017/10/08 phpcon 2017 https://joind.in/event/japan-php-conference-2017/session05-mysqlRead less
mysqldiff を使って継続的に MySQL のデータベーススキーマの差分をチェックする - kakakakakku blog
最近，環境ごとのデータベーススキーマの差分をチェックする機会があった．プロダクション環境とステージング環境ならまだしも，開発環境だと検証のために追加したインデックスがそのままになっていたり，開発が途中で止まってしまって日の目を見ることがなかったテーブルが残っていたり，そういうことって比較的あるのではないかなと思う．特に今の環境だと，マイグレーションの仕組みが整っていないという課題もあり，より一層，データベーススキーマに差分が出やすくなってしまっている． 今回は MySQL から公式に提供されている mysqldiff というツールを使ってデータベーススキーマの差分をチェックした． mysqldiff をインストールする mysqldiff は MySQL Utilities という MySQL の管理ツールパッケージの中に同梱されている．現在だと v1.6 が最新になっている． MySQL
MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
MySQLのgroup_concatで複数レコードを1行にまとめる - 文系プログラマによるTIPSブログ
実は非常に有用で、この機能が実は欲しかった！と言う方が続出する機能なのですよね〜 全然知らなかったのですが、mysqlでは複数レコードを1行にまとめる事ができます。 複数行をカンマ区切りにしたり、結構有効に使えそうです。 テーブル・データの準備 テーブル データ 実際に実行してみる 普通にselectしてみる group_concatしてみる group_concat + distinct group_concat + group by テーブル・データの準備 早速サンプルコードを。 テーブル mysql> create table gc1(id int auto_increment, uid int, name varchar(30), primary key(id))engine=innodb charset=utf8mb4; Query OK, 0 rows affected (0.
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか？その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫！ クエリ編 ３つのつぼと５つのグラフ （その１）監視ツールが何を見ているのか知る （その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler) （その３）グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール
社内勉強会で MySQL 入門的なはなしをしてきた | Born Too Late
社内で, 主に MySQL 初学者を対象とした勉強会をやってきました. 社内勉強会ということで, というと言い訳になりますが, いつも以上にゆるふわな内容となっています. 改めて見るとソースどこだよ? っていう情報がいくつかあるので反省. (「RDBMS を使いつつ, NOSQL で最適化というパターンがほとんど」とかどこのことだよと. まぁ Tumblr とかはそれにあたるみたいですが) あと, インデックスの仕組みを単純化して話すために B-Tree じゃなくて Binary Search Tree について紹介してますが, この辺も詳しい方の突っ込みが欲しい所です. ところで勉強会に参加していてよく思うのですが, 勉強会というのは自分で発表してナンボだということです. これは勉強会で人の話を聞くのは意味が無い, ということではなくて, 自分で調べたときの方が 30 倍ぐらい身に付くん
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ヤフー社内でやってるMySQLチューニングセミナー大公開
実行計画の話
現場指向のレプリケーション詳説
MySQL Casual な生活
MySQLにおけるJOINのチューニングの定石
社内サーバインフラ勉強会(DB)
ソーシャルゲームのためのデータベース設計