MySQL8.0でSELECT COUNT(*)が低速になる動作は8.0.37で解消されていた！ - CyberAgent SRG #ca_srgメディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、MySQ
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ | mond
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ
How Postgres Stores Rows
Out of curiosity, I was trying to understand how PostgreSQL stores the data onto the disk and there are a few interesting things that I have noticed that might be useful for application developers. In this post, I will try to go into the implementation level details and map out how PostgreSQL row storage really works. Just to be clear, PostgreSQL stores a lot of files on disk such as transaction c
MySQLに初めてINSERTするとアクセスが発生するファイルは何かという質問をどう調べるのか - oranie's blog
yokuo825さんのカッコいいインタビュー記事を t.co 読んで、この部分ですね ──例えばどのような話をしましたか？ 「インストールされたばかりのMySQLがあるとして、特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」と質問されたのを覚えています。 具体的にどのような理由でどのファイルにアクセスするか、一連の流れを片っ端から答えていくと、彼らがすごく楽しそうにしてくれて。「そうか、LINEの環境だと○○の設定が最初から○○になっているので、そのファイルへのアクセスは考えていなかったです。確かにそれもありますね」などと答えてくれました。 でこんなツイートしたんですが 全国のDBAは「特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」これ明日から職場で
サイボウズさんの開運研修(データベース)で話してきました
2024 ( 17 ) 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 INFILEの練習をする サイボウズさんの開運研修(データベース)で話してきました オプティマイザヒント
Re: Configuring sql.DB for Better Performance : DSAS開発者の部屋
Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab
InnoDBのテーブル断片化を解消させたいけどもマスターにそんなに容量が残っていない！ 時のテクニック
OPTIMIZE TABLE, ALTER TABLE .. Engine = InnoDB で空き領域が回収できることがわかっている SELECT table_schema, table_name, data_free FROM information_schema.tables WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') ORDER BY data_free DESC; とかで調べましょう 短時間（容量による）のメンテに入れられる オンラインの ALTER TABLE .. Engine = InnoDB では容量があふれそうである（または負荷的に耐えられないのでメンテに入れた方がマシ） MySQL 5.6.17とそれ以降はオンラインでできる（ただしフルテキ
Amazon RDS for MySQLの空き容量の確認と対策 - Qiita
はじめに RDSのRIの期限が近づいてきて、今年も去年と同じでいいかなと、ふとRDSを確認したところ、RDSの空き容量がかなり減っていたことが発覚。(←社内用サーバだから普段放置だったけど、何気に空き容量3%切ったアラームもRDSダッシュボード上に出ていた。) RDSの空き容量の確認方法と空き容量を増やすための対策（主にフラグメンテーションの解消法）について、自分用メモ。 前提条件 RDS MySQL 5.6 InnoDB （長期運用によりdata_freeの容量が増える。） 社内用サーバ （重要度：低。シングル構成。データ容量は数百GB。複数DBが同居。データの挿入は分単位、削除は時単位でやってるようなサーバ。） 流れ 現状確認 : 状況・原因の把握とスケジュール決め。 暫定対応 : 不要なDBやテーブルがあれば手っ取り早かったが今回はなかったし、まだ期限に余裕もあったので、何もせず。
MySQL InnoDBの領域最適化 - Qiita
for i in {1..100000}; do mysql -u root -e "INSERT INTO test.users set uuid=uuid(), id=uuid();"; done その他: innodb_buffer_pool_instances: 1 (単純化のため) 最適化の動作確認 次の順に操作を行い最適化/断片化の様子を確認します. ランダムInsert mysqldump optimize ランダムInsert MySQLが苦手とされるランダムInsertを領域管理の面から確認して行きたいと思います. ランダムInsert後の初期状態のディスク容量およびbuffer poolの状態を確認します. $ sudo ls -lah /var/lib/mysql/test/users.ibd -rw-r-----. 1 mysql mysql 44M 12月 23
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
database/sqlのDB接続パラメータをアプリケーション内で明に指定する | おそらくはそれさえも平凡な日々
tl;dr Goのdatabase/sqlのDSN内のsql_modeやLocation等、固定したほうが良いパラメータ設定は、設定値に持たせるのではなく、アプリケーション内部で決め打ちしたほうが安全です。 本論 社内でMySQLを使っているので、それを例にとって書きます。 いわゆる、DSN(dataSourceName)呼ばれる、sql.Open に渡すDB接続文字列があります。これは、環境変数 DATABASE_URL 等に入れてアプリケーション内で読み出してDBに接続するでしょう。 DSNにはホスト名、ユーザー名、パスワードなどの接続先情報の他に、様々なオプションパラメータを記述することができます。以下にDSNの例を出しますが、この中の?以降がオプションパラメータです。 user:pass@tcp(myhost:3306)/dbname?collation=utf8mb4_unico
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。 一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。 このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり
sqlcommenter
sqlcommenter Attach SQL comments to correlate user code in ORMs and SQL drivers with SQL statements sqlcommenter is a suite of middlewares/plugins that enable your ORMs to augment SQL statements before execution, with comments containing information about the code that caused its execution. This helps in easily correlating slow performance with source code and giving insights into backend database
ぐるぐるSQLは止めてくださいという話 - Qiita
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
MySQL select 10 random rows from 600K rows fast
How can I best write a query that selects 10 rows randomly from a total of 600k?
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using JQ with SQLite
Dragonfly - The Fastest In-Memory Data Store
MySQL Bugs: #98600: Optimize table fails with duplicate entry on UNIQUE KEY
MySQL: How to create Column if not exists?
https://github.com/ichirin2501/doc/blob/master/innodb.md
