正確な最大長がわからないときの最小かつ十分なサイズの値ってどう決めるのが良いのだろうーと思ってつぶやいてみたところ、多くの方々に返信いただけました。ありがとうございます。
MySQLのVARCHARサイズについて
正確な最大長がわからないときの最小かつ十分なサイズの値ってどう決めるのが良いのだろうーと思ってつぶやいてみたところ、多くの方々に返信いただけました。ありがとうございます。
外部キー制約に伴うロックの小話
4. ロックおさらい（簡易） • 共有ロック（LOCK_S） 共有ロック同士は互いにブロックしない 例：SELECT LOCK IN SHARE MODE • 排他ロック（LOCK_X） 何も受け付けないぞ、排他 例：INSERT(成功), UPDATE, DELETE, SELECT FOR UPDATE X S X Conflict Conflict S Conflict Compatible 4 大きく分けてロックは2種類 5. 5 > BEGIN; > SELECT * FROM player WHERE id = 100 LOCK IN SHARE MODE; > BEGIN; トランザクションA トランザクションB 共有と排他順によるデッドロック例 6. 6 > BEGIN; > SELECT * FROM player WHERE id = 100 LOCK IN SHARE MO
MySQLのデッドロック対処 おまけでギャップロック
タグ 保湿RTX1210VagrantVirtualBoxAnsibleLarabelClamAVCentOS7SWX2200ゆるいハッキング大会RTX1100MySQLPlesk12おりょりょんNFSPostfix基板修理linux 入門atomゆるいハッキングDrupalVisual Studio 2017RabbitMQMVCAsteriskベンチマークBINDGitMastodonwindows10GeoIPApacheAWS S3AWS CLIFuelPHPVulsH2OSSHFSAWS EFSZabbixRDPELBロードバランサsshバックアップ負荷分散AWS EBSCybozu Office10ElasticsearchSWX2300LogstashKibanaLaravelKubernetes仕事猫現場猫ゆるいハッキングセミナーALBDNSConoHa Vlanデッドロッ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編） こんにちは nob です。 前編 これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） の記事から１年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を（システム編）としてお届けいたします！ 今回の（システム編）で紹介するツボは 4 つです。（クエリ編）のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 （ツボ１）Load Average < (1 + (cpu数-1)/3) （ツボ２）Checkpoint Age が水平線になったら要注意 （ツボ３）MyISAM は無いよね監視 （ツボ４）万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.6.5.2 構成可能な InnoDB の自動インクリメントロック
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
InnoDB Monitorの仲間たち（InnoDBエンジン本体のアレ）
InnoDBストレージエンジンには InnoDB Monitor という機能があって、 だいたい`SHOW ENGINE INNODB STATUSの結果をエラーログファイルに定期的に吐き出してくれる'というイメージがある。 mysql> CREATE TABLE innodb_monitor ( hoge int ); $ tail -f error.log ===================================== 130306 10:09:30 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 20 seconds ----------------- BACKGROUND THREAD ------------
chiba.pm 2回目に行ってきた #chibapm - 目の前に僕らの道がある
行ってきた。 http://atnd.org/events/36981 自分の観測範囲だと総武線沿いというか千葉方面で勉強会があまりないので、chiba.pmはすごいありがいたいです。 ゆるふわな感じでPerlについて話ができてとても楽しかったです。 今回は基本全員LTしないといけないということに前日の夜に気がついて1時間で死霊を作るというていたらくでした。次回は余裕を持って、ちゃんとした発表をしたいです。 はなしたこと pt-query-digestは便利だよって話をしました。 (pt|mk)-query-digestに関しては自分以外の人が詳しく書いているのでそちらの方も参照いただければ、より理解できるかと。 ゆるふわにクエリ解析したい ※MySQL前提の話です。 アプリケーションのボトルネックになるのは、だいたいDBなのですが、じゃあ、どうやってボトルネックとなっているクエリを特定す
Percona ToolkitによるSlowログの解析 – variable.jp [データベース,パフォーマンス,運用]
MYSQLの運用・管理ツール検証 Percona Toolkit 最新版のPercona Toolkitをダウンロード http://www.percona.com/downloads/percona-toolkit/LATEST/ [root@HOME001 mysql]# wget http://www.percona.com/redir/downloads/percona-toolkit/LATEST/percona-toolkit-2.1.8.tar.gz --2013-01-31 14:03:47-- http://www.percona.com/redir/downloads/percona-toolkit/LATEST/percona-toolkit-2.1.8.tar.gz www.percona.com をDNSに問いあわせています... 74.121.199.234 w
Percona Server 機能紹介 (2) Slow Query Log | 外道父の匠
引き続きPerconaシリーズ機能紹介で、今回はスロークエリについてです。 Slow Query Log – Percona Server 5.5 Documentation に綺麗に書かれていますが、日本語での要約ということで・・・ スロークエリログの基本設定 処理時間が0.5秒以上 かつ 検索対象が10000行以上のクエリを残す場合はこんな感じ。秒数はマイクロまで可能だけど、まぁ0.1でもやりすぎなくらいでしょう。あと、インデックスを使わないけど軽いクエリってのもあるから、log-queries-not-using-indexes は直接調査する時用かと。 slow_query_log slow_query_log_file = /fio/mysql_log/system/slow-queries.log long_query_time = 0.5 #log-queries-not-u
MySQL 互換のDB、Percona Server を使う理由 - Qiita
# Time: 120114 6:34:33 # User@Host: user[user] @ [10.10.10.10] # Thread_id: 28313080 Schema: mydb Last_errno: 0 Killed: 0 # Query_time: 0.588882 Lock_time: 0.000068 Rows_sent: 3 Rows_examined: 183839 Rows_affected: 0 Rows_read: 100 # Bytes_sent: 121 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 /+ Percona Server 独自のログ +/ # InnoDB_trx_id: 9903E4DB1 # QC_Hit: No Full_scan: No Full_join: No Tmp
Query_time - Lock_time > long_query_time - takatoshiono's blog
MySQL(InnoDB)でロック待ちタイムアウトになるクエリはスロークエリログに記録されるのか？ 気になったので調べていた。 ロック待ちタイムアウト あるトランザクションで UPDATE 中の行を他のトランザクションから UPDATE しようとするとロック待ちになる ロック待ちの時間が innodb_lock_wait_timeout に設定された秒数を超えると Lock wait timeout exceeded; try restarting transaction というエラーが発生する スロークエリログ (MySQl 5.0) さて、このときスロークエリログは？ # Query_time: 51 Lock_time: 0 Rows_sent: 0 Rows_examined: 0 SET timestamp=1423478293; update ... こういう記録が残っていた。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL(InnoDB) で charset を utf8mb4 にする注意点の現在
MySQL :: Upgrading JSON data stored in TEXT columns
MySQLにおけるJOINのチューニングの定石
