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 のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
MongoDBの様なNoSQLに勢いがあるのは何故ですか？SQLと比べてどんな利点や欠点がありますか？ - Quora
回答 (3件中の1件目) ハイプサイクルという概念をGartnerグループが提唱してまして、様々な流行りスタリのサイクルを分析する標準的な方法となっています。 ハイプとは過度な期待や熱狂を意味する言葉です。一発屋芸人の人気のカーブみたいなもので、テツandトモみたいに安定する場合と、消えていくものがあります。芸人ではありませんがDA PUMPは一茶の人間性もありまして、次は厳しいけど定着すると思っています。 なんだかのトリガーで評価が上がり始め、ピークを迎える。その後評価が下がっていき、底を打つと少し上がって定着するという経過をたどるとしています。これと同じモデルで、流行りのハイテク...
MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。（もちろん、きっかは自分がドツボにはまったから） ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 （というか、これが問題なく読めて理解できる人はこの記事読む必要ない….） 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
サイボウズ版 MySQL パフォーマンスチューニングとその結果 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年
モンストのサーバー負荷との戦い 〜あけおめ2018編〜 / bcu_30_server_9
スマホアプリ「モンスターストライク」のサーバー負荷は、年末年始に1年のピークを迎えます。2018年元旦のサーバー負荷に立ち向かうために実施した対策の一例として、データベースサーバー（MySQL）を安全に水平分割した事例を紹介します。見積もりから計画、実施に至るまでを時系列で振り返ります。
Rails4で悲観的ロックを実装する - Rails Webook
ActiveRecordでは、lockとやlock!メソッドを使うことで悲観的ロックを実現することができます。 ロック自体は、基本的にはSELECT … FOR UPDATEが発行されてロックがされますが、DBに依存するので実際に発行されるSQLコードを確認することが大切です。 動作確認 Rails 4.1 ActiveRecord 4.1 mysql2 0.3.7 MySQL Server 5.6.21 Mac OS X 10.10 目次 悲観的ロックとは MySQLの設定とモデルの準備 悲観的ロックの使い方 (WIP)悲観的ロックのテスト 悲観的ロックとは悲観的ロックとは、競合が発生する可能性が十分あるという状況に向いたロック手法です。 DB側でレコードをロックし、ロックされたレコードを更新できないようにします。 あまりに競合が発生する場合には、ロックにより処理が待たされる時間が多くな
MySQLでGROUP BYとORDER BYを同時に使用する場合に気をつけたいこと | 日記の間 | あかつきのお宿
今さらな話ではあるんですが、前にも一度同じ過ちを犯したことがあるので、ここでちゃんと自分を懲らしめておきたいと思います。 前提条件 例えば、データベースにこんなデータが入っているとする。 +----+-----------+--------+------+---------------------+ | id | author_id | title | text | created | +----+-----------+--------+----------------------------+ | 1 | 1 | title1 | text | 2012-10-01 12:00:00 | | 2 | 2 | title2 | text | 2012-10-02 12:00:00 | | 3 | 1 | title3 | text | 2012-10-03 12:00:00 | | 4
脱！ゆるふわMySQL - Qiita
dots girls Advent Calendar 2015の出だしからしゃしゃってる吉澤です！ 何も考えないで現時点で最新のMySQL5.7.9を開発環境にインストールしたところ、今までみたことの無いエラーが出てしまいました。 Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column ’*.*' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
MySQLのFLOAT型を使う理由が見つからない件 - hnwの日記
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか？と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型（32bit）で実現されます*1。
mysql文字コードエラーの解消法方 - yeyue's diary
Mysql2::Error: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=':とかいうエラーが出て困った。まずは、MySQLシステム変数の値を確認しました。 MySQLはデフォルト言語が Latin1 に設定されているので、インストール時にコンパイルオプションを設定しなかった場合は Latin1 になっています。 しかし、my.cnfの[mysqld]に"character-set-server=utf8"を設定し、再起動させたので以下の様に表示されました。 mysql> show variables like '%character%'; +--------------------------+---------------
公式MySQLコンテナをDocker for Macで起動した際に外部から接続（リモート）ができないので困った - Qiita
最近、久しぶりにDockerを触ったら、Docker for Macという便利なものになっていたので、ちょっと色々と試してみた。 そこで、起きたのが公式MySQLコンテナをDocker for Macで起動した際に外部から接続（リモート接続）ができないという問題。 $ mysql -u root -p -h 127.0.0.1 --port 3306 mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) hostをlocalhost、portを3306としてmysqlに接続しにいこうとしたところエラーが発生。 あまり深
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLパフォーマンスチューニングTIPS
https://developer.hatenastaff.com/entry/2019/01/15/120431
Dockerで立ち上げたmysqldに接続する | クロジカ
PostgreSQLとMySQLで、僕がよく使うシステムコマンドのメモ - Qiita
