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
Sharding & IDs at Instagram
With more than 25 photos and 90 likes every second, we store a lot of data here at Instagram. To make sure all of our important data fits into memory and is available quickly for our users, we’ve begun to shard our data — in other words, place the data in many smaller buckets, each holding a part of the data. Our application servers run Django with PostgreSQL as our back-end database. Our first qu
日々の覚書: utf8mb4_0900_ai_ci の速度をどう見るか
TL;DR MySQL 8.0からデフォルトの照合順序が latin1_swedish_ci から utf8mb4_0900_ai_ci になった さすがに latin1 をそのまま使っているとは思えないけれど、 utf8mb4 だけで見てもデフォルトは utf8mb4_general_ci から utf8mb4_0900_ai_ci に変更になっている 「思ったよりは遅くならない」と見るか、「そんなに遅くなるのか」と見るかは人による気がする まずは等価比較。 それぞれ10億回繰り返しているので、1回当たりの時間はナノ秒単位になる。 あと、データは保管せずただ比較しているだけなので、単純にCPU勝負のワークロードになる。 mysql80 8> SELECT BENCHMARK(1000000000, '1' = '1' COLLATE utf8mb4_0900_ai_ci) AS utf8
MySQL の utf8mb4 の文字照合順序まとめ
MySQL で文字コードを utf8mb4 を使うことになったので、照合順序を決めるための自分用メモです 巷にたくさん記事はあるけど、現時点(2021/03)でまとめておきたかった 条件 MySQL バージョン: 8.0.22 OS: MacOS クライアント: MySQL Workbench 確認手法 次のクエリを実行する。照合順序だけ変更して確認 SELECT 'はは' <> 'ハハ' COLLATE utf8mb4_bin, 'びょういん' <> 'びよういん' COLLATE utf8mb4_bin, 'はは' <> 'ぱぱ' COLLATE utf8mb4_bin, 'ハハ' <> 'ﾊﾊ' COLLATE utf8mb4_bin, 'A' <> 'a' COLLATE utf8mb4_bin, '🍣' <> '🍺' COLLATE utf8mb4_bin ;
pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
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
