MySQL 8.0は SELECT .. FOR UPDATE SKIP LOCKED とJSON_TABLES関数で「取り敢えずJSON」が捗る？
MySQL 8.0は SELECT .. FOR UPDATE SKIP LOCKED とJSON_TABLES関数で「取り敢えずJSON」が捗る？ TL;DR auto_increment + JSON型（あるいはBLOB型やTEXT型でもいいけど）に生のJSONを突っ込む 後から SELECT .. FOR UPDATE SKIP LOCKED でワーカーが取り出して、 INSERT .. SELECT JSON_TABLE(..) FROM .. で正規化したテーブルに突っ込みなおす 外部APIからの戻りのJSONを取り敢えずログテーブルに格納して…みたいな感じを想像している PoC mysql80 13> SHOW CREATE TABLE t2\G *************************** 1. row *************************** Tab
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
mdqをさくっと使うツール「mdqi」の紹介 - KAYAC engineers' blog
mdqiの紹介 Lobi事業部サービス基盤チームの長田です。 この記事はKAYAC Advent Calendar 2017の11日目です。 以前本ブログでmdqというツールを紹介しました。 今回はこれを少し便利にするツールを作ってみました。 モチベーション mdqは複数のデータベースにクエリを発行して、結果をまとめてくれる便利なやつです。 データベースを水平分割している環境において、調査・集計作業が格段に楽になります。 JSONフォーマットで出力されるため、jqコマンドなどを使って再利用しやすいのですが、 「ちょっと集計して中身を見たいだけなんだけどなー」という場合、つまり人が読む場合にはちょっと読みづらいです。 mdqi と、いうわけでmdqのインターフェイスとなるmdqiというツールを作ってみました。 mdqのインターフェイスとして動作します。 mdqと同じくGo製です。 mdqが出
schemalexの神機能 - ken39arg’s blog
この記事はOSS紹介 Advent Calendar 2017 の 5日目の記事です。 schemalexとは schemalex/schemalex Generate the difference of two mysql schema と書いてある通り、２つのMySQLのスキーマの差分(ALTER)を表示するプロダクトで、@soh335が中心となって開発をしており、 僕も業務でも使っているのでたまにpatchを送っています。 perlだとSQL::Translator::Diffにあたり、 このschemalexはMySQLにしか対応していないのですが、Go製のプロダクトのためバイナリが提供されているため、コマンドラインツールとして簡単に使えるところがSQL::Translator::Diffより使いやすいと思って気に入っています。 紹介したいこと @lestrratによる#34 のP
ytkit - Yoku-san no ToolKITの紹介
最近、 --verbose で exec_time の中央値と最大値を出す機能を追加しました。スレーブ側のバイナリーログ( log_slave_updates が指定されている時)では exec_time が「マスターで実行された時刻」と「スレーブで実行された時刻」の差になるので、スレーブ遅延の時などにどの辺に問題があったのかを切り分けるのに使えるんじゃないかと期待しています。 $ mysqlbinlog -vv /path/to/binary-log | yt-binlog-groupby --cell=10m --group-by=time,table --verbose binlog entries between 171018 14:40 and 171130 19:30 171018 14:40 healthcheckdb.test3 13071 mid:0 max:1 1710
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
gh-ost: GitHub's online schema migration tool for MySQL
Engineeringgh-ost: GitHub’s online schema migration tool for MySQLToday we are announcing the open source release of gh-ost: GitHub's triggerless online schema migration tool for MySQL. gh-ost has been developed at GitHub in recent months to answer a… Today we are announcing the open source release of gh-ost: GitHub’s triggerless online schema migration tool for MySQL. gh-ost has been developed at
サーバーサイドエンジニア視点でLobiというサービスを紹介します - KAYAC engineers' blog
Lobiチームインフラ担当の長田です。 今年は弊社で運用しているLobiというサービスについて、 サーバーサイドエンジニアの視点から、月いちくらいのペースで紹介していきます。 今回は「Lobiとはなんぞや？」というところを書こうと思います。 サービスの概要 Lobiはゲームを中心としたコミュニティサービスです。 Lobi Chat & Game Community 2010年のサービス開始当初はナカマップという位置情報を絡めたチャットサービスでした。 2013年にスマホゲームに特化するとともにLobiという名前に改名し、様々な機能追加の末に今に至ります。 様々な機能とは・・・ グループチャット スマホゲームのプレイ動画録画・投稿・閲覧(Rec SDK) マルチプラットフォームなスコアランキング(Ranking SDK) スマホアプリへのグループチャット機能提供(Chat SDK) ゲームに
HikariCP で kamipo TRADITIONAL を有効にする - その手の平は尻もつかめるさ
さて2015年も暮れになってきましたので，各位に於かれましては常識の如く kamipo TRADITIONAL を有効にしていることと存じます． kamipo TRADITIONAL とはなんぞや，という方は以下のエントリが参考になりますからご一読下さい． さて Java で kamipo TRADITIONAL を有効にするテクについては 上記のエントリで紹介したわけですが，21世紀の我々には文明があるので connection pooling というものを使う (あるいは使えと言われる) ケースが多くなっております． ということで HikariCP を使うわけですが，この時に kamipo TRADITIONAL をどう設定するのかという話題があります．connection を borrow する度に sql mode を set するというのも渋いので，以下のようにしてやるとよろしい
世界の何処かで MySQL（InnoDB）の REPEATABLE READ に嵌る人を1人でも減らすために - KAYAC engineers' blog
tech.kayac.com Advent Calendar 2015 8日目担当の @m0t0k1ch1 です。 今年は MySQL さんにいろいろ泣かされた1年でした。特に、あの夏、幾夜をともにした実行計画のゆらぎは一生忘れな(ry さて。。。今回は、そんな中でも誰もが一度は嵌るであろう（？）MySQL（InnoDB）の REPEATABLE READ の嵌りどころについて自分なりにまとめてみようと思います。 この記事が目指すこと MySQL の各トランザクション分離レベルの嵌りどころについては、現状でも種々のブログ記事などでまとめられており、そんなに真新しい話ではないと思います。が、過去の自分のように、嵌ったことがない人間からすると、 話としてはなんとなく理解できる が、抽象的でいまいち身につかない というのが現実でした。嵌りどころに実際に嵌った今読み返してみると、「あーーー、、、そ
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
シンプルで移行しやすいデータベースシャーディング - クックパッド開発者ブログ
技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて
#isucon の予選問題の出題に参加しました
しまった、YAPC感想ブログ書いていなかった…。れもんです。 さて、先週末予選を行ったISUCON3の出題に参加しました。先に私の立場を明らかにしておくと、@fujiwaraの同僚で、昨年からWeb業界にやってきてWebサービスの開発経験1.5年くらいのエンジニアです。とりあえず業務ではサーバーサイドのエンジニアリングを行っていますが、iOSアプリも書けますのでそっちのテクニカルなアドバイスをしたりもしています。あ、そうそう、先日@typesterが独立して退社したので、im.kayac.comのiOSクライアントは私が引き継ぎました。ISUCONが終わって落ち着いたら通知サウンドを選べるようにする対応をやりますのでお楽しみに! もうなんか半分くらい書き終わった感じです。 出題内容についての反省項目などは既に@fujiwaraがまとめている通りで、/recentのチェックが甘かったのがやは
(帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
memo/MySQL/SQL.md at master · kenjiskywalker/memo · GitHub
COLUMN SELECT SELECT column FROM table; mysql> mysql> SELECT * FROM homhom; +----------+--------+---------------------+ | name | number | date | +----------+--------+---------------------+ | akemi | 1000 | 1999-12-31 01:00:00 | | homura | 1000 | 1999-12-31 01:00:00 | | homuhomu | 1000 | 1999-12-31 02:00:00 | | homu | 1001 | 1999-12-31 02:00:00 | | akemi | 1000 | 1999-12-31 01:00:00 | | homura | 10
MySQLのLEFT JOIN, RIGHT JOIN, INNER JOINの自分用まとめ - (ﾟ∀ﾟ)o彡 sasata299's blog
2008年09月03日00:53 MySQL MySQLのLEFT JOIN, RIGHT JOIN, INNER JOINの自分用まとめ MySQL の LEFT JOIN, RIGHT JOIN, INNER JOIN について、ちょっと混乱することが多いので自分用に簡単にまとめてみます。まぁ、タイトルのまんまです（・∀・；） まず、テスト用のテーブル (test1, test2) を用意します。 CREATE TABLE test1 ( test_id VARCHAR(255) PRIMARY KEY, hoge VARCHAR(255) ); CREATE TABLE test2 ( id INT PRIMARY KEY AUTO_INCREMENT, test_id VARCHAR(255) NOT NULL, fuga VARCHAR(255) ); テーブルの中身はこんな感じ
DBIのプレースホルダーで起こった謎な挙動 - $shibayu36->blog;
先日DBIを使っていて、謎な挙動に遭遇したので書いてみる。LIMIT, OFFSET句でプレースホルダーを用いた時に起こった。DBI + DBD::mysqlを使っていた。 DBI: 1.616 DBD::mysql: 4.022 LIMITとOFFSETを両方にプレースホルダーを使う LIMITとOFFSETを両方を?にするのはうまくいく。 $res = $dbh->prepare_cached(q[ SELECT * FROM user WHERE name = ? LIMIT ? OFFSET ? ])->execute('shiba_yu36', 1, 1); LIMITのみプレースホルダー LIMITのみ?でもうまくいく。 $res = $dbh->prepare_cached(q[ SELECT * FROM user WHERE name = ? LIMIT ? OFFSET
MariaDB Galera Cluster による DB サーバの冗長化 - dogmap.jp
さくらインターネット研究所さんの「MariaDB Galera Clusterを試す」という記事を読んで居ても立ってもいられなくなり、さっそく AWS で構築してみました。 上記の記事によれば 簡単にまとめると次のようになります。 Galera Replicationが複数のRDBMをレプリケーションするwsrep APIを提供し、同期をとります 完全同期型であるため、すべてのノードがアクティブかつマスターとなります クラスターノードのどれに対してもリード／ライトが可能です ノードの追加／削除は自動で行えます クライアント接続は通常のMySQLとなんら変わりなく使えます via. MariaDB Galera Clusterを試す (1) « さくらインターネット研究所 おー！スレーブ/マスター形式のレプリケーションよりも、断然使いやすそうやんか！ ってわけで AWS の ELB 配下に複
萌えキャラとは何だったのか - トランザクション
トランザクションってなーに？mix3です 同時更新処理 スレーブ遅延のときにSELECT > UPDATEで古い情報をもとにUPDATEしてしまうと不整合が発生すると書きましたが、 たとえば同じ行を複数で同時にSELECT > UPDATEすると同じように不整合が発生することがあります。 AがT1からSELECT BがT1からSELECT AがT1をUPDATE BがT1をUPDATE このような順序で更新がかかると、BがAの更新を上書きしてしまうため、実質Aの更新が無かった事になってしまいます。 これも更新がアトミックであれば発生しないので可能であればアトミックな更新にするのが良いですが、更新が複数ある場合はそういった変更も出来ません。 そんなときこそトランザクション。そんなふうに考えていた時期が僕にもありました。 で、そういうときはトランザクションを使う物だと思っていました。トランザク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スレッドIDを利用したMySQLのデッドロック解析手法
