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
レコードがなかったらINSERTして返すみたいなのを確実にやる | おそらくはそれさえも平凡な日々
find_or_create的なやつは大体どんなORMでも レコードを探す 無かったらINSERT みたいに実装することになると思う。ただこれだと、1と2の間でレースコンディションでエラー起きることがある。他のプロセスがINSERTしてしまうとかそういうやつ。 それを防ぎたい場合に、1の時点でFOR UPDATEするのはすごくダメで、空行にFOR UPDATEしたりするとMySQLだと盛大に乙るのは有名な話。 エラーを起こさないで、確実にレコードを取りたい場合にはどうすればよいかというと、以下のようにするのが良いと思っている。UNIQUEキー制約なりがちゃんと付いている前提。サンプルコードはTengの場合。 sub find_or_create_surely { my ($self, $table, $where, $opt) = @_; my $row; my $txn = $self-
Oracle Announces General Availability of MySQL 5.7
Oracle Announces General Availability of MySQL 5.7 New version of the world’s most popular open source database is up to 3x faster than MySQL 5.6 in benchmark tests Redwood Shores, Calif.—Oct 19, 2015 Oracle today announced the general availability of MySQL 5.7, the latest version of the world’s most popular open source database. The new version delivers greater performance, scalability and manage
#yapcasia でMySQL 5.7の罠についてLTしてきました
ネタ的には 発掘するたび書き溜めてきたブログ記事 から 笑いが取れそうなものを 大事そうなもののみをピックアップして紹介した感じです。 知らないと致命傷、でも知ってれば予防できる（はず） MySQL 5.7で不幸になる人が1人でも少なくなってくれることを願っています。 さて、今年のYAPC::Asiaはメイントラックもトークを応募していたのですが見事に落選したので、1日目は完全にリラックスして過ごしました。LTの採否、当日になるまでわかんないのか大変だなーとか、他人事だったんですが、 1日目のLT見るじゃないですか。 面白いじゃないですか。 俺もしゃべりたくなるじゃないですか。 なったんですよ！！１ が、翌朝になってLTの応募ページをたどってみると
MySQL の lower_case_table_names について，テーブル名とデータベース名の中の大文字小文字について - その手の平は尻もつかめるさ
MySQL には lower_case_table_names という変数があって，これはテーブル名の大文字小文字を区別するかどうかというのを設定するパラメータなわけですが，その詳細は以下のようになっています (参照: MySQL :: MySQL 5.6 Reference Manual :: 9.2.2 Identifier Case Sensitivity)． Value 説明 0 大文字・小文字を区別してデータベース名やテーブル名をストアする．これらの名前の比較についても大文字・小文字を区別する．MySQL のサーバが動作する OS のファイルシステムが大文字と小文字を区別しない場合 (例えば OS X や Windows)，この値に設定すべきではない．そうしたファイルシステム上でこの値を0にして，なおかつ MyISAM のテーブル名に対して大文字小文字を混ぜてアクセスするとインデ
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,
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
我々(主語が大きい)は何故MySQLで外部キーを使わないのか
外部キー便利!!! MackerelではPostgreSQLで外部キーあり そのレコードがあることが保証される 各テーブルのidにアプリケーションレベル(Mackerelの場合Scala)で型付けをするとなお便利 MemberID型、MonitorID型 → idで誤ったテーブルを引くとかがない 本日のスキーマ CREATE TABLE `member` ( `id` INTEGER unsigned NOT NULL auto_increment, `earned_item_count` INTEGER unsigned NOT NULL DEFAULT 0, `name` VARCHAR(191) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; CREATE TABLE `item`
Happy Elements Labs: HEKK流ソーシャルゲームのアプリ構成
エンジニアの草苅（@kusakari）です。 Happy Elements株式会社（以下、HEKK）では、モバイル向けのソーシャルゲームに注力して開発を行っています（PCアプリは中国の Happy Elements Ltd. で開発しています）。 HEKKでは全社的にサーバーサイドのプログラミング言語を Ruby で統一しており、フレームワークは Ruby on Rails を使用しています。 データストレージには Cassandra と MySQL を併用しており、スケールする必要のあるデータ（ユーザーデータ）は Cassandra、マスターデータ（例えばアイテム情報）は MySQL に保存するという形で区別しています。 HEKKで開発しているソーシャルゲームの典型的なリクエストフローは、次の図のようなものです。 Apache Cassandra は facebook で開発された大規模
ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL
MySQLの次期バージョンはMemcached APIを備える！ MySQL Conference & Expo 2011基調講演
MySQLの次期バージョンはMemcached APIを備える！ MySQL Conference & Expo 2011基調講演 今年も米サンタクララで4月11日から13日にかけてMySQLのイベント「MySQL Conference & Expo 2011」が開催されました。 MySQLはオープンソースのデータベースとして最も人気のあるデータベースですが、オラクルが買収したことによって先行きが心配され、またMariaDBやDrizzleといったフォークも頭角を現してきています。しかし、この基調講演で明らかにされた次期バージョンMySQL 5.6とMySQL Cluster 7.2は、そうした懸念を吹き飛ばすほど強力な性能向上と新機能が予定されていました。現地時間4月12日に行われた基調講演「State of the Dolphin」の内容を、公開されているビデオから紹介しましょう。 オ
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
米Oracleの「MySQL」取得に対し、R.Stallman氏や創業者が反対意見を表明 | OSDN Magazine
Free Software Foundation（FSF）の設立者、Richard M. Stallman氏は10月19日、米Oracleによる米Sun Microsystems買収が「MySQL」に与える影響について、2つの非営利団体（NPO）と共同で執筆した公開書簡を発表した。書簡は欧州委員会（EC）の競争政策担当委員、Neelie Kroes氏に宛てたもので、「買収を承認すべきではない」と助言している。 この書簡は、Stallman氏、Knowledge Economy International（KEI）の代表者James Love氏とMalini Aisola氏、Open Rights Group（ORG）のJim Killock氏が共同執筆したもの。ECは先に、OracleによるSun買収に対し、MySQLの将来を懸念としてさらなる調査を進めることを発表している。 書簡のメイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
片手間MySQLチューニング戦略
MySQLを割と一人で300台管理する技術
120億レコードの金融資産データを扱うマネーフォワードのMySQL活用のこれまでとこれから // Speaker Deck
MySQLでタイムゾーンがどう設定されているか確認したい - tokuhirom's blog
https://github.com/ichirin2501/doc/blob/master/innodb.md
MySQLのバックアップ運用について色々
TechCrunch
