MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ
もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました（と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです） 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその
MySQLを使ったアプリケーションを作るエンジニアが知るべきMySQLの内部構造とは？ | Yakst
MySQLを使ったアプリケーションを作るエンジニアが知るべきMySQLの内部構造について、データベースコンサルティング会社PalominoDBを経営するLaine Campbell氏による回答。MySQLを知るためには何をポイントに学習すればよいのかがよくわかる、DBAや開発者にとっても役立つ内容。 1. ストレージエンジン ストレージエンジンと、永続性、ロック機構、トランザクション処理の振る舞いや分離レベルといったストレージエンジンの基礎となる動きについての理解なしに、MySQL自体やモデルデータのコードをいじるべきでない。それに加えて、InnoDBのクラスタ化されたプライマリキーや、MyISAMの全文検索インデックスのようなコア要素も、極めて重要な情報だ。 2. インデックスのコンセプト 特に以下のような点について。 カバリングインデックス 連結インデックス インデックスを使ったソート
PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能
基礎からのPHPという書籍を読んでおりましたら、SQLインジェクションの攻撃例として、以下のSQL文ができあがる例が紹介されていました。PHP+PDO+MySQLという組み合わせです。 SELECT * FROM tb2 WHERE ban=1;delete from tb2 2つのSQL文がセミコロンで区切って1つにまとめられていますが、これを「複文(multiple statement)」と言います。私は、SQLインジェクション攻撃の文脈で複文が使える組み合わせを調べたことがあり、PHPとMySQLという組み合わせでは、複文は使えないと思っていましたので、この攻撃は成立しないのではないかと思いました。 しかし、決めつけも良くないと思い手元の環境で動かしてみたところ、あっさり動くではありませんか。 PDOを用いてMySQLを呼び出す場合は複文が実行できると気づきましたが、なぜPDOの場合
MySQL の SQL エスケープ - tmtms のメモ
この記事は MySQL Casual Advent Calendar 2013 の15日目の記事です。 今、空前の SQL エスケープブームみたいなので、このビッグウェーブに乗っかってみます。 でも面倒なのでセキュリティについての話はしません。カジュアル！ 文字列リテラルとエスケープ MySQL では SQL 中の文字列リテラルは次のように表現します。 'abc' -- シングルクォートで括る "abc" -- ダブルクォートで括る 0x616263 -- 16進数 x'616263' -- 16進数 0b011000010110001001100011 -- 2進数 b'011000010110001001100011' -- 2進数 各表記で charset を指定することができます _utf8 'abc' _utf8 "abc" _utf8 0x616263 _utf8 x'6162
#11 MySQL Master HA を AWS で動作させる場合のフェイルオーバー支援ツール MHA::AWS のご紹介 - KAYAC Engineers' Blog
こんにちは、@fujiwara です。 2013年を振り返ると、春の新卒研修での社内ISUCON、秋のISUCON予選と本選でずっとISUCONをやっていたような気がしていまして、さてそれ以外になにか……そういえばインフラ回りの仕事もしていましたね。 カヤックのサーバインフラ全体としては、Amazon Web Service(AWS) への移行が進んだ1年でした。いままで自社サーバでやっていたソーシャルゲームや、比較的アクセスが多いとある自社サービス(これは後ほど事例公開されるかも知れません) を、AWS上で構築したり移行したり、という仕事が多かったです。 AWSでサービスを構築する場合、MySQL については RDS を利用する EC2 インスタンス上に MySQL サーバを稼働させる というどちらかの手段を取ることになります。 RDSはフェイルオーバーやバックアップを自動でやってくれま
気軽なMySQLバージョンアップ - まめ畑
このエントリーはMySQL Casual Advent Calendar 2013 10日目の記事です。カジュアル！ このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。 MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。 新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。 検証 実際に検証を行う場合、本番環境で流れているクエリをバージョンアップ先のDBに実際に流して
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
基本に戻ってInnoDBの話をします
14. mysql> SHOW CREATE TABLE t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `num` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `val` varchar(32) DEFAULT NULL, UNIQUE KEY `num` (`num`), KEY `val` (`val`) ) ENGINE=InnoDB AUTO_INCREMENT=100000001 DEFAULT CHARSET=utf8mb4 1 row in set (0.03 sec) 【 innodb_buffer_pool_size= 4G 】 $ time bin/m
Transactd - ビズステーション株式会社
Transactd Plugin 3.0 高速アクセス、高機能、分散クエリー可能 MySQL用NoSQLプラグイン 高速スループット 垂直スケーリング 水平スケーリング 分散クエリー トランザクション SQLライクなクエリー Windows Linux Mac OS X C++ PHP Ruby ActiveX DOWNLOAD → Transactd 3.0の機能 New! スキーマテーブルなしでのアクセス New! フィールドのNULL対応 New! すべてのMySQL/MariadbバージョンのDATE型、TIME型、DATETIME型、TIMESTAMP型に対応 New! ビットフィールド専用クラスの追加 New! フィールドのデフォルト値に対応 New! MySQL5.7 / Mariadb10.1への対応 Improved! SQLとの相互運用性の向上 Improved! テス
MySQL5.6関連情報まとめ
5. バグ情報など GTID有効でネットワークが途切れるとデータ消失する InnoDBmemcacheAPIのメモリリーク（ #68530 ） GRANT文発行時、構文に特定の記載ミスがあるとレプリ ケーションが停止する（ # 68892） マッチしないパーティションがたくさんある場合、予想ス キャン件数を過剰に低く見積もってしまう不具合 ※上記は勉強会で見かけた情報などです 僕らのMySQL5.6移行記(仮) http://www.slideshare.net/conmame/mysql56-27565355 7. 運用方法の変化について GTIDが有効だとSlaveでクエリをスキップできなくなって確認 して空コミットしないといけなくなった（割と手間） MySQL Utilityというpythonツールが便利そう バッファプールのダンプとリスト
MySQLで、正しいデータ型を使うことはどのくらい重要なのか？ | Yakst
テーブル設計においてカラムのデータ型を正しく決めることには、どのような利点があるのかについて。単純に扱う値と同じ型を選ぶべきであるというだけではなく、なぜそうあるべきかについて、内部的な効率の面から解説する。 パフォーマンスに関する話の中で、カラムに値を保存するのに正しいデータ型を使うことの重要性を説いているのを聞くことがよくある。例えば、数値はINTやBIGINTで表現し、IPアドレスにはINT UNSIGNEDを使い、VARCHAR(255)の代わりにVARCHAR(60)を使うといったことだ。 このアドバイスは正しい。しかし、今日はもう少し詳細の説明を試みてみようと思う。 理由 この最適化が正しいと思う3つの理由は以下の通りだ。 文字列として数値データを扱うことは、文字コードや照合処理のCPUオーバーヘッドが余計に必要になってしまう。例えば、'Montréal' = 'Montrea
MySQLの大きなテーブルでのパフォーマンスを改善する10の方法 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、テーブルサイズが大きくなるにつれてINSERTのパフォーマンスが落ちてきてしまうことを防ぐ様々な方法についてのまとめ。 今日は、パフォーマンス問題を引き起こす原因になる、サイズの大きいテーブルのパフォーマンスを改善することについて書いてみようと思う。このアドバイスのうちのいくつかは、たくさんのテーブルをまとめて大きくなっているデータベースにも適用できるが、大抵の場合、独立した大きなテーブルというのは特に問題になりやすいものだ。 一般的に知られていると思われるのは、テーブルを変更する時のスピードは、そのサイズが大きくなるにつれて遅くなることだ。以下の図は、一般的なB+ツリーインデックスのパフォーマンスを時系列で見たものだ。 このグラフは、MySQL@Facebookの記事から拝借したものだ。これは、insert buffe
実践ハイパフォーマンスMySQL 第3版
新しい情報を盛り込み、信頼性や正確さといった目標を重視するという前版からの方針に加えて、第3版では、MySQLの動作の仕組みに関する事実だけでなく、MySQLがそのように動作する原理を伝えたいと考えて執筆されている。そうした原理の実質的な効果を示す、より具体的なストーリーやケーススタディを盛り込んで、それらをベースとして、「MySQLの内部のアーキテクチャや処理がそうなっているとしたら、実際の使用状況で実質的にどのような効果が得られるのか」、「そうした効果はなぜ重要なのか」、「結果として、MySQLは特定のニーズにどのように適しているか、あるいは適していないか」という質問に答えている。MySQL管理者やアプリケーション開発者が求める必須の知識や手法を掘り下げて、問題や課題に対して実践的な考え方と解決の手法を示す。読者のMySQLについての理解と技術を一段高いレベルに引き上げる。改訂第3版。
次バージョンのMySQL 5.7はさらに性能を2倍へ、「オラクルはMySQLを殺そうとしている」は真実ではない～MySQL Connect 2013
次バージョンのMySQL 5.7はさらに性能を2倍へ、「オラクルはMySQLを殺そうとしている」は真実ではない～MySQL Connect 2013 米オラクルが主催するMySQLのイベント「MySQL Connect」が9月21日から23日まで、サンフランシスコで開催されました。このイベントでは毎回「The State of The Dolphin」（イルカの最新状況、つまりイルカをマスコットキャラクターにしているMySQLの最新情報）と呼ばれる基調講演が恒例になっていて、MySQLの最新情報が解説されています。 今年も行われた「The State of The Dolphin」の内容を、ダイジェストで紹介しましょう。 The State of The Dolphin 米オラクル、Chief Corporate Architect、Edward Screven氏。 最初に言いたいのは、オ
(帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
MySQL ibdata1が肥大化する理由(記事の意訳) | Ore no homepage
毎日暑い…。というか蒸し暑い。何年か前にベトナムとカンボジアをバックパッカー旅行したときを思い出す。日本の気候が亜熱帯ってか東南アジアっぽくなってきたような…昔はこんな頻繁にゲラリ豪雨とか降らなかったよねー？温暖化ってやつ？日本の植生とか変わるんじゃねーのかな…。 えーと、おれがよく見ている技術ブログの一つにPercona社のMySQL Performance Blogがある。そのブログに先日、「Why is the ibdata1 file continuously growing in MySQL?」という記事が投稿された。内容はInnoDBのibdata1の肥大化とその解消方法に関するもの。ibdata1の肥大化を解消する手段は、ダンプをとってDBを作り直してあげないと治らないということは多くのInnoDBユーザが知っていることだと思うけど、おれもInnoDBを触り始めたころは、「気
MySQLは立ち止まらない・・・MySQL 5.7開発版登場！
まだMySQL 5.6が登場して興奮冷めやらぬところだが、MySQLの開発チームはその手綱を緩めることはない。次期バージョンの開発版であるMySQL 5.7.1がすでに登場している。MySQLの開発リリースモデルではマイルストーンリリースと呼ばれるマイナーバージョンごとに新しい機能が盛り込まれる。（参照：MySQL 5.5登場）MySQL 5.6系での最後のマイルストーンリリース、つまり新しいバージョンが盛り込まれたバージョンがマイルストーン9、そして5.7.1がマイルストーン11となる。（マイルストーン10、つまり5.7.0はリリースされていないバージョンとなっている。）MySQL 5.7が正式版になるまでに、いくつのマイルストーンリリースを経るか、つまりどれだけ新機能が搭載されるかについては今のところ未定だが、新しいバージョンのリリースが待てない！という人はぜひMySQL 5.7.1を
MySQL5.6のちょっとした話 - まめ畑
最近、とあるサービスの本番環境にMySQL5.6を導入していっています。社内だけの環境も含めて5システムに導入しました。 5.5からのアップデートや最初から5.6というものもあります。 今回、導入で変わった点いろいろありますが、メモ程度にまとめておきます。 間違いなどありましたら指摘していただけるとありがたいです。 Replicationエラー時 今までは、replicationのエラーが起こった場合は SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; とかでダメなクエリを確認しつつSKIP出来ればしていましたが、5.6でGTIDモードONの場合、これが使えなくなりました。 GTID便利なんですが、この点少し不便です。 以下のように直します。 まず、slaveでmaster server UUIDと最新のGTID、Retrieved_Gtid_Setを確認します
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Level up your MySQL query tuning
[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo![[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo](https://cdn-ak-scissors.b.st-hatena.com/image/square/7a1595d56a22d7e152f0c4c44cf3168a5c66fcbf/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20131110tuningonmysql5-131117180858-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
