2024年6月22日に開催された「第14回 関西DB勉強会 」での、 『こんなに違うよ MySQLとPostgreSQL ~MySQLとPostgreSQLのニッチな違いを語る~』 の発表資料です。 https://kansaidbstudy.connpass.com/event/316348/
![こんなに違うよ MySQLとPostgreSQL /](https://cdn-ak-scissors.b.st-hatena.com/image/square/e436bc92ca183ad5c88004a565f12654b62a6ebd/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F2398ef954df34c139ba26b76d8acfb96%2Fslide_0.jpg%3F30717582)
AWS Aurora MySQLには、高性能を期待できる Parallel Query という機能があります。 実際、良いモノっぽいのですが、非常に情報が少ないので私めがいつものように掘り下げて、お役に立てればという徳を積む行為であります。 目次 Parallel Query とは リンク集 速度比較 費用の仕組み 設定による有効・無効 有効にできない条件 Parallel判定されるクエリ 結合クエリ innodb_buffer_pool_size との関係 その他 実践では Parallel Query とは 詳しくは下記リンクを見たほうがいいのですが、頑張って要約してみます。 通常のDB処理は、データを可能な限りメモリ上に置いておいて処理しようとしますが、オンメモリじゃないデータはストレージから取得する必要があり、データ取得後はDB本体における1スレッドがクエリ処理を行います。 Aur
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか?順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
Bring your app’s core features to users with App Intents とか App Intents 関連の要約
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
— そーだい@初代ALF (@soudai1025) 2015, 8月 24 とブーメラン投げて見事に刺さってるので今から記事書く。 両サイドにはかなり厳しい話もするが俺の本音を聴いておけ(関白宣言) まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。 なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。 むしろ実際に使ってみた際の違いをにフォーカスする。 1. SQLの違い 基本的にMySQLでやっていたことはPostgreSQL出来る。 しかし関数の挙動の違いは幾つかある。 例えば時間から曜日に該当する数字に変換した場合に MySQL → date_format(time,"%w") 0から始まり、日曜日に該当する PostgreSQL → to_char(time,'D') 1から始まり、日曜日に該当する など挙動に互換性
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く