MySQL JOIN Types Poster - Steve Stedman
So many times I have been asked for help with a query, where the question really comes down to the understanding of the difference between INNER and LEFT or RIGHT JOINs. I created this poster a few years ago and I keep it posted on the wall at the office. This way when I am trying to explain JOIN types, I just refer to the poster. I have created the poster below to help describe JOIN types in My S
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
Ansibleで本番レベルのMySQLレプリケーションを構築して見よう。 - Qiita
はじまる前に この記事では主にAnsibleの機能を紹介したいと思います。 playbookに記述したMySQLの詳細を知りたい方は次の記事を参照してください。 CentOS 7.3でMySQL 5.7を設置、かなり勉強になりました。 MySQLのSQLモードをstrictモードで設定する。 やりたいこと 実際のサービス環境でMySQLを運用する場合、このくらいは必要だと思ったことを書いてみた。 master1台とslave2台のレプリケーション構成 スロークエリを残す。 MySQLをstrictモードで使う。 これらをAnsibleのplaybookで作成する。 ファイル構成 # mysqlのrole roles/mysql ├── handlers │ └── main.yml ├── tasks │ └── main.yml └── vars └── main.yml # d
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
docker-composeでmysql使うとき初回起動時に複数のDBを作る方法 - Qiita
とりあえず自分が慣れてるんで docker-compose のymlの書式で書きますが、コマンドラインからでも同じことはできるはずでやんす。 tl; dr MYSQL_DATABASE をenvに指定すれば１個は作ってくれるけど、複数個のDBは作ってくれない /docker-entrypoint-initdb.d にあるSQLは勝手に突っ込んでくれるしシェルがあればシェルを実行してくれる /docker-entrypoint-initdb.d にいい感じのシェルを書くといい感じにDBが作れるというか、なんでもできる。 やりたいこと 以下のような docker-compose.yml を用意して、２つのDBを作りたいと思っています。 version: '2' services: db: image: mysql environment: MYSQL_DATABASE: first_datab
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
MySQLでお手軽デッドロック - jfluteの日記
-- MEMBER_SEA は MEMBER の 1:n の子テーブル delete from MEMBER_SEA where MEMBER_ID = 3 insert into MEMBER_SEA ...(MEMBER_ID は 3) ん？ 最初のdeleteが互いに「0件削除」だとデッドロック。別トランザクションのMEMBER_IDが別ID(例えば4)でもデッドロック。(とにかく両方のトランザクションでdeleteが0件であれば) これは... ネクストキーロックって？ MySQLのInnoDBには「ネクストキーロック」という機構があります。 詳しくは、ぐぐってくれればOKですが、ひとまず参考になるオフィシャルサイトのページを。 => ネクスト キー ロック:ファントムの問題を防ぐ 難しいこと書いてありますねぇ。 「ギャップ」って何!? ここでいうインデックスレコードって!? とに
MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。（もちろん、きっかは自分がドツボにはまったから） ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 （というか、これが問題なく読めて理解できる人はこの記事読む必要ない….） 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
MySQL ってクソだよね - Qiita
CREATE TABLE tbl_unique_test ( id INTEGER NOT NULL, value INTEGER NOT NULL DEFAULT 0, PRIMARY KEY (id) ); 挿入してみます。 mysql> INSERT INTO tbl_unique_test VALUES (1,1); Query OK, 1 row affected (0.50 sec) 同じクエリをもう一回叩いてみます。 mysql> INSERT INTO tbl_unique_test VALUES (1,1); ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY' はい。 IGNORE を指定してみます。 mysql> INSERT IGNORE INTO tbl_unique_test VALUES (1,1)
MySQLのAUTO_INCREMENTについて色々と調べてみた。 - Qiita
AUTO_INCREMENTとは カラムに値が指定されなかった場合、MySQLが自動的に値を割り当てる。 データ型は整数。 値は1ずつ増加して連番になる。 基本的なこと。 テストテーブル作成 mysql> CREATE TABLE fruit(id INT AUTO_INCREMENT NOT NULL PRIMARY KEY, name VARCHAR(50), price INT); mysql> DESC fruit; +-------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+----------------+ | id | in
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 パーティショニングまとめ - Qiita
参考URL パーティショニングとは パーティショニングの種類 RANGE パーティショニング このタイプのパーティショニングは、指定された範囲に含まれるカラム値に基づいて、行をパーティションに割り当てます。 LIST パーティショニング RANGE によるパーティショニングに似ていますが、別個の値のセットのいずれかに一致するカラムに基づいて、パーティションが選択されます。 HASH パーティショニング このタイプのパーティショニングでは、テーブルに挿入される行内のカラム値を操作するユーザー定義式によって返される値に基づいて、パーティションが選択されます。関数は、負ではない整数値を返す MySQL の有効な式で構成できます。このタイプを拡張した LINEAR HASH も使用できます。 KEY パーティショニング このタイプのパーティショニングは、HASH によるパーティショニングに似ていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mysqlバックアップの取り方 - Qiita
mysqldumpでコマンドラインからパスワードを入力しない - Qiita
https://codeday.me/jp/qa/20190228/339200.html
MariaDBのインストール/初期設定 [CentOS7] - Qiita![MariaDBのインストール/初期設定 [CentOS7] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/7d6602abf8f5dca1989e72f9b6b76a4475b5ac71/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9TWFyaWFEQiVFMyU4MSVBRSVFMyU4MiVBNCVFMyU4MyVCMyVFMyU4MiVCOSVFMyU4MyU4OCVFMyU4MyVCQyVFMyU4MyVBQiUyRiVFNSU4OCU5RCVFNiU5QyU5RiVFOCVBOCVBRCVFNSVBRSU5QSUyMCU1QkNlbnRPUzclNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWUyOGQxZGEyNDlkOGNiZGUwYTU3OGY3ZDkyYzNkYzY5%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBwb25zZWEmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTYyY2M1ZDQ1N2NmMTczMmQ4ZTExYTZmODZjMGE2NGFj%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dc93e6f1d1e1747b5536f51efe38397d7)
GitHub - sqldef/sqldef: Idempotent schema management for MySQL, PostgreSQL, and more
Got "Duplicated entry '1' for key 'PRIMARY'" when specified the value of a `AUTO_INCREMENT` field · Issue #1230 · jinzhu/gorm · GitHub
doc/innodb.md at master · ichirin2501/doc
Dockerコンテナ内に入らずにMySQL公式コンテナの中にSQL等を実行するメモ - Qiita
