MySQLでお手軽デッドロック - jfluteの日記
-- MEMBER_SEA は MEMBER の 1:n の子テーブル delete from MEMBER_SEA where MEMBER_ID = 3 insert into MEMBER_SEA ...(MEMBER_ID は 3) ん？ 最初のdeleteが互いに「0件削除」だとデッドロック。別トランザクションのMEMBER_IDが別ID(例えば4)でもデッドロック。(とにかく両方のトランザクションでdeleteが0件であれば) これは... ネクストキーロックって？ MySQLのInnoDBには「ネクストキーロック」という機構があります。 詳しくは、ぐぐってくれればOKですが、ひとまず参考になるオフィシャルサイトのページを。 => ネクスト キー ロック:ファントムの問題を防ぐ 難しいこと書いてありますねぇ。 「ギャップ」って何!? ここでいうインデックスレコードって!? とに
ちょっぴり上行く SHOW PROCESSLIST の使い方
MySQL サーバで詰まっているクエリを調べる際に SHOW PROCESSLIST を使いますが 実はこれもデータベースに蓄えられた情報を出力してるだけなんですよね。 データベース名 information_schema、テーブル名 PROCESSLIST はこんな構造をしています。 （ちなみに MyISAM で管理されています） mysql> DESC information_schema.PROCESSLIST; +---------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------+-------------+------+-----+---------+-------+ | ID | bigint(4) | NO |
開発スピードアクセル全開ぶっちぎり！日本よ、これがMySQL 5.6だッ！！
米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC（リリース候補版）が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている！正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは？などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか？と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB
複合インデックスで範囲検索が遅いとき - （ひ）メモ
DDLとデータは末尾に示しますが、複合インデックスが効くはずのクエリなんだけどナめてる行数が多くて困ったというお話です。(MySQL 5.1.55) このクエリで返ってくる行数は246件なんですが、それにしてはナめてる行数(rows)がやたら多いです。where句で使っているageとlast_updateとで複合インデックスを張っているのに、です。 between使用: explain extended select id from betweeeeen where age between 30 and 35 and last_update >= 946612000 \G ↓ id: 1 select_type: SIMPLE table: betweeeeen type: range possible_keys: i1 key: i1 key_len: 10 ref: NULL rows
HugeDomains.com
Captcha security check stack3.com is for sale Please prove you're not a robot View Price Processing
MySQL TIPS 3 空間情報(geometry)を使って経度・緯度の検索を高速化する - イノベートな非日常
以下のようなピタゴラスの定理を使った指定した経度緯度に最も近いデータを取得するSQLは結構ありがちですが、CPU負荷が高く効率も悪いのでMySQLに標準搭載となった空間情報(geometry)を使ってみることにします。 SELECT * FROM loc ORDER BY power(abs(latitude - 緯度 ), 2) + power(abs(longitude - 緯度 ), 2) LIMIT 1 MySQLの空間情報(geometry)機能はPostGIS(Postgresカスタマイズ)に比べると貧弱なので、その為の工夫を行います。例えばここのとおりのままだと逆にSQLが遅くなります。 まずは、テーブル定義から 通常のテーブル CREATE TABLE IF NOT EXISTS `loc` ( `loc_id` int(11) NOT NULL auto_incremen
共有行ロックと排他行ロックの違い - shima111の日記
select ... for update; select ... lock in share mode; の違いがよくわからなかった。 データを更新する時に必要なロックは、for update データを参照する時に必要なロックは、share mode と体感的に理解できるのだが、どちらのロックを取ったときも、他の誰もデータを更新、削除できない。 また、どちらのロックも、(for update していたら、他から参照できないのかと思いきや)他の誰からも参照は可能。 ん？となると、この２つのロック、何がどう違うの？？ その答えは ここ に書いてあった。(リンク先はPostgresだが、MySQLでも同じこと) 共有ロックとは、排他ロック（更新、削除、FOR UPDATE）をブロックする／される一方、共有ロック同士では互いにブロックしないというものです。 なるほど、share mode はセマ
groongaで高速な位置情報検索 - 2011-09-13 - ククログ
groongaのドキュメントにも位置情報検索について書かれているのですが、情報の更新が追いついていないため情報が不足しています。そこで、ここに現状に合わせたgroongaの位置情報検索についての情報をまとめておきます。なお、ここにまとめた内容もドキュメントに反映させる予定です。 できること groongaには位置情報を用いた検索機能がついています。位置情報を用いた検索では索引を利用するため、全文検索と同じように高速に検索することができます。ただし、PostGISやMySQLのように1線や面などもデータとして保持できるというわけではなく、点のみをデータとして保持できます。よって、groongaにできることは以下の通りです。 指定した四角の中に含まれている座標を持つレコードを検索する。 指定した円の中に含まれている座標を持つレコードを検索する。 座標間の距離を計算する。 ある座標からの距離が近
第5回 位置情報を保存しよう（前編）：位置情報サービスのはじめ方｜gihyo.jp … 技術評論社
今回から2回に分けて、位置情報をDatastoreに格納する方法をいくつか紹介します[1]。 数値型で保存する 緯度経度の情報をデータベースへ格納するときに、もっとも簡単な方法が数値型として保存する方法です。緯度経度がとりうる値の範囲は、以下の通りですので、システムに必要な小数点以下の数字を考慮して型を決めましょう。 はてなフォトライフでは、写真に緯度経度のメタ情報を設定することができますが、高精度な緯度経度情報は必要ないので、型を以下のように指定しています。 latitude decimal(7,4) longitude decimal(7,4) decimal(7,4)という指定は、10進数で7桁のデータで、小数点以下は4桁まで格納するというものです。 あるオブジェクトの緯度経度を保存し、表示するだけならこれだけで十分ですが、位置情報を中心に扱うサービスになると、格納したデータを緯度
MySQLのコマンドたち - すぎゃーんメモ
http://mysql-casual.org/2011/11/mysql-casual-advent-calendar-2011.html の6日目の記事として書かせていただきます、sugyanです。 勢いで参加表明してしまい、今日慌てて久しぶりにMySQLを触りました。 MySQLでFizzBuzz ストアドプロシージャって使ったこと無かったので初めて触ってみました。 DROP PROCEDURE IF EXISTS FizzBuzz; delimiter // CREATE PROCEDURE FizzBuzz(n INT) BEGIN DECLARE i INT DEFAULT 1; WHILE i <= n DO SELECT CASE WHEN i % 3 = 0 AND i % 5 = 0 THEN 'FizzBuzz' WHEN i % 5 = 0 THEN 'Buzz'
MySQLがおかしい！あなたならどうしますか？ – MySQL Casual Advent Calendar 2011 - As a Futurist...
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
カヤック流ソーシャルアプリの作り方 インフラ編 - KAYAC Engineers' Blog
入社4年目にもなってtech.kayac初登場のせいです。 ブログ書けプレッシャーにとうとう屈する時がきました。 これで夢にkyo_agoが出てうなされなくてすみます。(彼はtech.kayacの尻たたき担当でした) 先々月「ぼくらの甲子園!熱闘編」というゲームをモバゲー内にてリリースしました。 これは去年リリースした「ぼくらの甲子園!」の続編です。 モバゲーユーザの方、是非遊んでみてください。 今回はこの「ぼくらの甲子園!熱闘編」がどういうインフラ構成になってるか紹介したいと思います。 注) 題名に「カヤック流」とはつけましたが、カヤックでは多様性を善としている風潮があり、 ゲームによってインフラの構成が違うどころか、利用しているプログラミング言語すら違います。 なので全てのゲームがこのような構成になってるわけではありません。 前提 今回のインフラ構成を決めるに至って考慮した点は「ラクに
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
blog.nomadscafe.jp
PHPの勉強会なので、いままでお会いしたことのない方とお話ができてよかったです。 発表内容は大きくなってしまったmaster.phpファイルをどうやって高速に読むかというお話です。PHPではリクエストの終了とともに全てのメモリを捨ててしまうので、変わらないデータもリクエストの度にキャッシュからロードしなくてはいけません。大きなphpファイルがあれば当然毎回の読み込みがオーバーヘッドとなってきます。そんな環境でどうやってアプリケーションのパフォーマンスをあげていったのかを紹介しています。 スライドの中でfile sizeを小さくする必要があると書きましたが、@hnwさんによると、VM命令が多過ぎるのが問題で、構造を簡単にしたことでVM命令が減ったのがよかったのではとのことでした。非常に参考になりました。ありがとうございました そろそろ傷が癒えてきた。。 ISUCON5の本選にメルカリのインフ
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
MySQL 5.6登場！！新機能速攻レビュー
現在、米国で行われているMySQL Conference & Expoにあわせて、新しい開発版であるMySQL 5.6が発表された。MySQL 5.5における新機能もかなりのものだったが、MySQL 5.6の進化は質・量ともに勝とも劣らない内容となっている。そこで、今日は簡単に、MySQL 5.6で追加された新機能の概要について見てみよう。開発版なので利用にあたっては十分な注意が必要（予期なく予定が変更される可能性あり）だが、次期正式版のリリースに向けて是非試してみて欲しい。 InnoDB関連MySQL 5.5で大幅な進化を遂げたInnoDBだが、その勢いはまったく衰えることを知らない。性能の強化だけでなく、痒いところに手が届く便利な機能が追加されている。 ダーティページのフラッシュをするスレッドが独立した。以前はマスタースレッド内でフラッシュが行われていたが、スレッドが独立したことによっ
「優れたMySQL DBAを見分ける27+3の質問」に対する回答例
随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例（漢バージョン）を紹介しよう。実は質問を掲載した際「難しい！」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日本を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった！！ そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある？ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLで全文検索 - FULLTEXTインデックスの基礎知識｜blog｜たたみラボ
https://labs.cybozu.co.jp/blog/kazuho/archives/2008/06/friends_timeline.php
Twitterにおける大規模システム構築、3つの原則
