「日本国内でもトップレベルのスキルを持ったMySQLエキスパートは誰か？」 そう問われたときに、多くのエンジニアが名前を挙げる人物がいます。LINE株式会社のITサービスセンター データベース室 MySQL1チームでDBA（Database Administrator）として働くyoku0825さん*（@yoku0825）です。 日本人として3人目のMySQL分野のOracle ACEであり、2015年には「default_password_lifetime」の功績でMySQL 5.7 Community Contributor Awardに選出されたyoku0825さん。彼はひたむきに自己研鑽を続けるだけではなく、ブログ「日々の覚書」や技術イベントへの登壇などを通してMySQL関連の情報発信を行ってきました。 今回はそんなyoku0825さんに「これまでどのようなトレーニングをして、DB
【2022/2/26 追記】 主にはてブコメントで様々なご指摘を頂いたので、タイトルの修正＆内容を一部追記しました。分かりにくいタイトルを付けてしまい申し訳ございません。ご指摘ありがとうございます。 もともと本記事は自分用のメモを兼ねて駆け出しエンジニアの人が数人参考にしてくれたらいいかな、程度の気持ちで書いたものでした。 現在はてなブックマークのテクノロジーカテゴリーで 1 位になっており、予想の 1000 倍以上の人に見ていただける記事になってしまいました。 今後も精進します、ありがとうございます！ 特に理由もなくローカルに MySQL を入れて遊びたくなる気持ちって定期的に湧きますよね。 私は湧きます、半年に 1 回ぐらい。 業務ではフロントを触ることが多く、DB はそれほど触りません。 そのため久々に MySQL をローカルで立ち上げようとするといつも手順を忘れてしまっていて、なん
この記事は freee Developers Advent Calendar 2021 の23日目の記事です🎄 freee の DBRE チームに所属している caterpillar です. なんだか大きなデータベースを眺める仕事をしています. 突然ですが, pingcap/parser を使って SQL を簡単に解析していきたいと思います. Go 製 の SQL Parser で, MySQL への高い互換性を謳う TiDB で利用されています. この parser の嬉しい点はこんな感じです. シンプルで使いやすい TiDB に利用されていることから, ある程度結果を信頼できる mask 済 SQL もおおよそ構文解析可能 3つ目について, mask済の SQL は select * from users where id = ? のように一部が別の文字に置き換わっているものを指しま
こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした！障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー
"We have been amazed by the increased performance of MySQL HeatWave and the improved availability of our services delivered on OCI. Moving from Azure to OCI has prepared us for global growth." "We successfully migrated our 6 TB database and in-house digital marketing and media management applications from AWS Aurora to MySQL HeatWave, which reduced our costs by 60% and improved performance for com
yokuo825さんのカッコいいインタビュー記事を t.co 読んで、この部分ですね ──例えばどのような話をしましたか？ 「インストールされたばかりのMySQLがあるとして、特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」と質問されたのを覚えています。 具体的にどのような理由でどのファイルにアクセスするか、一連の流れを片っ端から答えていくと、彼らがすごく楽しそうにしてくれて。「そうか、LINEの環境だと○○の設定が最初から○○になっているので、そのファイルへのアクセスは考えていなかったです。確かにそれもありますね」などと答えてくれました。 でこんなツイートしたんですが 全国のDBAは「特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」これ明日から職場で
あれ？メモリめっちゃ使ってるという時の対処メモです きっかけはZABBIX監視 ZABBIXで検証用のサーバを監視していたところ、なんかRAMの使用率が高かったんですね。 その時MySQLのチューニングをRAMの総量と比較するとそれなりにパフォーマンス重視！みたいな設定にしていたので、「あーやりすぎたか」と思って値を調整したのでした。 しかし、値を再調整してもメモリ使用量があまり変わらず……。 freeコマンドで確認しても、どう考えても設定よりもずっと多い量のメモリを消費しているようでした。 原因は一体？ 当てはまるものが何か無いか探してみました。 探して結果、以下の２点が怪しそうということが分かりました。なんやかんやで。 table_definition_cache テーブルを開くためにキャッシュを使って高速化する。 そのキャッシュのテーブル定義の格納数？らしいです。最小値が400で最大
Vitess(ヴィテス)とは MySQLインスタンスの大規模クラスタをデプロイ、拡張、管理するためのデータベースソリューションです。 本ソリューションはもともとYouTubeのバックエンドであるMySQLクラスタで利用されていましたが、GoogleがOSSとして公開し誰でも利用可能となりました。 2018年のMySQL Awardで表彰されたり、Cloud Native Computing Foundation (CNCF)のインキュベーションプロジェクトとなったりと 今後が非常に注目されるソリューションです。 Vitessの主な機能は以下のとおりです。 コネクションプール ACL パフォーマンス監視 MySQLトポロジ管理インタフェースの提供 水平分割/垂直分割 今回は、チュートリアルをもとに可能な限りVitessを解明していきたいと思います。 ドキュメント Vitess Doc Git
2007/ 01 02 03 04 05 06 07 08 09 10 2006/ 01 02 03 04 05 06 07 08 09 10 11 12 2005/ 01 02 03 04 05 06 07 08 09 10 11 12 2004/ 01 02 03 04 05 06 07 08 09 10 11 12 2003/ 01 02 03 04 05 06 07 08 09 10 11 12 2002/ 01 02 03 04 05 06 07 08 09 10 11 12 2001/ 01 02 03 04 05 06 07 08 09 10 11 12 2000/ 01 02 03 04 05 06 07 08 09 10 11 12 1999/ 01 02 03 04 05 06 07 08 09 10 11 12 1998/ 01 02 03 04 05 06 07 0
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
If you are a regular reader of this blog, you likely know I like the ZFS filesystem a lot. ZFS has many very interesting features, but I am a bit tired of hearing negative statements on ZFS performance. It feels a bit like people are telling me “Why do you use InnoDB? I have read that MyISAM is faster.” I found the comparison of InnoDB vs. MyISAM quite interesting, and I’ll use it in this post. To
慣例(?)として4月下旬には出るのではないか、と勝手に予測していた MySQL 8.0 が、私の予想よりもほんの少し早くリリースされました*1。ついに待望の GA です。 MySQL 5.7 で、それ以前のバージョンと比べて非常に大きな進化をしたMySQLですが、バージョン番号を大きく飛ばした今回の MySQL 8.0 でも一層の進化をしています。進化の内容は MySQL Server Blog の記事で詳しく説明されているので、私もこれから少しずつ読もうと思います。 mysqlserverteam.com この Server Blog のエントリー、とってもとっても長い力作で、これを読むだけでMySQL8.0の進化の概要はざっと理解できそうなくらいです。が、長いと(更に英語だし)だんだん何を読んでいるのか分からなくなってしまうので、私はこういうときに「地図」を作ります。自分用に、ざっくり
この記事はMySQL Casual Advent Calendar 2017 - Qiitaの9日目のエントリとなります。 実行が長引いたSELECT文を強制終了させるヤーツ MySQL5.6まで、正常に処理が進んでいて遅いSELECTをタイムアウトさせるシステム変数はありませんでした。 正常に処理が進んでいない時のパラメータだと lock_wait_timeout：メタデータロック取得待ち innodb_lock_wait_timeout：レコードロック取得待ち がありました。 正常に処理が進んでいるけど、厳密には「処理中」ではないときに効くパラメータだと net_read_timeout：クライアントからサーバに送り込んだデータの読み込み時間 net_write_timeout：サーバからクライアントへのデータの書き戻し時間 がありました。 他にも、アイドルタイムアウト系で inter
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
