MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
MySQLで3億レコード物理削除した話 - Qiita
はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分である12'000'000件ほど。このse
MySQL5.7以降で条件付きのユニーク制約をかけるためのベストプラクティス - Qiita
解決したい問題 PostgreSQLなどでは部分Indexが使えることでテーブルの一部分に対するユニーク制約などをDBで実現できたのに、MySQLではそれができないのでつらすぎる問題を解決したい。 今回は、以下のようなユーザーアカウントテーブルに対する操作を例として記載します。 CREATE TABLE IF NOT EXISTS account ( id BIGINT NOT NULL AUTO_INCREMENT, email VARCHAR(255) NULL, create_timestamp TIMESTAMP NULL, update_timestamp TIMESTAMP NULL, del_flg BOOL NOT NULL, -- 0: 有効な会員 1:削除済み PRIMARY KEY(id) ) このときに、del_flg=0の有効な会員に対してのみユニークキー制約をか
MySQLの物理削除によるパフォーマンスの悪化とその回避策について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめまして、Yahoo!ショッピングでシステム開発を担当している村上です。 Yahoo!ショッピングでは数億件にのぼる商品が日々更新されています。 今回はそれを支える巨大なDBの運用の中で遭遇したMySQLのアンチパターンと、回避した方法について紹介いたします。 特定のテーブルをJoinするとすごく遅くなる Yahoo!ショッピングでは商品を出品するためのツールがあります。 商品情報には「商品名」「価格」といった、任意で設定可能な項目のほか、「ブランド」「商品種別」など、製品ごとに入力する内容が決まっている項目を、マスター情報としてテーブルで管理しています。 このマスター情報を利用して、出品の際に入力情報が正確であるかどうか確か
MariaDB(MySQL)の照合順序の話
ぼくが初めてデータベースという存在を知ったのは25年ほど前のBtrieveだったと記憶していますが、検索／ソートができて自分でコーディングするよりも早いことに感動したものです。 RDBMS (Relational DataBase Management System) が普及しはじめてからはSQL文だけで集計処理はおろか、表結合まで出来るし、いったいどこまで生産効率が上がってしまうのかと恐ろしくも感じました。 実際、RDBMSが出た当時はSQL ServerやOracle、非常に安価な案件ではAccessなんて例もありましたが、業務システムを開発する上で利用するのはデータの蓄積、参照、集計処理くらいなもので、RDBMS間でSQL文にもそこまで大きな違いはなく、どれも似たようなコーディングで済むため開発効率はとても上がりました。 細かいことをいえばストアドプロシージャの有無や作り方、関数名と
MySQLの文字コードとCollation - Qiita
まずMySQLの文字コードですが絵文字のみでなく、JIS X 0213の第3・4水準漢字の 一部にUTF8 4バイト文字があり（まぁまず使われないと思いますが）、 MySQLの文字コードはこれからはutf8mb4一択のようです。 charsetは、サーバ、クライアント、サーバー/クライアント感の接続、データベース、、テーブル、カラムで個別に指定でき、 問題を起こさないようにするには、すべて揃えたほうが無難であります。 character_set_server=utf8mb4 character_set_client=utf8mb4 character_set_connection=utf8mb4 character_set_database=utf8mb4 character_set_results=utf8mb4
MySQLでJSON型を使う（パフォーマンス編） | スマートスタイル TECH BLOG
MySQLではバージョン 5.7.8 以降でJSON型がサポートされるようになりました。 このシリーズでは基本編、パフォーマンス編、論理設計編と、JSON型のデータ操作方法やどのような場合に使用を検討するべきかをベンチマーク結果も踏まえて探っていきたいと思います。 MySQLでJSON型を使う（基本編） MySQLでJSON型を使う（パフォーマンス編） MySQLでJSON型を使う（論理設計編） 今回はJSON型を使った場合のパフォーマンスについて見ていきたいと思います。 検証マシンスペックとMySQLの設定 今回はAWSのEC2上にMySQL5.7.18を構築して検証を行いました。 マシンスペックは以下です。 インスタンスタイプ： t2.medium CPU: v2core メモリ: 4GB MySQLで設定変更したのは以下のみで、後はデフォルトです。 [mysql] [mysqld]
高速処理化！MySQLのパーティショニング機能を使ってみよう | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
みなさん、最近人生のパーティショニングしてますか？ こんにちは、勝利です。 今回はMySQLのパーティショニングについて紹介させていただきます。 MySQLのパーティショニングとは？ MySQL5.1ぐらいから使えるようになった、1つのテーブルを分割する機能。 テーブルを分割するので、格納できる根本的な容量の拡張や、やり方(Plunning)によっては高速処理を実現できます。 分割した際のデータ振り分け方法としては大体以下のような形があります。 RANGE ・・・ パーティションごとに範囲を指定して振り分ける LIST ・・・ パーティションごとに格納する値で振り分ける HASH ・・・ 1つのカラムの値を式の結果で振り分ける KEY ・・・ １つ以上のカラムの値をMD5関数等で評価して分割する 使用するメリットとしては下記2点のようなことが考えられます。 メリット１ [高速化が見込める]
MySQL パーティショニングまとめ - Qiita
参考URL パーティショニングとは パーティショニングの種類 RANGE パーティショニング このタイプのパーティショニングは、指定された範囲に含まれるカラム値に基づいて、行をパーティションに割り当てます。 LIST パーティショニング RANGE によるパーティショニングに似ていますが、別個の値のセットのいずれかに一致するカラムに基づいて、パーティションが選択されます。 HASH パーティショニング このタイプのパーティショニングでは、テーブルに挿入される行内のカラム値を操作するユーザー定義式によって返される値に基づいて、パーティションが選択されます。関数は、負ではない整数値を返す MySQL の有効な式で構成できます。このタイプを拡張した LINEAR HASH も使用できます。 KEY パーティショニング このタイプのパーティショニングは、HASH によるパーティショニングに似ていま
Amazon RDS for MySQL と全文検索 | DevelopersIO
こんにちは、藤本です。 先日開催された Developers.IO 2017 で「Amazon Elasticsearch Service の使いドコロ」というタイトルで登壇しました。 Developers.IO 2017セッション「Amazon Elasticsearch Service の使いドコロ」で話しました #cmdevio2017 資料を作成する中で MySQL 5.7 から追加された全文検索の日本語対応に関して調べました。せっかくなのでまとめた内容をブログに書き出すとともに、RDS だとどこまでできるのかということを追加調査してみました。 MySQL 5.7 の日本語全文検索に関しては公式ドキュメントや、Oracle の方のスライドに詳しく説明されていますので、詳しく知りたい方は下記をご参照ください。 12.9 Full-Text Search Functions MySQL
MySQL5.7 InnoDB のN-gram全文検索を検証＆サービス導入した
MySQL5.7・InnoDB・N-gram という環境下で全文検索の挙動やパフォーマンスについて検証を行った。FULLTEXT INDEXは以前はMyISAMでしか利用できなかったが、 5.6.4からInnoDBでのサポートが始まっていた。 InnoDBの全文検索は5.7、特に5.7.6以降でいわゆるCJK（中国語・日本語・韓国語）がN-gramで標準サポートされ始め、 CREATE TABLE文で簡単にパーサーを指定できる構文のサポート、 設定やクエリの組立で考えないといけない事が減った事で導入障壁がかなり下がっている。 ※4.1と5.0でサービス導入経験がある私の個人的な比較感想です。 FULLTEXT INDEXも他のINDEXと同様にデータ更新・削除の際にINDEXのrebuildが走るので更新時の負荷には注意が必要で、FULLTEXT INDEXの場合は「rebuild負荷が列
プロダクトに日本語の全文検索機能を加えたい、検索インデックスのリアルタイム更新もほしい というときの手軽な方法 - Qiita
プロダクトに日本語の全文検索機能を加えたい、検索インデックスのリアルタイム更新もほしい というときの手軽な方法MySQL検索InnoDB全文検索mysql5.7 プロダクトオーナー や ユーザからの要望によって 検索機能 の必要性に迫られたとき、 ありふれた方法 でかつ 速攻 で実装する方法です 要件 日本語文章 などのデータに対して、全文検索できる 検索リクエストに対して、十分高速にレスポンスを返す 検索インデックスはリアルタイム更新され、実データと相違がでない 検索対象のデータが追加／更新／削除されたら検索結果にも即反映される 希望 できるだけ速く実装／提供したい できるだけ運用コストも小さくしたい おすすめな方法 もしもプロダクトがMySQL互換のデータベースを使っていたら、要件を満たして 明日にも提供できる かもしれません（気持ちです、フロント周りの実装など事情によって当然コストが
RDS for MySQLで変更すべきパラメータチューニング - なからなLife
呼ばれたきがしたので soudai.hatenablog.com なお、InnoDB限定のお話ですよ。MyISAMを（システムテーブル以外で）使ったことない若輩者なので。 ちょっと余裕がないこともあり、思いつく最小限のことだけ書きます。追加で思いついたら後ほど＆温かいフォロー（というマサカリ？）歓迎。 checkpointに影響がある値 innodb_log_file_size Redoログのファイルサイズです。 生MySQLのデフォルトは「50331648 Byte（48MB）」、RDSのデフォルトは「134217728 Byte（128MB）」。大きなバッチ処理がなければ間に合うかも知れないですが、広げたほうがよいでしょう。 適切な値の範囲は、1M バイトから 1/バッファープールの N 番目のサイズまでです。ここで、N はグループ内のログファイルの数です。 https://dev.m
テーブルやカラムのCollationは揃えよう - 41から始めました
元ネタはMySQL Casualのslack この辺以降 それを見て、 そういや自分も2年前(DB移行時)にこれ調べたなー 社内メンバーに改めてちゃんと周知しよう なんか記事書くか という軽い備忘録的な感じ。 ちなみに、揃えないとどうなるか？ slackにもあったように、 インデックスが効かない！(抽出はできる) 試しにテストテーブルを作る(個人の趣味が多分に含まれているのは気にしないこと) 使った環境はMySQL8.0.13 CREATE TABLE `test1` ( `test1_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'testID1', `test1_name` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL COMMENT '名前', `test1
MySQL 8.0は何が優れていて、どこに注意すべきか。データベース専門家が新機能を徹底解説 - エンジニアHub｜Webエンジニアのキャリアを考える！
MySQL 8.0は何が優れていて、どこに注意すべきか。データベース専門家が新機能を徹底解説 MySQLの最新版「MySQL 8.0」正式版が2018年4月にリリースされました。数多くの機能や設定が追加・変更されているMySQL 8.0の「知っておきたい便利な機能」や「危険なハマりどころ」などを、My SQLの専門家に教えてもらいました。 2018年4月、世界中のエンジニアが待ちに待ったMySQL 8.0の正式版がリリースされました。本リリースに伴い、数多くの機能や設定が追加・変更されており、MySQLがより便利なものへと進化しています。 MySQL 8.0で積極的に利用すべき目玉機能や、知っておかなければ危険なハマりどころなど重要な変更点を、MySQLの保守サポートやコンサルティングなどを専門とする株式会社スマートスタイルの中野真也さんと成田優隆さんに解説してもらいました。 中野真也（な
MySQL の X Protocol/X DevAPI 周りについて調査したのをまとめたののメモ - tokuhirom's blog
MySQL 8 以後では X Protocol がサポートされている(5.7 系では部分的なサポートであり、X Protocol を本格的に利用する場合には 8 を利用することが推奨されているようだ) 通信は従来の MySQL Protocol と異なり、Protocol Buffers Based となっていて、各言語のドライバの実装が簡単になっている(protocol buffers がその言語でサポートされていれば、だが) これにより今後 libmysqlclient に依存せずに各言語のドライバが実装されるようになって運用管理が簡単になるんじゃないかと私は考えています。 実際に、mysql-connector-nodejsは X Protocol のみをサポートしていて、libmysqlclient への依存がありません。 また、X Protocol/X DevAPI は asyn
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.js MySQL Driver Benchmarks 2018
MySQLの容量とか圧縮まわり
MySQL/InnoDB の裏側 / Rails Developers Meetup 2018 Day 1
