EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。
このエントリはMySQL Casual Advent Calendar 2015の10日目のエントリです。 先日のMySQL Casual Talks Vol8で@karupaneruraさんがパラメータの振り返りのような発表をされていたので、昨今あまり書かれなくなったMySQLに絡む設定パラメータについて書きます。それなりのメモリ(32GBとか)やSSDとか使ってる事を前提にしたような内容となります。 依存して変更した方が良いパラメータもあるので内容が前後に飛びますがご容赦下さい。またソースコードをがっつり読んだわけではなく、ベンチマーク中の挙動から推測している箇所が多分にあります。MyISAMのテーブルがサービス用データベースに同居する事を考慮していません。 結構突貫で書いているので後から微妙に修正する可能性があります。 InnoDBのパラメータ innodb_buffer_pool_
Linux/Unix/Open Source Software related Mailing-List Log http://MLog.euqset.org/ 試験運用中 [mysql 14161] Re: 制約の確認について 平塚様、 丸一日かけて出てこなかった答えをありがとうございます。情けないやら嬉しいやら です。 すばらしいです。すみませんでした。大変助かります。 みょうつぞの -----Original Message----- From: HIRATSUKA Sadao [mailto:hiratsuka.sadao@xxxxx] Sent: Wednesday, August 08, 2007 6:11 PM To: ml@xxxxx Subject: [mysql 14160] Re: 制約の確認について 平塚です。 > oracleでいう > d
Linux/Unix/Open Source Software related Mailing-List Log http://MLog.euqset.org/ 試験運用中 [mysql 14353] Re: InnoDBテーブルのテーブルスペース容量計算 木下と申します。。。 私自身4.0以前は利用したことが無いので、正確な原因は分りませんが、 Data_lengthが見積もりよりもかなり大きくなってしまう主な原因は、 レコードを主キーに対してランダムな順番で挿入しているからだと思います。 InnoDBにおける表の構造は主キーの索引構造になっていますので、 ランダムな順番での挿入はフラグメンテーションが多発してしまい、 Data_lengthは無用に大きくなってしまいます。 また、挿入自体の性能も索引構造の更新やレコードの再配置なども伴うため、 良くありません。
Section Navigation [Toggle] 8.9.1 The InnoDB Buffer Pool8.9.1.1 Resizing the InnoDB Buffer Pool Online As of MySQL 5.7.5, the innodb_buffer_pool_size configuration option can be set dynamically, which allows you to resize the buffer pool without restarting the server. For example: mysql> SET GLOBAL innodb_buffer_pool_size=2147483648 The resizing operation is performed by a background thread.
1 Copyright 2007 MySQL AB The World’s Most Popular Open Source Database InnoDBのパフォーマンスチューニング (前編) 松信 嘉範(MATSUNOBU Yoshinori) MySQL株式会社 シニアコンサルタント ymatsunobu@mysql.com 2 Copyright 2007 MySQL AB The World’s Most Popular Open Source Database 今回のカバー内容 • パラメータ設定の指針 • テーブル設計の指針 • MySQL 5.1以降での強化内容 • ハードウェアの選定指針 • 様々なTips ※順不同です 3 Copyright 2007 MySQL AB The World’s Most Popular Open Source Database Inno
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
Section Navigation [Toggle] 9.8 InnoDB トランザクションモデルとロック9.8.1 InnoDB ロックモード 9.8.2 一貫性非ロック読み取り 9.8.3 SELECT ... FOR UPDATE と SELECT ... LOCK IN SHARE MODE ロック読み取り 9.8.4 InnoDB レコード、ギャップ、およびネクストキーロック 9.8.5 ネクストキーロックによるファントム問題の回避 9.8.6 InnoDB 内で各種 SQL ステートメントによって設定されるロック 9.8.7 暗黙的なトランザクションコミットとロールバック 9.8.8 デッドロックの検出とロールバック 9.8.9 デッドロックにどのように対処するか ロックする読み取り、UPDATE、または DELETE は通常、SQL ステートメントの処理の中で走査
前の節で説明したように、InnoDB は AUTO_INCREMENT カラムを含むテーブルへの挿入を行う際に、AUTO-INC ロックと呼ばれる特殊なテーブルレベルロックを使用します。このロックは通常、(トランザクションが終了するまでではなく) ステートメントが終了するまで保持されますが、これは、与えられた一連の INSERT ステートメントに対する自動インクリメント番号が、予測可能かつ繰り返し可能な順番で割り当てられることを保証するためです。 ステートメントベースのレプリケーションの場合、これは、ある SQL ステートメントがスレーブサーバーで複製される際に、自動インクリメントカラムでマスターサーバーと同じ値が使用されることを意味します。複数 INSERT ステートメントの実行結果は決定性のものとなり、マスターと同じデータがスレーブで再現されます。もし複数の INSERT ステートメン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く