InnoDBのすゝめ（仮）
2. Copyright © GREE, Inc. All Rights Reserved. 自己紹介 ● わりと MySQL のひと ● 3.23.58 から使ってる ● 前職の頃、10年以上前は、 MMORPG の DB の設計などもやってました ● むかしは Resource Monitoring も力入れてやってた ● ganglia & rrdcached の（たぶん）ヘビーユーザ ● というわけで、自分は Monitoring を大事にする ● 一時期は Flare という OSS の bugfix などもやってた ● さいきんは、ハードウェアの評価をしている時間が長かった ● たまに Linux の TCP プロトコルスタックについて調べたりもする 2
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
MySQLのインデックスの使い方 - Qiita
SQLのパフォーマンスチューニングで考えるべきことの一つに、インデックスがある。インデックス無しで作業をしてみて、インデックスの重要性を理解しましょう。 ディスクからのデータの読み込み ディスク上ではファイルという概念はない。ブロックという概念がある。普段なら一つのファイルがいくつかのブロックを使用している。ブロックの順位が決まっていて、ファイルが分割された後に各部分がそれぞれのブロックに保存されます。 ファイルを読み込んでる時に、各ブロックのデータを取得して組み立てる。フラグメンテーションによってそのブロックがディスクの色んな位置に置いてある可能性があるので、それによって読み込みが遅くなりかねない。 ファイルの中で何かを探している時に、全てのブロックからデータを取得する必要が出てくる。ファイルが大きければ大きいほどブロックの数が増えて検索がすごく遅くなる。 MySQLでのデータ検索 My
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.4 Reference Manual :: 8.4.1.2 Caching SHA-2 Pluggable Authentication
GitHub - radondb/radon: RadonDB is an open source, cloud-native MySQL database for building global, scalable cloud services