サイボウズさんの開運研修(データベース)で話してきました
2024 ( 30 ) 12月 ( 5 ) 11月 ( 1 ) 9月 ( 4 ) 8月 ( 2 ) 5月 ( 1 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 東京都オープンデータカタログサイトのCSVを使ってLOAD DATA LOCAL INFIL
用途 時間計測したいけど、結果の行表示とか余計なものは全くいらない、ってケースありますよね。性能検証やってるときとか。 何百行何千行も取れるようなSQL流すと、表示するのも萎える。 pager有効だと「--More--」って出て止まる。これは「q」で残りの表示はスキップできるけど、それもめんどくさい。 pager無効にすれば余計な操作はいらなくなるけど、表示処理が重いし。 結論 psqlでログインして「\timing」で実行時間表示モードをONにした後、以下を実行します。 その１：メタコマンド「\g」を使って、/dev/nullにリダイレクトする。 SELECT ...(任意のクエリ) \g |> /dev/nullWindowsのコマンドプロンプトだと、Nullへのリダイレクトは「>nul」、Powershellだと「> $null」が該当するらしいのですが、これ使うと「The synt
TL;DR この記事に書いた事 二分探索木のお話(前提知識) MySQLのInnoDBで利用されているB+木インデックスの構造と特性 (前提知識) MySQLのClusteredIndex,SecondaryIndexについて(前提知識) カーディナリティについて(前提知識) 実際の負荷対策 検出編 スロークエリ 検出編 その他のクエリ割り出しいろいろ クエリ・インデックスの最適化 explainの使い方と詳細 ケース別実践 単純にインデックスがあたっていないケース カーディナリティが低いインデックスが使われているケース 部分的にしかインデックス/複合インデックスがあたっていないケース 複合インデックスの順序誤りでインデックスが適用できていないケース 複合インデックスの最初がrange検索のケース ソートにインデックスが適用できていないケース ソートにインデックスが適用できていないケース（
同根のバグレポートが散見されますが、ここ数ヶ月、状況をみるに修正される見込みがなさそうなので記録しておきます。 事象 MySQL 5.7 の libmysqlclient (libmysqlclient.so.20) を使用しているプロセスが、無限ループに突入して CPU (user%) を食いつぶし続ける。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28150 hirose31 20 0 32488 6080 5492 R 93.8 0.3 0:16.70 mysql 発現条件 MySQLが提供しているパッケージのMySQL 5.7.25, 5.7.26, 5.7.27 で確認。 Ubuntu 18.10, mysql-community-client 5.7.25-1ubuntu18.10 Ubuntu 18.04, m
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
やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
AWS re:Invent 2017で発表のあったAurora Serverlessがいよいよ一般利用可能になりました。早速Aurora Serverlessに触って確認してみます。 大栗です。 AWS re:Invent 2017で発表されていたAmazon Aurora Serverlessが一般利用可能になったので、早速試してみました。 Aurora Serverless MySQL Generally Available Aurora Serverless 概要 AWS re:Invent 2017で発表されていたAuroraの新しい形態の動作モードです。 【速報】新しいDBサービスAurora Serverlessが発表されました！ #reinvent AuroraはSQL処理を行うDBインスタンス部分と高可用性な分散ストレージ部分が分離している構成をとっています。Aurora
こんにちわ。せじまです。さいきん、ジム用に左右独立型スポーツモデルのBluetoothイヤホン買ったのですが、あまりの快適さに、ジムに通うモチベーションが５割増しになりました。 はじめに innodb_thread_concurrency について書こうかと思ったんですが、まずはその前に MySQL の metric の話から入ったほうが良いかなぁと思ったので、今回は metric の話を書こうと思います。はじめにお断りしておきますが長くなります。 弊社では７年以上前から、 MySQLのサーバ一台あたり（OS側のも含めると）200-300 以上の metric を だいたい15秒間隔で記録しています。最近はSSDなども使ってますが、むかしはHDDにmetricを保存していました。例えばMySQLのサーバ一台分のmetric表示した画面をキャプチャすると、次のような感じになります。 ※画像は
MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
慣例(?)として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の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか？ SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか？ そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を
トランザクションはACID特性を満たすと言われている。 そのうちA(Atomicity)はトランザクション内の操作をAll or Nothingとなるよう保証し、トランザクションが中途半端に実行されて(アプリケーションレベルから見た)データの整合性が失われることを防ぐ特性。またD(Durability)とはシステム運用中に起こる様々な障害からデータを守る(整合性を保つ)特性。 これらの特性を満たすためのDBMSの古典的なテクニックがすごく面白いので、それに関するMySQL(主にInnoDB)のパラメータ・パフォーマンスにどのような影響を及ぼすかを調べた(*'ω'*) なお紹介している技術は基本的に教科書に書かれていた技術で、実際にInnoDBに実装されているアルゴリズムとは異なることがある(とはいえベースにはなっている) 参考 障害の種類 DBMSの基本構成 データベースバッファ 概要 関
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
役に立つ場面もある一方、スケーラビリティー上問題があるとされてきたMySQLのクエリーキャッシュが、MySQL 8.0で廃止されることになる。その背景と理由。 免責事項 この記事はMorgan Tocker氏によるMySQL Server Blogの投稿「MySQL 8.0: Retiring Support for the Query Cache」(2017/5/30)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 Reneが昨日、ProxySQLのブログにこう書きました。 MySQLのクエリーキャッシュはパフォーマンスを改善するためにあるが、それは重大なスケーラビリティー上の問題を抱えていて、深刻なボトルネックに簡単になってしまいかねない。 これは、MySQLチーム内でも確かに長い間言われてきたことです。今日の記事の本題に入る前に、少しイントロダクションを書かせて
5/13(土)に「MySQLユーザ会会 in 長野」を開催しました。 nseg.connpass.com 「会」が2つあるのは仕様です。「MySQLユーザ会」の会合で「MySQLユーザ会会」です。 開催経緯はこんなかんじです。 自分もMyNAとかに気軽に遊びに行きたい。— とみたまさひろ🍣🍺 (@tmtms) 2017年1月5日 @tmtms 遊びに行きましょう！ っていうか「俺がMyNAだ！」くらい言ってくれてもいいんじゃないでしょうかｗ— 坂井 恵(SAKAI Kei) (@sakaik) 2017年1月5日 @sakaik 「俺がMyNAだ！みんな長野に来い！」— とみたまさひろ🍣🍺 (@tmtms) 2017年1月5日 @tmtms 長野まで行きますよ！いつ行けばいいですか？— 🐬🍣🍻 (@RKajiyama) 2017年1月5日 この発言から早3ヶ月経ちましたが、5
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
