tree-tips: MySQLのlock in share mode | MySQL
lock in share modeとは？ lock in share modeは、共有ロック・shared lock・slock、と言われているロックです。 for updateは、排他ロック・xlock、と言われています。 参照(select)する時にロックをする機能です。 lock in share modeはどんな時に使う？ 主な使い道は、ファジーリード・ロストアップデートを防ぐ、です。 ファジーリードはトランザクション分離レベルがread committed以下の場合の発生します。repeatable readの場合はそもそもANSI/ISO SQLの仕様上発生しません。 具体的な使い所としては、一覧画面の表示時のSQLや、不正データ検出、等で使うかと思います。 for updateとの違いは？ 最大の違いはslockによる参照をブロックしない・されない点です。つまり、参照同士の
MySQLのINSERT/UPDATE時におこる不整合対策 - LukeSilvia’s diary
先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。 同時に存在してはいけないはずのデータが、DB に存在する 整合性のチェックはアプリケーションレベルで行っている 一意制約のような単純なものではないので、アプリケーションレベルで実装 整合性のチェックロジックは正しい これに対し、バグは次のような状況で発生したと仮説を立てました。 ユーザがレコードを一括登録しようとする 登録ボタンを押したがレスポンスが遅い この間、整合性チェックが走っている ユーザはもう一度登録ボタンを押した 2回目の登録の整合性チェックが走り始める 1回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した 結
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
Forecasting MySQL Scalability with the Universal Scalability Law
All of Percona’s open source software products, in one place, to download as much or as little as you need.
オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
QA＠IT サービス終了のお知らせ - ＠IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
MySQL InnoDBのネクストキーロック おさらい - SH2の日記
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。 mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。 mysql> set tx_isolation = 'repeatable-r
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.10.3 InnoDB と TRANSACTION ISOLATION LEVEL
Section Navigation [Toggle] 13.5.10 InnoDB トランザクション モデルとロック13.5.10.1 InnoDB ロック モード 13.5.10.2 InnoDB と AUTOCOMMIT 13.5.10.3 InnoDB と TRANSACTION ISOLATION LEVEL 13.5.10.4 一貫非ロック読み取り 13.5.10.5 SELECT ... FOR UPDATE と SELECT ... LOCK IN SHARE MODE ロック読み取り 13.5.10.6 ネクスト キー ロック:バグの問題を防ぐ 13.5.10.7 InnoDB 内での一貫した読み取りの例 13.5.10.8 InnoDB 内で各種 SQL ステートメントによって設定されるロック 13.5.10.9 暗黙的なトランザクション コミットとロールバッ
MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 9.8.4 InnoDB レコード、ギャップ、およびネクストキーロック
レコードロック: これはインデックスレコードのロックです。 ギャップロック: これはインデックスレコード間にあるギャップのロック、先頭のインデックスレコードの前や末尾のインデックスレコードのあとにあるギャップのロック、のいずれかです。 ネクストキーロック: これはインデックスレコードに対するレコードロックと、そのインデックスレコードの前にあるギャップに対するギャップロックとを組み合わせたものです。 レコードロックでは、テーブルにインデックスが定義されていなくても必ず、インデックスレコードがロックされます。そのような場合には InnoDB によって隠しクラスタインデックスが作成され、このインデックスを使ってレコードロックが行われます。項9.10.1. 「クラスタインデックスと二次インデックス」 を参照してください。 デフォルトでは、InnoDB は REPEATABLE READ トランザク
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.16 情報関数
BENCHMARK(count,expr) BENCHMARK() 関数は、式 expr を count の回数だけ繰り返し実行します。 MySQL による式の処理速度を計測する際に使用される場合もあります。 NULL や負の繰返し回数などの不適切な引数の場合、結果値は 0 または NULL です。 この使用目的は、mysql クライアント内から、クエリーの実行時間をレポートすることです。 mysql> SELECT BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye')); +---------------------------------------------------+ | BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye')) | +-----------------------------
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.1 数値データ型
MySQL はすべての標準 SQL 数値データ型をサポートします。 これらの型は、概数値データ型 (FLOAT、REAL、DOUBLE PRECISION) だけでなく、真数値データ型 (INTEGER、SMALLINT、DECIMAL、NUMERIC) を含みます。 キーワード INT は INTEGER のシノニムで、キーワード DEC および FIXED は DECIMAL のシノニムです。 MySQL では、DOUBLE は DOUBLE PRECISION (非標準の拡張) のシノニムと見なされます。 また、REAL_AS_FLOAT SQL モードが有効でないかぎり、REAL は DOUBLE PRECISION (非標準のバリエーション) のシノニムと見なされます。 BIT データ型はビット値を格納し、MyISAM, MEMORY, InnoDB および NDB テーブルでサ
漢(オトコ)のコンピュータ道
※この記事は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について解説しよう。
MySQL演算子・関数
MySQLの演算子や関数について説明します。 なお、個人的に必要無いと思うものについては省略しています(笑)。 MySQL5.0.16対応 最初に MySQLでは、数値⇔文字列の変換は自動的に行われます。 SELECT 100 + '200' -> 300 SELECT 100 < '200' -> 1 (TRUE) SELECT 100 < '22' -> 0 (FALSE) 比較演算子 比較演算の結果は、1(TRUE) / 0(FALSE) / NULL のいずれかになります。 例を挙げます。 SELECT 1 = 1 -> 1 SELECT 1 = 3 -> 0 SELECT 1 = NULL -> NULL SELECT NULL = NULL -> NULL 最後の結果に注意して下さい。 どのデータベースにも共通して言えることですが、NULLという値は 特別な意味を持ちます。 N
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
MySQLパフォーマンスチューニングのためのインデックスの基礎知識 - 久保清隆のブログ
仕事でMySQLのパフォーマンスチューニングをしていて、インデックスについて分かっていないことが多かったので調べたことをメモ。基本的なところから学習しなおした。 MySQLのインデックスは、カラムが特定の値をもつレコードの迅速な検索に使用される。インデックスを使用すれば、数百とか数億ものレコードが入っているテーブルから、一組のレコードを迅速に見つけて取り出すことが可能になる。 しかし、インデックスは速度を改善することもあるが、挿入の邪魔になって遅くなることもある。 インデックスを適切に使うために、まずはインデックスの基本概念をおさえる必要がある。 インデックスの概念 インデックスとは インデックスの仕組みを理解するには、まずMySQLがどのようにクエリに応答するかを知る必要がある。 例えば、 SELECT * FROM phone_book WHERE last_name = 'Hoge'
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
KLab
https://labs.cybozu.co.jp/blog/kazuho/archives/2008/06/friends_timeline.php
[Mac]MySQLのmy.cnfのデフォルト設定ファイル | うえちょこ＠ぼろぐ