InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
DB移行の7つのステップ
データベース移行ではどのような作業を行わないといけないのか？全体的な流れを俯瞰的に見なければ、作業の見積もりなどが難しいことだろう。というわけで、今日はデータベース移行時に必要になる作業について7つのステップに分けて紹介しようと思う。言うまでもないことであるが、移行時には既存システムを直接いじるわけではない。（稼働中のシステムを直接いじるのは、走ってるクルマに乗り込むのと同じぐらい危険な行為である！！）開発用のシステムを別途用意して作業を進めるという前提で読んで欲しい。 1. データベース構築まずは何はともあれ新規データベースを構築することである。MySQLであれば典型的な構成にしておけばそれなりに高速に動作するので、細かいチューニングは後で問題が出てからやれば良い。my.cnfはインストールディレクトリの下のsupport-filesディレクトリにあるものを弄ってもいいし、MySQL P
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
書評：「7つのデータベース 7つの世界」
訳者、角 征典氏より献本御礼。「7つのデータベース 7つの世界」はそのタイトルの通り、7種類のデータベースソフトウェアについて解説したNoSQLの道標とも言うべき書籍である。7種類のデータベースとして紹介されているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4j、Redisである。本書は非常にそそるタイトルであり、わくわくしながらページをめくった。だが、第2章「PostgreSQL」で期待感は打ち砕かれることになる。 正直なところ、この書籍について書評を書くのはどうしようか迷ってしまった。なぜならば、第2章の説明がかなり間違っているからである。そのため、書評を書こうとするとどうしても辛口にならざるを得なかった。献本して頂いた角氏にその旨を伝えたところ、それでも良いと快く了承して頂いた。本当に辛口になるのでその点は容赦して頂きたい。 何が問題なのか
最高の土管が欲しい
筆者は1年半ほど前に携帯のキャリアをドコモへ変更した。それまではソフトバンクを使っていたのだが、筆者の生活圏との相性が良くなかったようで、電波の状況が芳しくなかったのだ。ドコモへ変更してからは電波状況は満足のいくものとなった。しかし電波状況以外の問題で返って不満が募る結果となってしまった。なぜか？ひと言で表すとサービスに制約が多すぎるからだ。様々な不満を心に抱いていたところ、次のようなニュースが報じられた。 ドコモ社長「米アマゾンになる」 来年度からモバイル通販で野菜、健康機器など販売 - SankeiBiz（サンケイビズ） このニュースには閉口せざるを得ない。不満が爆発してしまいそうなので、ここらへんでひとつぶちまけてみようと思う。 IMEI規制 まず一つ目の問題は、それまで使用していたSIMロックフリー端末が使えなくなってしまったということだ。正確にいうと使用できるのだがデータ通信費が
受託開発とGPL
GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対
オープンソースでお金を稼ぐ方法いろいろ。
オープンソースソフトウェア（以下OSS）が広く使われるようになって久しい。ご存じの通りOSSは無償で入手できるものばかりであるため、多くの人が疑問に思うことがひとつある。それは、「OSS開発者はどこから収入を得ているのか？」ということだ。収入源の実体がよく分からないために「霞を食って生きているのか？」などと揶揄されることもある。実際OSS開発者は「どうやって収入を得るか？」ということについて色々と悩んでいる場合も多かったりするのだが、実はOSSには様々なビジネスモデルも存在する。そんなわけで、今日はOSSを活用して収入を得る様々な方法について詳解しよう。OSS開発者になることに躊躇している人の背中を後押しすることが出来れば幸いである。 プロプラエタリソフトウェアのビジネスモデルまずはおさらいである。OSSのビジネスモデルについて考える前に、プロプラエタリソフトウェアのビジネスモデル（特にラ
真の自由とは？フリーソフトウェアにおける究極の選択。CopyleftかPermissiveか。
オープンソースソフトウェアにとって、ライセンスが何であるかというのは非常に大切なことである。なぜならば、ソフトウェアのライセンスの種類によっては、組み合わせることができるものと、そうでないものがあるからだ。ソフトウェアの利用制限がない「自由なライセンス」として有力なものの中には、Copyleftと呼ばれる種類のものとPermissiveと呼ばれる種類のものがある。いずれも、フリーソフトウェアライセンスとして定義されているライセンス形態であり、Copyleftで代表的なものにはGPL（GNU Public License）、Permissiveの代表格としてはBSDLやMIT Licenseなどが挙げられる。これらは一体全体どちらが真に自由をもたらすソフトウェアライセンスなのであろうか？ CopyleftライセンスGPLでは「ソフトウェアの自由」を以下のように定義して、これが守られるようにC
漢(オトコ)のコンピュータ道
※この記事はMySQL Advent Calendar 2023の4日目です。 MySQL 8.0シリーズでは正式版になってから多数の新機能が追加されるというリリースモデルであった。正式版になってから追加された新機能の中に、GIPK（Generated Invisible Primary Key）というものがある。これはなんとMySQL 8.0.30で追加された機能だ。MySQL 8.0が正式版になってから、なんと4年と3ヶ月後のことである。そんな感じでMySQL 8.0の新機能は正式リリース後にも増え続け、途方もない規模になっている。このブログでは一度に紹介するのは諦め、少しずつ気の向いたものから紹介していこうと思う。今回はその第一弾として、GIPKについて解説しよう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
