インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
DBT-2 で MySQL と他のRDBMSの性能比較をしている人に騙されないように注意
一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。 未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。 DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。 が、３年前にあろうことかMySQLの性能QAがDBT-2(nonsp:mysql)を利用していて、とある性能FIXに対して問題を指摘して
InnoDB Deep Talk #2 (仮) に引っ張りだされました。
先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。 「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。 今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。 これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
MySQLのパラメーターチューニング at OSC 2014 Tokyo/Spring
去る2014/03/01(土)の OSC 2014 Tokyo/Spring でMyNAとしてセミナーの枠をいただいたので、おはなしししてきました。 雨の中たくさんの方に足を運んでいただきました。本当にどうもありがとうございました。 "MySQLパラメーターチューニングの理屈と定石"と銘打って、普段アプリを書いているような人向けに、俺が普段やってるパラメーターチューニングと同じくらいのことが誰にでもできるように…とか思って資料を作っていたんですが(社内のDB勉強会に使うネタのうち、パラメーター調整の部分だけを切り出した、というのがもともとのコンセプトです)、作れば作るほど、いかに自分が「考えるな。感じるんだ」でチューニングしているのかをむしろ思い知らされました。 「これとこれ見るでしょ？ そうするとなんか変な感じがするじゃない？ で、こことここだからこれかなって。いじってみたら違うから、近
DBD::mysql Async API MySQL の Async API 使って思いクエリを並列処理したら早いかと思ったらそうでも無い風味。 Web アプリの時のように、クライアント側の並列度があがれば差が縮まる感じだけどそうでもない。 ある程度重いクエリの想定で SELECT SLEEP(0.05) とか投げてみたけどやっぱり普通に使った方が早い。 Async API 使うのにコストがかかるのかな、と思って IO::Select 使ってみたらかなり早くなったので AnyEvent がわりとボトルネックっぽい。 とは言え微妙な誤差ではあるので、普通に DBI 使ってればいい気がしてきた。 perl 5.18.2 DBI 1.63 DBD::mysql 4.025 AnyEvent 7.07 IO::Select 1.21 async-mysql-ioselect.pl が全入りベンチ(
plenvやperlbrewでcpanmを入れてそれでモジュールを入れるとDBD::mysqlが入らないケースがあります。手元にMySQL (libmysql) が入っていないからです。 Homebrewを使って手元に手軽にMySQLを入れてしまいましょう。 検証環境: MacBook Air 2013 Late Mavericks なお、付記として Debian stable / Ubuntu stable の場合についても言及してあります。 HomebrewでMySQLを入れる 思いつく通りに入れれば大丈夫そうです。 ここでトラブルが起きた場合は brew doctor を参考にするか、brew update を怠っていないかなどをチェックしましょう。HomebrewでMySQL 5.6をインストール。開発用my.cnfもさらす も参考になります。 DBD::mysqlインストール用の
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
2. やあ (´ ・ ω ・ `) ようこそ、バーボンハウスへ。 このＤＤＬはサービスだから、 まず読んで落ち着いて欲しい。 3. CREATE TABLE `hogehoge`( `aa_id` bigint NOT NULL AUTO_INCREMENT, `bb_id` int unsigned NOT NULL, `key` varchar(64) NOT NULL, `cc_url` varchar(255) NOT NULL, `dd_json` text, `ee_flag` int(1) NOT NULL, `pp_date` datetime NOT NULL, `qq_date` datetime NOT NULL, PRIMARY KEY(`aa_id`), UNIQUE KEY `uidx_hogehoge_01`(`cc_url`), KEY `1`(`ee_fl
ご縁があってAWS User Group - Japanにお誘いいただき、10月4日に第18回 AWS User Group - Japan 東京勉強会で発表をしてきました。運営のみなさま、当日お越しいただいたみなさま、どうもありがとうございます。 今回は「秋のDB祭り」ということで、MySQLに限らずさまざまなデータベースに関する話題が取り扱われていました。その中でもRedshiftのセッションが複数あり、注目度の高さが伺えました。クラスメソッドさん、EnterpriseZineさんが勉強会の様子を詳しくレポートされています。 第18回 AWS User Group - Japan 東京勉強会 に参加してきた #jawsug ｜ Developers.IO JAWS-UG東京勉強会で濃ゆーい「秋のDB祭り」：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (E
yoku0825 @yoku0825 @con_mame ああ、やっぱりそうなりますよね。。こっちは息をするくらい当たり前のことだと思っていても向こうは違って、向こうが当たり前に思っていることも俺は知らなくて、あぁ…ってなります。。
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 はトラブルシュートや改 善提案 ( 運用 ) 、というサイクルで回しています。
追記：記事の文中で5.6のsql_modeデフォルト値について若干実際の挙動と異なる表記をしていました。rpmでinstallすると/usr/my.cnfというのがひょっこりいて、この中に [mysqld] sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES という記述があり、これを/etc/my.cnfと合わせて設定している様です。で、デフォルト値については5.6.6以降はデフォルト値が「The default SQL mode in MySQL 5.6.6 and later is NO_ENGINE_SUBSTITUTION;」でそれ以前のデフォルト値は「MySQL 5.6.5 and earlier, it was empty (no modes set)」となっているようですね。 詳しくは http://yoku0825.blo
Test::mysqldというモジュールがあって、MySQLを使うテストを簡単に書けるので好評なわけですが、今回これに copy_data_from って、既存のデータディレクトリをコピーして mysqld を起動するオプションを足しました。 このオプションを使うことで、以下のように MySQL データベースからコピーしたデータを使うテストを書くことができるようになっています。 use Test::mysqld; my $mysqld = Test::mysqld->new({ my_cnf => { 'skip-networking' => '', }, copy_data_from => 't/mysql.data', # mysqld の data ディレクトリをコピーしたやつ }) or die $Test::mysqld::errstr; my $dbh = DBI->conne
良くはない。それはわかってる。でもなんかちょっとくらいなら使っていいかな的な 例えばこのようなテーブル Create Table: CREATE TABLE `users` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(128) NOT NULL, `delete_null_flag` tinyint(1) DEFAULT '1', PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`,`delete_null_flag`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 があって、適当にinsertしてみる mysql> insert into users (name) values ('shoichimasuhara'); Query OK,
今さらですが、Amazon RDSのマルチAZデプロイメントについて調べていました。マルチAZデプロイメントとは、独立した電源、空調、ネットワーク、セキュリティを備えた物理的に異なるロケーションに対して同期レプリケーションを行うことで、データベースの耐障害性を高める機能です。AZはAvailability Zoneの略です。 異なるロケーションに対する同期レプリケーションと聞くと、性能が出ないのではないかという懸念がどうしても出てきます。そこで、どの程度性能が落ちるものなのか検証を行いました。なお、すでに実際のAmazon RDSを利用して検証を行った方がいらっしゃいましたので、今回は手元の環境を利用して、ネットワーク遅延やMySQLパラメータと性能との関連性を確認していきたいと思います。 Amazon RDS MYSQL Performance Benchmarking - Cloud
こんばんはこんばんは!! myfinder です。 MySQL Casual Advent Calendar 2011 始まりました!! 1日目は言い出した自分から書きます。 よく Casualじゃない といわれのないツッコミを受ける MySQL Casual ですが、Casual Advent Calendar という名前の通りライターの皆さん自身が気軽に書けるネタでサクっとupすればOKです。 もちろんですが、綿密な検証に基づいたガチな記事も書ける方がいたら是非お願いします。 きわどいネタは id:kamipo さんや id:do_aki さんがきっとやってくれるので、お二人にお任せしましょう。 はじめに MySQL5.5 からは InnoDB がデフォルトストレージエンジンになりました。 4.xや5.1以前を利用している方も、今となっては InnoDB を使わないのは敢えてそれ以外を
オープンソースデータベースを加速する「キムラデービー」のブログです。カレー日記を兼ねてます。なお著者は2010-06-01より日本オラクルに在籍していますが、本サイト（ブログ、またはウェブサイト）において示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。 MySQL 5.1+InnoDB Plugin, 5.5以降でサポートされた以下の三つの情報スキーマテーブルを使うとトランザクションとロックに関わる情報をInnoDBロックモニタよりも簡単でわかりやすく取得することが可能です。 | INNODB_LOCK_WAITS |独自: ロック待ち情報 | INNODB_LOCKS |独自: ロック競合情報 | INNODB_TRX |独自: トランザクション情報 通常一つの接続ではトランザクションのBEGIN; COMMIT;を何度か行います。つまり一つ
Perl › モジュール › here MySQLのデータベースの差分から、差分をなくすようなコマンドを自動生成するツールを探していたら、MySQL::Diffというモジュールを発見した。このモジュールにはmysqldiffというコマンドラインツールがついているので、通常はこちらを使うのが良いみたい。 開発環境と本番環境の差分を埋めるのにとても役立つ。すべての差分を表示してくれるわけではなく、テーブル定義に関する部分だけのようなので、トリガやインデックスについては、自分で設定する必要があるようです。 ドキュメントにはオプションの説明がないようなので、--helpコマンドで確認できる。 mysqldiff --help まずデータベースのテーブル定義をmysqldumpで取得しましょう。今は開発環境にいて開発環境のデータベースサーバーに変更を加えていると仮定します。 mysqldump -d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
