ヤフー社内でやってるMySQLチューニングセミナー大公開SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
MySQL 5.6と5.7における高度なクエリチューニングのQ&A(The Percona Performance Blogより) | Yakst
9年弱前投稿 修正ありMySQL 5.6と5.7における高度なクエリチューニングのQ&A(The Percona Performance Blogより) 出典について この記事はThe Percona Performance Blog内のAlexander Rubin氏による「Advanced Query Tuning in MySQL 5.6 and MySQL 5.7 Webinar: Q&A」(2015/8/24)を翻訳したものである。 8月22日のオンラインセミナー「MySQL 5.6および5.7における高度なクエリーチューニング」に参加していただいてありがとう(私のスライドおよび動画はここで確認できる)。ここでは質問とその回答の一覧を紹介する(いい質問をありがとう) 。 Q: ここにexplainの例がある mysql> explain extended select id, s
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
MySQL と寿司ビール問題 - かみぽわーる
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
YouTubeがMySQLをスケールアウトする「Vitess」をオープンソースで公開。Kubernetesに対応
YouTubeがMySQLをスケールアウトする「Vitess」をオープンソースで公開。Kubernetesに対応 Google Cloud Platformのブログに投稿された記事「Scaling MySQL in the cloud with Vitess and Kubernetes」で、Vitessは次のように説明されています。 At YouTube, we went on that journey as we scaled our MySQL deployment, which today handles the metadata for billions of daily video views and 300 hours of new video uploads per minute. To do this, we developed the Vitess platform,
VOYAGE GROUP エンジニアブログ : MySQL InnoDBのinsertとlockの話
2015年03月08日17:06 カテゴリ MySQL InnoDBのinsertとlockの話 こんにちは。ECナビでアプリケーションエンジニアをやっている駒崎です。 今回はMySQLのInnoDBエンジンにおけるINSERTとロックの挙動について書きたいと思います。 はじめに アプリケーションでレコードの重複チェックをしてからINSERTをする。テーブルにはUNIQUE制約をかけてデータ不整合が起きないようにしている。という仕様はよくあるケースだと思います。 こういったケースでINSERTしたときにどのような仕組みが働いて重複データを防いでいるのだろう？アプリケーションで重複チェックをしてはいるけどMySQLではどんな挙動をしているんだろう？というのが気になったので調べました。 調べること INSERTした場合のロックの挙動 FOR UPDATE文で排他ロックをかけた場合のロックの挙動
MySQL 5.7で絶対に必要になると思うlog_timestampsの設定
気づかなかったけど、これ5.7.2から入ってたのか。 フツーに扱うDATETIME型(やその親戚)は time_zone 変数に支配されるけど、ログに出力される時刻は log_timestamps 変数に支配される。 この変数の取りうる値は UTC または SYSTEM で、暗黙のデフォルトはUTC 。。 mysql57> SELECT @@version; +---------------+ | @@version | +---------------+ | 5.7.5-m15-log | +---------------+ 1 row in set (0.00 sec) mysql57> SHOW GLOBAL VARIABLES LIKE '%time_zone'; -- タイムゾーンはフツーにJST +------------------+--------+ | Variable_
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
5.6 以前の InnoDB Flushing
Bind Peek をもっと使おうぜ！(柴田 歩) - JPOUG Advent Calendar 2014(Day 5) -歩 柴田
MySQLにうるう秒は保存できるのか試した - かみぽわーる
結果、保存できなかった😢 SET sql_mode = STRICT_ALL_TABLES; CREATE TABLE time_leap ( dt datetime, ts timestamp ) ENGINE=InnoDB; INSERT INTO time_leap VALUES ('2012-06-30 23:59:59', '2012-06-30 23:59:59'); -- Query OK, 1 row affected (0.02 sec) INSERT INTO time_leap VALUES ('2012-06-30 23:59:60', '2012-06-30 23:59:60'); -- ERROR 1292 (22007): Incorrect datetime value: '2012-06-30 23:59:60' for column 'dt' at r
『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
Amazon RDS における MySQL 5.6 のパラメータ設計例 - bekkou68 の日記
(最終更新日: 2017/9/25) はじめに production 環境で MySQL 5.6 動かすためのパラメータ設計についてまとめました。この記事がカバーする内容は次のとおりです。 パラメータを設定するスクリプト。 各パラメータにおける変更するかどうかの判断基準。 想定されるメモリの消費サイズを算出してパラメータが妥当かどうか確認する方法。 サービスの状況に応じててきぎ読みかえてください。 【結論】パラメータグループ作成・パラメータ設定のスクリプト 結論として、パラメータグループを作成し、パラメータを設定する aws-cli のスクリプトを置きます。Amazon AWS の Web Console から設定することもできます。 #!/bin/sh # == パラメータグループ作成 aws rds create-db-parameter-group --db-parameter-gr
チューニンガソン5の復習 MySQL 5.6 新機能編 - SH2の日記
というわけで、MyNA(日本MySQLユーザ会)会 2013年3月に参加して発表をしてきました。とてもリラックスして話をすることができました。司会進行の坂井さんをはじめ日本MySQLユーザ会のみなさま、日本オラクルのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは前回のエントリの続きということで、MySQL 5.6の新機能Optimizer Traceを活用しながら正攻法でのチューニングを行っていきました。とはいえ途中から正攻法ではなくなっていた気もします。MySQL 5.6でRDBMSとしての土台はしっかりしてきたと思いますので、今後は高度な統計情報を使用したSQL実行計画の最適化といったところにも機能強化が施されていくのではないかと期待しています。 プレゼンテーション資料 (PDF) EXPLAINとOptimizer Traceの出力結果 プ
チューニンガソン5の復習 MySQL 5.5 チート編＆勉強会のお知らせ - SH2の日記
ゼロスタートの@zakiさんを中心に企画、運営されているチューニンガソンというイベントがあります。指定された環境を用いてOSやサーバ周りのチューニングを行い、性能を競うというものです。2013年1月に行われた第5回ではMySQLがテーマだったということで、本日はこれの復習をしていこうと思います。 【レポート】いろいろチューニングしてパフォーマンスを競うバトルイベント！「Tuningathon」第5弾！ #tuningathon : ゼロスタートの広報ブログ 2013年最初のチューニンガソンはMySQL！――第5弾！ いろいろチューニングしてパフォーマンスを競うバトルイベント「チューニンガソン」レポート：レポート｜gihyo.jp … 技術評論社 Tuningathon#5 - Togetter しばらく真面目にチューニングしていたのですが思いのほか難しかったので、今回はちょっとズルをして優
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門 広く浅くを担当してます、ota です。 技術ブログ第一回から早速流用スライドで申し訳ありませんが、社内勉強会資料として作成した「MySQL INDEX + EXPLAIN入門」です。 当社でもソーシャルゲームの開発を行っていますが、このような大量のデータを使用する・クエリの速度が求められる場合にインデックスは大変重要です。 インデックスの有効な利用にはDB設計者だけではなくプログラマにもある程度の知識が最低限必要となりますが、インデックスについての初心者向け資料があまりないようです。 このスライドではプログラマに知っておいて欲しい以下の基本的な点をまとめました。 INDEXを使用する時に気をつけること WHERE句 !=、<>はインデックスが使用できない WHERE句の全てのANDにかかっていないイン
MySQLパフォーマンスチューニングのためのインデックスの基礎知識 - 久保清隆のブログ
仕事でMySQLのパフォーマンスチューニングをしていて、インデックスについて分かっていないことが多かったので調べたことをメモ。基本的なところから学習しなおした。 MySQLのインデックスは、カラムが特定の値をもつレコードの迅速な検索に使用される。インデックスを使用すれば、数百とか数億ものレコードが入っているテーブルから、一組のレコードを迅速に見つけて取り出すことが可能になる。 しかし、インデックスは速度を改善することもあるが、挿入の邪魔になって遅くなることもある。 インデックスを適切に使うために、まずはインデックスの基本概念をおさえる必要がある。 インデックスの概念 インデックスとは インデックスの仕組みを理解するには、まずMySQLがどのようにクエリに応答するかを知る必要がある。 例えば、 SELECT * FROM phone_book WHERE last_name = 'Hoge'
レプリケーションを使わないMySQLの冗長化
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、DBMSチームの三谷です。 ヤフーでは多くのサービスでMySQLを利用しています。MySQLはヤフーを支える重要な技術の1つです。 私のチームではヤフーのさまざまなサービスのデータベースを集約して管理・運用しています。 集約することでコストの削減やノウハウの蓄積といった効果を生み出しています。 今回はこの集約環境の冗長化方法についてご紹介します。 集約環境の構成 集約環境ではマスターの冗長化にレプリケーションを利用せず、エンタープライズ向けの共有ストレージを利用したアクティブ・パッシブ型のHA構成を採用しています。 データファイルを共有ストレージに置き、どのマスターサーバーからでも同じデータに対してアクセスできるように
localhost の特別扱い - どさにっき
2012年10月2日(火) ■ localhost の特別扱い _ localhost というのはローカルなホストであって外部のホストではない。はず。なので、デフォルトで特別扱いしているアプリというのがたまにある、というのがちらっと近所で話題になって思い出したことを。 _ MySQL。サーバではなくクライアント側のライブラリ。この手の特別扱いでとびぬけておかしな挙動をしやがる。接続先ホストとして localhost を指定すると、127.0.0.1 でも ::1 でもなく、接続先を勝手に UNIX ドメインソケットに変更してつなぎにいきやがる。 詳細。ライブラリが勝手にやってるので、それを利用するアプリはすべてこのような挙動になる。localhost で待ち受けているのが自ホストの mysql サーバではなく、他ホストで動いている mysql に接続するために掘ったトンネルだったりするとこ
MySQL 5.6におけるsync_binlog=1の改善について＆勉強会のお知らせ - SH2の日記
2012年6月のエントリの続きです。前回は同期レプリケーションによるネットワーク遅延のある環境において、MySQLの性能がどの程度低下するのかということを確認しました。その中でも特にsync_binlogが1に設定されている場合、性能が大きく低下するということが分かりました。参考としてAmazon RDSのマルチAZデプロイメントにおいては、性能と信頼性のトレードオフを考慮した結果、sync_binlogがデフォルトで0に設定されているということを調査しました。 タイトルでネタバレしていますが、MySQLの次期バージョン、MySQL 5.6でこのsync_binlog=1の性能が大きく改善します。前回と同じ負荷テストをMySQL 5.5.25からMySQL 5.6.6-labsに差し替えて行った結果を、以下に示します。 前回のMySQL 5.5.25と異なり、sync_binlog=1にお
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL Casual Talks Vol.4 「MySQL-5.6で始める全文検索 〜InnoDB FTS編〜」
