EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

1. 高性能・安定運用のための Linux/DB システム構築 / 運用技術 松信 嘉範 (MATSUNOBU Yoshinori) サン・マイクロシステムズ株式会社 プリンシパル MySQL コンサルタント 2. プロフィール 2006 年 9 月から MySQL->Sun(-> オラクル ) で MySQL コンサルタントとして勤務 主な著書 Linux-DB システム構築 / 運用入門 現場で使える MySQL Java データアクセス実践講座 Twitter: matsunobu Blog: http://opendatabaselife.blogspot.com * 今回の資料は公開します * MySQL 用語があちこちに出ますが、 経験の無い方にも分かるように配慮していくつもりです 3. 安定稼働と高性能を支える要素 アプリケーション層に関する技術 テーブル設計、インデックス設

MySQLはとても気ぃつかい屋さんである。我々が投げる多少あいまいな指示も頑張って解釈し、なんとか文句を言わずに実行してみようと挑戦してみてくれる。 今日はそんなMySQLがケナゲに解釈してくれる自動変換について紹介しようと思う。この自動変換、ケナゲなMySQLの奥ゆかしさ故、出した指示と異なる動作をされたことに気がつかないことがある。ここで紹介する６つの自動変換をしっかり脳ミソにたたき込んでおけば、無用なトラブルにハマる時間も減るかもしれない。 １．[数値] 範囲外の数値は頭を押さえつけられる intやsmallint、bigintなどの数値型には、扱える範囲が決まっている。例えばint型なら最大21億ちょっとだ（unsignedの場合は43億弱）。これより大きい数字を登録するよう指示を出すとMySQLはどうするか。そう、頑張って入れられるところまで入れてくれるのである。「入れられるとこ

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

1. <Insert Picture Here> MySQL 日本語利用徹底入門 日本オラクル株式会社 MySQL Global Business Unit テクニカルアナリスト 奥野幹也 2012 年 5 月 29 日 Copyright© 2012, Oracle. All rights reserved. 2. 2 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。ま た、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはでき ません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確 約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オ ラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊 社の裁量により決定されます。 Oracle と Java は、 Oracle Cor

随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例（漢バージョン）を紹介しよう。実は質問を掲載した際「難しい！」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日本を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった！！ そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある？ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー

今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿

最近@namikawaさんと@con_mameさんがEBSの性能測定をされていて、少し気になったので追試をしました。 Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々 Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編) - 元RX-7乗りの適当な日々 Amazon EBS の性能ベンチマーク その3 (Provisioned IOPS編) - 元RX-7乗りの適当な日々 4,000IOPS EBSのベンチをとってみた - まめ畑 今一度Provisoed IOPS EBSのベンチをとってみた - まめ畑 測定環境です。 ap-northeast-1c m1.small (Spot Instance) Amazon Linux AMI 2013.03.1 EBS Standard Volume 16GB

MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう

よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし

以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ

1. MySQLの 文字コード とみたまさひろ 2011-04-29 MySQLの文字コード Powered by Rabbit 0.9.2 2. 自己紹介 ✓ とみた まさひろ ✓ プログラマー ✓ mailto:tommy@tmtm.org ✓ http://d.hatena.ne.jp/tmtms ✓ http://twitter.com/tmtms 1/36 MySQLの文字コード Powered by Rabbit 0.9.2