誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。（特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ！！）しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られている「都市伝説」を10個紹介しよう。MySQLをよく知っている人にとっては「んなアホな！？」と思われるほど突拍子もない事ばかりなので、くれぐれもそのような根も葉も幹も細胞もないうわさを信じないで頂きたい。
都市伝説1. トランザクションが使えない？？？
な、わけねーだろ！！
などといきなり切り捨ててはいけない。未だにMySQLではトランザクションが使えないと信じて止まない人が未だに居る。以前のバージョンではMyISAMもしくはその前身となったISAMがメインのストレージエンジンとして使われており、なおかつそれらが非常に高速であったためMySQL=MyISAM=トランザクションに非対応といったイメージがあったのは否めない。しかしそのような次代は遙か彼方原生代の出来事であり、現在デファクトとして使われているInnoDBではACIDに準拠したトランザクションが利用可能である。InnoDB以外にもNDB、PBXT、TokuDBなど様々なストレージエンジンでトランザクションが利用可能になっている。
そのような都市伝説には喝！！である。
都市伝説2. InnoDBは遅い？？？
たまに居るんです。「InnoDBは遅いから素早いレスポンスを要求するWebアプリケーションでは使えないよ。」などと書いている人が。
な、わけねーだろ！！
などと簡単に切り捨ててはいけない。InnoDBはMySQLに後から組み込まれたストレージエンジンであり、以前のバージョンでは効率が悪かった面があるのは否めない。しかしそれは新生代の出来事であり、現在のInnoDBは「超高性能ストレージエンジン」という認識である。特にOLTP系の処理では卓越した性能を発揮する。昨今のハードウェアは以前と比べると大容量メモリ、多くのCPUコア数、IOPS性能の優れたディスクといったデータベースにとって必要なリソースを豊富に搭載したものが安価に手に入れられるようになった。そのような豊富なリソースを最大限に活用出来るのもInnoDBの特徴である。
そのような都市伝説には喝！！である。
都市伝説3. サブクエリがない？？？
あるよ！あるある！！
などと無闇に突っ込んではいけない。昔々のバージョンには確かにサブクエリなどの一部の機能がなく、その代わりとても高速だというのがMySQLのウリであった面があったことは否めない。しかしそれは先カンブリア時代の話であり、サブクエリはとうの昔に（バージョン4.1において）搭載されている。サブクエリ以外にも、ビュー、プリペアドステートメント、ストアドプロシージャ、トリガ、外部キー制約、INFORMATION_SCHEMA、XAトランザクション、パーティショニング、XML機能といった機能についても「MySQLにはまだ実装されていない」と思い込んでいる人が居るがそれは大きな誤解であり、幅広いアプリケーションで利用出来るように日々MySQLは進化している。
そのような都市伝説には喝！！である。
都市伝説4. 古いバージョンの方が高速で安定している？？？
とんでもない！！
などと容赦なく切り捨ててはいけない。以前のバージョンも確かに高速で安定していた。しかし、今のバージョンはもっと高速で安定している。一部のバージョンにおいて、リリース当初に新機能を追加したために一時的に安定性が劣化した（新機能を使うとバグに見舞われた）ということは確かにあった。しかしそれは遙か昔、白亜紀の話であり、現在は「性能や安定性が損なわれるような変更は絶対しない」という堅いポリシーにおいて開発が進められているため、バージョンを追うごとに性能も安定性も向上しているのである。MySQLはオープンソースで開発されており、なおかつ非常に多くの方々に利用して頂いているので日々たくさんのフィードバックが送られてくる。そのため、開発チームはユーザーの声を取り入れやすいのである。
そのような都市伝説には喝！！である。
都市伝説5. 毎回必ずソースからビルドしなければいけない？？？
オープンソースソフトウェアの宿命であろうか。オープンソースソフトウェアであるがためにソースコードからビルドするのは必須！というかたしなみ！と思い込んでいる人が見受けられるが、それは誤った認識である。MySQLは多くのプラットフォーム（Windows、Linux、Mac、Solaris、HP-UX、AIX、FreeBSDなどなど）をサポートしており、それらのプラットフォーム向けに最適化されたバイナリが提供されている。MySQLビルド専門のチームがあり、日々プラットフォームの特性やコンパイラについて研究してバイナリをビルドしているので、バイナリ版でも十分な性能を得られることが多いのである。しかもオフィシャルなバイナリはQAチームによってしっかりとテストされているので、安定性にも不安はないだろう。
そのような都市伝説には喝！！である。
都市伝説6. オンラインバックアップが出来ない？？？
出来る！出来るんだっ手羽先！！米を食え！！
などとshozo_matsuokaボット風に突っ込んではいけない。MySQLをバックアップするには「MySQLを停止してその間にデータをコピーしてしまう＝コールドバックアップが最適！」だと思い込んでいる人が居るがそれは大きな誤りである。MyISAMしかなかった時代、mysqldumpは処理中ずっとテーブルをReadロックしてしまうため、確かにmysqldumpを実行している間は更新が出来ないという面があったのは否めない。しかしながらそのような話は石器時代のものであり、現在デファクトになっているInnoDBはmysqldump中にテーブルをReadロックするということはない（MVCCがあるので容易に一貫性のあるバックアップを取ることができる）し、商用のInnoDB Hot Backupを使えばmysqldumpよりもずっと高速にInnoDBをオンラインバックアップすることが可能だ。また、LVMやZFSなどのソフトウェアもしくはディスク装置がもっているスナップショット機能を使えば、瞬時に一貫性のあるバックアップを取得することが可能である。スナップショットはMyISAMでもInnoDBでも使えるテクニックでる点は見逃せない。
そのような都市伝説には喝！！である。
都市伝説7. HA構成が組めない？？？
いやいやいやいやいやいや！！
などと高田純○風に突っ込んではいけない。HA構成を組むにはフェイルオーバーが発生したときにスタンバイ側でクラッシュリカバリをする必要があり、確かにMyISAMにはクラッシュリカバリ機能がないためフェイルオーバーに失敗するかも知れないという側面があったのは否めない。しかし、そのような問題は遙か昔、InnoDBが存在しなかったジュラ紀の出来事でありInnoDBが実装されている今となっては当てはまらない。InnoDBはトランザクション対応であるため、突然サーバーマシンやmysqldがクラッシュしても、次回起動時には自動でリカバリが行われるようになっている。従って、InnoDBを使えば各種HAクラスタリングソフトウェアと組み合わせることにより、容易にHAを構成することが出来るのである。（スタンバイ側ですることはファイルシステムをマウントし、mysqldを起動するだけである。）先日リリースされたMySQL 5.5ではSemi-Synchronous Replicationを利用することができ、超短時間でフェイルオーバーするHAを構築することも可能になっている。
そのような都市伝説には喝！！である。
都市伝説8. セキュリティが弱い？？？
どんだけー！！
などと死語になりつつあるツッコミをしてはならない。MySQLは特別セキュリティが堅牢というわけではないが、必要十分なセキュリティは実装されている。ユーザーのアクセスはカラムごとに制限出来るし、SSLによる通信も出来る。希に「MySQLはSQLインジェクションの被害を受けやすい」などと吹聴する人が居るが、それはSQLインジェクションというものを理解していない愚かな発言である。（SQLインジェクションは文法的に正しいSQL文を用いて行われるため、どのようなRDBMSであっても発生してしまう問題なのだから。）
そのような都市伝説には喝！！である。
都市伝説9. 社内利用でもGPL違反で訴えられる？？？
そんなわけあらしまへんがな！
などと某関西系お笑い芸人風のツッコミをしてはならない。何故か日本にはGPLを毛嫌いする人が多いのだが、GPLを正しく理解していればそのような事がないのは明白である。GPLは「ソフトウェアのユーザーは最大限の自由を手にしなければならない」という哲学に基づいたソフトウェアライセンスであり、ユーザーが「ソースコードを要求して仕組みを理解したり自分のニーズに合うよう改竄する自由」ことすら認めている。GPLは「GPLソフトウェアを組み合わせたソフトウェアは、GPLでリリースすること」を求めているが、それは自分がGPLソフトウェアを元に（リンクしたり改造したりして）作成したソフトウェアを頒布（公開・配布・販売etc）するとき以外は問題にならない。つまりユーザーである限り、GPLは最強で最良のライセンスなのである。
そのような都市伝説には喝！！である。
都市伝説10. MySQLはオモチャ。大規模アプリケーションでは使えない？？？
これは誤解もいいところである。最近、超巨大なWebサイト（Web企業）が出現しているが、それらは例外なくMySQLを採用している。Facebook、Twitter、Mixi、Gree、はてな、ニコニコ・・・例を挙げればキリがない。特にFacebookはデータ量・トランザクション量は抜きんでて多く、単一のアプリケーションとしては現時点で地球上で最大規模のアプリケーションであると言って良いだろう。それでも彼らは運用当初から人的オペレーションに起因する（つまりオペミスによる）もの以外データロストに見舞われたこともないという。（こちらの解説を参考）このような大規模なWebサイトは、プロプラエタリなRDBMSをもってしても構築するのは至難の業だろう。これら大規模サイトの例は、如何にMySQLが管理しやすく性能や安定性に優れているかかということを示す証拠なのだ！それでもあなたはMySQLがオモチャだと言いますか？大規模アプリケーションでは使えないと言いますか？それとも人間辞めますか？
そのような都市伝説には喝！！である。
以上のようなとんでもない「都市伝説」達を紹介したが、それらの多くは「MySQLは使えない」といった意味の烙印を押すものであり、それはいずれも悪質なデマである。そのようなデマとは裏腹に、MySQLの実体は「高性能で」、「安定して」、「使い易い」と3拍子揃った優れたデータベース管理システムであり、現時点で最も大規模アプリケーションに向いていると言えるだろう。なので是非安心してMySQLを使って頂きたい！！
社内利用で訴えられる誤解が多いのは、MysqlがGPLと商用ライセンスの二つを用意しているからではないでしょうか？
返信削除以前、Postgresqlと見比べた時に商用ライセンスに拒絶反応を起こしたことがあります。
kiyoさん、
返信削除ちなみにですが、社内利用、つまり頒布を伴わない場合であればGPL版で一切の問題はありません。おそらくこれはMySQLに対する誤解というよりは、GPLに対する誤解でしょうね。ちなみに、GPL版でも商用サポートを受けられますし、商用のサブスクリプションを購入した際に提供されるバイナリのライセンスはGPLです。ただし、希望すれば無料でプロプラエタリ（商用）ライセンスへ変更できます。
社内利用での誤解は，ソフトエージェンシーなどのサイトにあるライセンスの説明のせいではないでしょうか？
返信削除以下のURLを見れば，社内利用を考えている人もコマーシャルライセンスを買えと読めます．
http://www.softagency.co.jp/products/mysql/license/
発売元がこういった表記をしているから，GPLでは問題ないはずだけど，ここから文句言われるんじゃないか，という不安が生じるのだと思います．
沢渡さん、
返信削除コメントありがとうございます。確かに2つめの設問「そのソフトのソースコードを引き渡しますか？」はGPL的にも間違っていますね。本来は、「そのソフトウェアを頒布しますか？」という設問にして、「No」を「GPLでご利用になれます」に繋ぐべきですね。
> サブクエリはとうの昔に（バージョン4.1において）搭載されている。
返信削除ちょっとこれは誇大広告のきらいがあるように思います。
http://dev.mysql.com/doc/refman/5.5/en/subqueries.html
にも記載されている
currently you cannot modify a table and select from the same table
in a subquery.
という制限は、かなりキツく、ふつうの RDB と同じようにサブクエリを
使おうとすると、よく問題になると思います。
あと、
> 社内利用でもGPL違反で訴えられる？？？
社内で別会社(協力会社)の方が作業しており、その方がMySQLのライブラリをリンクした
アプリケーションを利用している場合、その協力会社の人がソースコードを請求したら
開示しなければいけませんし、またその協力会社の人がソースコードを自由に再配布
することを妨げることもできません。
ある程度の規模の会社の場合、協力会社の方が作業しているケースが多いので、
この点にも注意が必要かと思います。
soda@sra.co.jp さん、
返信削除コメントありがとうございます。
> currently you cannot modify a table and select from the same table in a subquery.
> という制限は、かなりキツく、ふつうの RDB と同じようにサブクエリを
> 使おうとすると、よく問題になると思います。
そうですか？私はあまりこの点が問題になったということを聞いたことはありません。サブクエリで参照したのと同じテーブルを更新するパターンというのがイマイチイメージ出来ないのですが。WHERE句なら、更新するのと同じテーブルならそもそもサブクエリを使う理由がありませんし。SET句で更新の値として渡すのでしょうか？
> 社内で別会社(協力会社)の方が作業しており、その方がMySQLのライブラリをリンクした
> アプリケーションを利用している場合、その協力会社の人がソースコードを請求したら
> 開示しなければいけませんし、またその協力会社の人がソースコードを自由に再配布
> することを妨げることもできません。
これはとんでもない誤解です。
GPLのライブラリをリンクしてソフトウェアを開発した場合、ライブラリ以外の部分の著作権は、そのソフトウェアを開発した人のものです。もし開発したソフトウェアでGPLのライブラリやGPLのソースコードを利用していると、そのソフトウェアをGPLにしなければなりませんが、それは、ソフトウェアを頒布する場合に適用されます。つまり、開発中は頒布しないので、GPLは関係ありません。協力会社の人が委託を受けて開発する場合、そのソフトウェアの著作権保有者は依頼主です。従って、協力会社の人が勝手にそのソフトウェアを、著作権者（持ち主の）了承無しに頒布したら犯罪となります。
細かい話になりますが、自前で開発した部分は、組み合わせる場合の状態であれば、GPL以外のGPL互換のライセンス（new-BSDやMITなど）を適用することも可能です。もちろん、GPL互換のライセンスでなければなりませんので、プロプラエタリなライセンスは利用できません。
しかし、社内利用ならばソフトウェアの頒布は発生しませんので、上記のようなライセンスの問題は一切発生することがないのです。
> サブクエリで参照したのと同じテーブルを更新するパターンというのがイマイチイメージ出来ないのですが。
返信削除私が引っかかったのは、以下のような SQL 文でした。
DELETE FROM greylist WHERE ip IN ( SELECT ip FROM greylist WHERE sender='necojp@citiz.net' )
> これはとんでもない誤解です。
失礼しました。
確かに「利用している場合」というのが、たとえばMySQLをリンクした
Webアプリケーションを、協力会社の人がPCのブラウザから利用している
といった場合であれば、おっしゃる通りで問題ありません。
あるいは、あらかじめ社内のコンピュータにインストールしてある、
MySQLライブラリとリンクされたプログラムを利用する場合も、
おっしゃる通りで問題ありません。
不用意に「利用している場合」という言葉を使ったのは私の誤りでした。
失礼しました。
ただ、GPLが適用されるのは「頒布」のみならず、「複製」も含まれます。
たとえば、MySQLライブラリとリンクされたアプリケーションプログラム
を、社内ネットワークから、協力会社の資産であるPCにダウンロードして
インストールし、実行した場合、「複製」が行なわれていることになりま
せんか？ この場合は、GPLが適用されるのでは？
少なくとも、普通の商用ソフトウェアの場合、この行為はソフトウェアの
複製と見なされますよね？
soda@sra.co.jp さん、
返信削除> DELETE FROM greylist WHERE ip IN ( SELECT ip FROM greylist WHERE sender='necojp@citiz.net' )
とても具体的な例を示して頂きありがとうございます。（メールアドレスが含まれていますが公開してしまっても大丈夫でしょうか？）
確かにこのパターンだと単純なDELETE文だと解決できず、サブクエリが必要になってしまいますし、例の制限にひっかかってしまいますね。（一応、MySQLだと以下の様な書式でサブクエリを使わずに処理できますが。）
DELETE t1 FROM greylist AS t1, greylist AS t2 WHERE t1.ip = t2.ip AND t2.sender='necojp@citiz.net';
> ただ、GPLが適用されるのは「頒布」のみならず、「複製」も含まれます。
> たとえば、MySQLライブラリとリンクされたアプリケーションプログラム
> を、社内ネットワークから、協力会社の資産であるPCにダウンロードして
> インストールし、実行した場合、「複製」が行なわれていることになりま
> せんか？
細かい話になってしまいますが、先ほども申し上げた通り、自作した部分の著作権は、そのソフトウェアを開発した人のものです。頒布する予定がなければ、開発を委託された人が勝手にGPLを適用することは出来ません。つまり、委託された業者の人がコピーするのは、「GPLのライブラリ」と「GPLが適用されていないソフトウェア」となるのです。
また、GPLが守るのはソフトウェアの著作権なので、コンピュータ内で単純に「cpする」ような場合とは区別して考えるべきですね。
よくぞ書いてくれたって記事です。
返信削除数年前までのMySQLのイメージのままの技術者が多いことに本当に驚いています。
私の場合、日本最大のSNDでも利用されている信頼性のあるシステムなんですよってことを説明して、次にトランザクションもあるんです、関数だって、トリガーだって、レプリケーションも普通につかえるんですって言ってます。
ほかのDBMSに比べてOSやファイルシステムに依存しない論理ファイルでリロケータブルってのも付け加えるようにしてます。
本当はHotBackupは数万円というのも言いたいんですけど、それはちグッとこらえてますｗ
hirano_2475 さん、
返信削除コメントありがとうございます。
技術者にとって、知識をリフレッシュするのは一つの課題ですからね。先入観を捨て去るのはとても難しいです。この手の話は小難しく書いても誰も聞いてくれないと思ったので、このエントリはノリノリ（死語）で書きましたｗ ちょっと調子に乗りすぎな気もしますが。
先日某勉強会に行ってきたのですが、そこでも相当な技術者の方が
返信削除「トランザクションがない！」
「大規模アプリには使えない！」
「更新を繰り返すとファイルが巨大化する！」
だからMySQLは使えない！！と断言してました。(´・ω・｀)
最初の二つはいいとして、最後のひとつはどうなんでしょうか？
個人的には SQLServer の方がよっぽどログが肥大化するように思えるのだが・・・
ひらぽんさん、
返信削除コメントありがとうございます。
ははは、あり得ないですね。そんなこと言う人は全員渇を入れないといけないですね！！
ちなみに、
> 「更新を繰り返すとファイルが巨大化する！」
については、インデックスのつけかたと値の偏り方次第です。InnoDBのインデックスは16KBごとのページに分けられて管理されているので、フラグメンテーションを0にすることは出来ませんが、更新によってテーブルが肥大化するというのはFUDだと言っていいでしょう。特に、インデックス値が更新されない場合にはテーブルのデータサイズ（＝ページ数）に変更が生じない可能性が高いです。例えば次のようなクエリとか。
UPDATE tbl SET non_key_col = 12345 WHERE pk_col = 123;
SQL Serverという製品名が飛び出しましたが、参加されたのはSQL Serverの勉強会だったのでしょうか。
返信ありがとうございます。
返信削除> SQL Serverという製品名が飛び出しましたが、参加されたのはSQL Serverの勉強会だったのでしょうか。
こちらの勉強会です。
http://www.wankuma.com/
IT中心で何でもありの勉強会です。
幅広い技術者が集まってますが、どちらかというと、MS寄りのエンジニアが多いかな。
たまにオラクルの中の人やMS の中の人も来ています。
ちなみにこの話をしてたのは、誰とはいいませんが、MS より MVP の称号をもらってる人です。
だれでも参加オッケーなので、一度渇を入れに来られてはいかがでしょう。。。(^^;
ほほう。普段私が接点のなさそうな人が目白押しですね。このサイトの存在自体今知りましたし。MySQLはWindowsでも動きますし、誤った知識は改めて頂きたいものです。その人の面子を潰すのもなんなので、こっそりとこのエントリを教えてあげて下さい ;)
返信削除