MySQL の外部キーのため自動作成されたインデックスは不要になると自動で削除される
知らなかったのでメモ。 MySQL の外部キーは相当するカラムのインデックスが必要 必要なインデックスがない場合は外部キー作成時に自動でインデックスも作成される こうして自動で作成されたインデックスは、不要になった際に自動で drop される 不要になった際 = その外部キーをカバーできるような別のインデックスが追加された場合 MySQL :: MySQL 5.7 Reference Manual :: 1.7.3.2 FOREIGN KEY Constraints MySQL requires that foreign key columns be indexed; if you create a table with a foreign key constraint but no index on a given column, an index is created. MySQL :
MySQLのJSON Data Typeの値に対し、明示的なキャスト無しに `BETWEEN`, `IN()`, `GREATEST()`, `LEAST()` を使ってはならない - その手の平は尻もつかめるさ
表題の通り、MySQLのJSON Data Typeの値に対しては、明示的なキャスト無しに BETWEEN, IN(), GREATEST() そして LEAST() を使ってはいけません。 MySQLむずかしい pic.twitter.com/YKoadLbaG2— すぎゃーん💯 (@sugyan) 2021年9月7日 本記事はこれに係る話題で、id:sugyan さんに Slack で相談を受けて「僕もそれハマったことあるな」と調べたところ以下のドキュメントに辿りつきました。 dev.mysql.com これはMySQL 8.0のJSON Data Typeに関するドキュメントですが、このドキュメントの Comparison and Ordering of JSON Values というセクションに The following comparison operators and fun
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
ISUCON Cheat Sheet · GitHub
00_timeline.md 集合 9:00にオフィス(Sticky Fingers) 食料品は事前に用意しておく。食べ過ぎない。胃に負担をかけないようにする。 運営の櫛井さんからのメールに従って、サポートチャットと予選ポータルサイトにログインする。 ISUCON6 予選レギュレーション メール: ISUCON6 オンライン予選 当日の流れについて 今までに寄せられた質問についてまとめたFAQ ISUCON6 予選 9月18日(日) 参加者サポート用チャット ISUCON6 予選ポータルサイト http://isucon6q.songmu.org/ 10:00〜11:00 最初の1時間 11:00〜12:00 まず基本的なことをやる。 12:00〜17:00 この辺りからRedis移行に取り組む。 17:00〜18:00 最後の1時間 01_first_hour.md Why 課題の理解、
VTuberチームでISUCON 10本戦を解く企画「Virtual #ISUCON Live 2021」に出演しました！ - 糟屋郡はいいぞ
こんばんは、糟屋もふです。本日は、Virtual ISUCON Liveのプレイヤーとして参加しました。 興奮冷めやらぬ中ではありますが、ブログを書くまでがISUCONということで、振り返りと今後改善できることの2つにわけて話します。 今日の振り返り 概要と総評 本企画に関われた全ての関係者の皆様、ご来場や声援をいただいた皆様、そしてチームメンバーの晴栄リコさんとこみっとちゃんさん。この企画に関わった全ての時間を有意義に、楽しく過ごせたのは、皆様のおかげです。本当にありがとうございました！ 当日だけでなく、ISUCON 11の事前講習をベースに、実際に手を動かして学ぶ機会も用意いただきました。ISUCONは何をやるべきか、改善に取り組む前に必要なものは何か、改善するには何を見るべきか、様々なことを、休日問わず教えていただきました。どれくらい成長したかというと、もふさんはgitの操作すら怪し
SELECT ... FOR UPDATEとUPDATEでデッドロックが出る人へ - 41から始めました
はじめに 最近は主に花粉症に悩まされており、目が痒くてたまりません。 また、娘の生活がガラッと変わったせいで、毎日貧乏ヒマ無しです。 そんな中、たまたま早起きできたので奮起して久々に書いてみました。 問題が起きる環境 MySQL8.0.17以前 transaction_isolationがREAD-COMMITTED WHERE句の条件が一意ではない。（フルテーブルスキャンだと発生しやすくなる） キーの値がたすきがけになってる トランザクション開始＋SELECT ...FOR UPDATE→UPDATEのようにロックを取っている 先に実行されたトランザクションが、たすきがけになっているキー値の若い（っていうのかな？）方のロックを取る 何が起きるかと言うと、SELECT ...FOR UPDATEのWHERE句で抽出した行に対してロックを取ってるのに、 後から別セッションで実行されたSELE
プライマリーキー(primary key)はシーケンシャルな値で良いと思うよ - 角待ちは対空
zenn.dev を読んでの感想です。「シーケンスナンバーをPKにする」以外の項目については言及しませんが、言及しないことは正当性や妥当性を保証していることにはならないです。 InnoDB(MySQL)を想定してます。が、原理は割と一般的なので他のDBでも適用できることが多いと思います。 追記:一般的とは分散でないような"普通の"RDBMSを想定してましたが、分散システム(distributed systemないしreplicated system)のような場合では話が違います。 なぜシーケンシャルな値がよいか 端的にいうと書き込み操作時にバッファープール(baffuer pool)に読み混む必要のあるページが少なくて済むからです。その結果書き込み操作時にバッファープールにページが存在する可能性が高くレイテンシー的に有利になる可能性が高いです。 バッファープール、ページ、btreeなど具体
MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
クエリログを使ったAurora MySQLの負荷テスト - クックパッド開発者ブログ
最近はZX-25Rが気になっている菅原です。4気筒250ccといえば、以前バリオス2に乗っていたんですが、あれもよく回るよいバイクでした。足つきの良さが懐かしいです。 この記事では、クエリログを使ったAurora MySQLの負荷テストの話を書きます。 MySQLの負荷テスト サービスに使われているデータベースは、Webサーバと比べて自動的なスケールアップ・スケールアウトが簡単ではないためキャパシティプランニングは非常に重要です。サービスへのアクセス増による負荷増大の結果、急激に性能が低下するためなるべく事前にキャパシティを把握しておきたいところです。 クックパッドではサービスのデータベースとして主にAurora MySQLを利用しているのですが、キャパシティを把握するための負荷テストには以前から苦労してきました。 1. シナリオを書くのが大変 サービスで使われているデータベースの負荷テス
ISUCON10 の振り返りと MySQL の generated columns - Techtouch Developers Blog
バックエンドエンジニアの misu です。最近は塩加減に苦戦しながら、スパイスからカレーを作っています。 この記事について ISUCON 10 の振り返り チーム構成 振り返り generated columns とは 参考 この記事について ISUCON 10 に出場し、予選敗退したのでその振り返りと次回のために MySQL の generated columns について調査したことが書かれています。 ISUCON 10 の振り返り チーム構成 弊社では、僕が ISUCON 出る人いませんか〜と募ったところ、6 人の戦士が手を上げてくれました。僕以外は全員初出場です。 7 人なので、得意な言語でこんなチーム分けになりました。 Go チーム 2 人セットが 2 チーム Node.js チーム 3 人 振り返り 僕は、Go で普段開発しているので、Go で挑んだのですが、社内 3 チームの
ISUCON10 予選問題の解説と講評 : ISUCON公式Blog
ISUCON 10 予選問題作問担当の @yosuke_furukawa です。ISUCON 10 の予選お疲れさまでした。このブログでは、 ISUCON 10 の予選問題の解説と講評を行います。 問題については下記のURLにて公開されています。 http://github.com/isucon/isucon10-qualify 動作確認をしたい場合は README.md を確認の上、検証してみてください。 課題アプリケーション ISUUMO について ISUCON10 の予選の問題は、 ISUUMO と呼ばれるイスに合う物件を検索するサイトでした。せっかくリクルートが作問担当になったので、リクルートならではのものにしたいのと、ずっと社内ISUCONでポリシーとして持っていた「実際に起きているパフォーマンス問題に近い課題を設定したい」という思いから作りました。 今回の問題は位置情報を使った
ISUCON10予選を1位通過した - FCCPC
はじめに ISUCON10予選で運良く1位通過ができてしまったので記事を書いてみました。 自己紹介 ponyopoppo: PNYOという会社のCTO＋i社ソフトウェアエンジニア。 主にアプリ担当 hiro116s: i社ソフトウェアエンジニア。 主にMySQL担当 じゃがいも: i社ソフトウェアエンジニア。 主にnginx担当 チームについて ISUCON7-9は予選敗退したので、今回が初の本選出場です。 「FCCPC_かみのやま温泉」というチームで参加しました。3人の住んでる家の地図上での重心をとってみたら、かみのやま温泉があったのでそれをチーム名にしました。 使用言語 ponyopoppoが普段から使っているNode.jsです。 やったこと 13:30 最初のベンチ 451点 13:44 とりあえずnazotteのN+1問題をJavaScriptで多角形包含関係を計算するように改善
ISUCON10予選に参加して不通過でした - 酒日記 はてな支店
Webアプリケーションパフォーマンスチューニングコンテスト ISUCON http://isucon.net/、記念すべき10回大会の予選に参加して、あと3チーム100点弱の差で不通過に終わりました。悔しい！ チームメイトは会社の同僚の @acidlemon (ISUCON 3の出題、ISUCON 4, 7 のチームメイト), @mackee_w (macopy, 実はチームを組んだのは初) です。 序盤から中盤 ベンチを回して MySQL が重いねー(いつものことだ) と把握 acidlemon estate の範囲検索になっているカラムを = 条件で取れるように 0〜49999 -> 0, 50000〜100000 -> 1 のようにクラスわけ(verify がたまにコケるのを解消できず取り込めず interpolateParams=true (server side prepare
ISUCON10予選に「チーム中目黒乗り過ごし」で参加し本選出場決まりました - Hateburo: kazeburo hatenablog
ISUCON10の予選に尊敬するエンジニアであるhanabokuro氏、mtokioka氏と参加して、9位で本戦出場できることになりました。うれしい！ ISUCON8は予選落ち、去年は出題をやらせていただいたので、本選出場は3年ぶりになります 今年の問題も、よく練られた問題で開始から終了まで楽しむことができました。運営のみなさま朝早くから遅くまで本当にありがとうございます。 準備 GoはMackerelプラグインやミドルウェアでよく書いておりますが、、いわゆるWebアプリケーションはあまり書いてないので、手を動かすために去年のISUCON9予選の問題を手元で動かして取り組んでみてました。 ローカル環境で動かすのは以下の記事が役立ちます。 isucon.net また、Cloud TraceやProfilerを試すために、takonomura氏の記事やgithub repositoryをすごく
ISUCON10の予選を4位で通過しました
こんにちは、Finatextでエンジニアをしている @s_tajima です。 先日行われたISUCON10の予選に、Finatextのエンジニア陣 @s_tajima / 石橋 @atsushi-ishibashi / @yami20 で参加しました。 チーム名は 一口坂46 です。オフィスの前の坂の名前です。 結果として、予選を4位で通過することができました！ 私達のチームがどんな戦略でどんなことをやっていたかのブログです。 尚、このブログはチームメンバー3人での共著です。 リポジトリhttps://github.com/s-tajima/isucon10q-hz46-app 事前準備他にもやっていた準備はあるのですが、特に役立ったものを3つほど紹介します。 作業用AWS環境の準備事前練習用のEC2、当日のログアップロード用のS3バケット(後述) 等を作成するためのAWSアカウントを用
MySQL の SQL thread は lock_wait_timeout を無視するという話 - なゆ発システム研究室
MySQL の話。「Master から slave にレプリケートされた DDL が、slave 側の metadata lock によりブロックされ lock_wait_timeout を超えてエラーになった場合、master と slave でスキーマが合わなくなるのではないか？」と心配になったので調べてみた。 もう少し丁寧に書くと、次のような状況を想定している: Master で何らかの DDL の実行が完了する。 DDL が slave にレプリケートされ、slave の SQL thread が DDL を実行する。 運悪く、DDL が変更するテーブルの metadata lock を握っている別のトランザクションが存在し、DDL がブロックされる (process list に "Waiting for Table metadata lock" と出るやつ)。 DDL が lo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
初めてのMySQLパフォーマンスチューニングーデータベースは怖くない！/mysql-performance-tuning-basics-in-db-study-chugoku-chiho
https://github.com/ichirin2501/doc/blob/master/innodb.md
ISUCONの失敗から学ぶ パフォーマンスチューニングの勘所 / isucon10
