DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識 - CARTA TECH BLOG
みなさん、おはようございます！ CARTA fluct エンジニア の なっかー@konsent_nakka です。 CARTA TECH BLOG アドベントカレンダー 12/14ということで、普段DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識をざっとまとめてみました。 とりあえずこれだけ読んでおけば最低限は困らない、もし何か困った時にはあそこで出てきた内容をもう少し深く調べて見るか、というきっかけになれば良いなと思います。 厳密な定義よりも普段DBを扱う中でロックについてあまり意識したことがないような人にもすっと入ってくるように簡単な表現を優先して書いていますがご了承ください。 目次 留意事項 排他ロックと共有ロック トランザクション分離レベル SELECTのロックレベルを変更する 共有ロック: LOCK IN SHARE MODE 排他ロ
MySQLとインデックスと私
2021/05/24 サイボウズ開運研修 動画が以下のサイトからリンクされています - https://blog.cybozu.io/entry/2021/07/20/100000 - これに矢印を書きながらぐりぐりやっていたわけなので、資料単体だとわかりづらいと思います…
「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターン
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
トランザクション分離レベルについてのまとめ - Qiita
※ InnoDBはREPEATABLE READでもファントムリードが発生しません。 MySQLで実際に試す MySQL(InnoDB)でトランザクション分離レベルを実際に試してみます。 準備 プレイヤーのコイン数を表す簡単なテーブルを作ります。 テーブル構造は次のようになります。 テーブルにplayer1とplayer2のデータを追加します。 2つのターミナルからMySQLに接続します。クライアントAとクライアントBとします(以下はAとBと呼ぶ)。 これで準備は完了です。 READ UNCOMMITTED READ UNCOMMITTEDは一番低いレベルです。 コミットされていない変更を他のトランザクションから参照できる設定です。 ① Aで現在接続中のセッションのトランザクション分離レベルをREAD UNCOMMITTEDに設定して、テーブルを検索します。 ② BでREAD COMMIT
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編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
【MySQL5.6->5.7】 とてもたくさんの列をもったテーブルをつくりたい／Row size too large (> 8126)についてかんがえる - Qiita
【MySQL5.6->5.7】 とてもたくさんの列をもったテーブルをつくりたい／Row size too large (> 8126)についてかんがえるMySQL ■ はじめに 現実を前にして正規化などといった理想を捨て去ったとある人は、 とある日とあるスキーマに全知全能の神を降臨させようと画策した。 すなわちTEXT型の列を大量に備えたテーブルを用意して、 あらゆる情報と状況を何とかしてもらおうと企図したのだった……！！ ■ やってみる MySQL5.6を実行できる環境を用意して、 とりあえず以下のようなCREATE TABLE文を叩いてみる。 mysql> CREATE TABLE zeus ( -> col1 TEXT -> , col2 TEXT -> , col3 TEXT -- 中略 -> , col195 TEXT -> , col196 TEXT -> ) ENGINE=I
株式会社Go-Next | お客様にビジネスの成長と革新を
今日も生まれる感動と笑顔 お客様の事業、戦略、Webサイトの現状などを把握し、最適な施策を立案・実行します。 more info Top Message インターネットテクノロジーの需要が高まり、その必要性と可能性を感じ2005年に創業して以来、現在に至るまでステークホルダーの皆さまに支えていただきながら成長を続けてまいりました。「ITとクリエイティブのチカラで、心沸き起こるプロダクトを生み出す」ことをミッションに掲げ、さらなる充実したチカラ溢れる未来の実現を目指します。私たちの強みは、企画戦略からシステム開発、Webアプリケーション開発、クリエイティブ、コンサルティングに渡るワンストップソリューション提供とオーナーシップマインドを両立することにより、より精度の高い、顧客満足度の高いアウトプットと課題解決を達成します。また、創造性の向上、生産性の向上、コストの削減といった意識、文化を育むた
MariaDB(MySQL) - 既存 InnoDB ファイルフォーマットを Antelope から Barracuda に変換！
MariaDB(MySQL) の既存 InnoDB ファイルフォーマットを Antelope から Barracuda に変換する方法についての記録です。 0. 前提条件 当方は MariaDB 10.0.20 で動作確認を行なったが、別のバージョンや MySQL でも同様。 InnoDB ストレージエンジンを使用する設定にしている。（必須） InnoDB データファイルをテーブルごとに作成するシステム変数 innodb_file_per_table を 1（有効） にしている。（必須） 不測の事態に備えてデータのバックアップ（ダンプ）をとって作業を行うこと。（重要） 1. InnoDB ファイルフォーマットについて InnoDB ファイルフォーマットの設定は MariaDB(MySQL) システム変数 innodb_file_format で行うが、設定していなければ Antelope
MySQL5.6 innodb_file_formatをAntelopeからBarracudaにオンラインで切り替える
遅くなったVPNサーバのレスポンスを少しでも改善すべく、MySQL5.6のパフォーマンス改善を目指してinnodb_file_formatをBarracudaに切り替えてみました。 1. my.cnfファイルにinnodb_file_formatの行を追加する my.cnfはmysqldを再起動しないと反映されませんが、とりあえず先に追加しておきます。 innodb_file_per_tableはBarracudaに変更するための必須設定ですが、InnoDBへ変更した際に設定済なのでこの場での説明はパスします。 # vi /etc/my.cnf [mysqld] innodb_file_per_table = 1 + innodb_file_format = Barracuda + innodb_file_format_max = Barracuda 2. オンラインで対応フォーマットをB
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.4.7 テーブルカラム数と行サイズの制限
MySQL にはテーブル当たり 4096 カラムの強い制限がありますが、特定のテーブルの有効な最大値が少なくなる可能性があります。 カラムの正確な制限は、いくつかの要因によって異なります: すべてのカラムの合計長がこのサイズを超えることはできないため、テーブルの最大行サイズによってカラムの数 (および場合によってはサイズ) が制限されます。 行サイズ制限を参照してください。 個々のカラムの記憶域要件によって、指定された最大行サイズ内に収まるカラム数が制限されます。 一部のデータ型の記憶域要件は、記憶域エンジン、記憶域形式、文字セットなどの要因によって異なります。 セクション11.7「データ型のストレージ要件」を参照してください。 ストレージエンジンは、テーブルカラム数を制限する追加の制限を課す場合があります。 たとえば、InnoDB には、テーブル当たり 1017 カラムの制限があります。
InnoDBの制限とファイルフォーマットAntelopeとBarracudaの違い - かみぽわーる
この投稿はMySQL Casual Advent Calendar 2014の5日目の記事です。 @kamipo 質問させてください。このエントリーで COMPRESSED ではなく DYNAMIC を選んでいる理由はなぜですか？あまりDB詳しくないので参考リンクなどポインタを教えていただけるだけでも構いません http://t.co/9sC4lzLjXr— kiyoshi nomo (@kysnm) November 27, 2014 先週ツイッターでInnoDBのことを質問されまして、せっかくなのでアドカレのネタにしようと思いますってことでInnoDBのファイルフォーマット毎の違いをカジュアルに説明しようと思います。 InnoDBのファイルフォーマットBarracudaと新機能 InnoDBにはファイルフォーマットとして昔からあるAntelopeと新しいフォーマット(5年も前からあるの
InnoDBの8KBの壁にぶち当たったら。 – sawara.me
InnoDBの行の最大長は約8KBらしい。 意外と少ない。。。 運用中のサービスがこんなエラーを吐いていました。。。 [code gutter=”false”] Got error 139 from storage engine [/code] マジですか。これが噂の「InnoDB 8KBの壁」ですか。。。 設計段階であればテーブル縦分割とかテーブル構造自体を変えちゃえ！ってなるかもしれないですが、運用中のサービスですし、できるだけ全体へのインパクトは少なくしたい(アプリケーションは改修したくない)。って時にテーブルのROW_FORMATを変更して対応しましたよ、って話です。 「ROW_FORMAT=DYNAMIC」または「ROW_FORMAT=COMPRESSED」を使おう！ そうです、結論から言ってROW_FORMATを変更することで対応したんです。 ROW_FORMATについてMyS
MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
(帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
MySQLバックアップ・リカバリ
© 2005 Sony Global Solutions Inc. 2005 3 26 (MATSUNOBU Yoshinori) © 2005 Sony Global Solutions Inc. � � MySQL � � � � � mysqldump � FLUSH TABLES WITH READ LOCK � � � � © 2005 Sony Global Solutions Inc. (4.1 ) ( ) SSL SSL VPN(SSH ) ( ) (InnoDB ) (InnoDB ) SQL92 SQL99 Core 4.1 5.0 SQL InnoDB MyISAM ( ) B-Tree ( 5.0 ) 4 (InnoDB ) C/C++( ) Linux,Solaris,HP-UX,AIX,Windows © 2005 Sony Global Solutions I
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
競馬で使える馬券術と指数分析｜日曜の夜をストレスなく過ごすための馬券術
http://www.2ch-search.net/blog/3
unixlife.jp