MySQLのEXPLAIN - Qiita
クエリを最適化するということは、 ・書き換える前と後でクエリの実行結果が同じになる ・EXPLAINがよりよい実行結果を表示する クエリの実行計画を調べるためには、 SELECT文の先頭に「EXPLAIN」をつけて実行する フィールド id/select_type クエリの種類を表すもの。 クエリの種類とはJOIN、サブクエリ、UNIONおよびそれらの組み合わせのことで、 select_typeの内容もその組み合わせから導き出されたものである。 JOINの場合 MySQLが実行できるJOINの種類は「Nested Look Join(NLJ)」の一種類しかない。 テーブルを一つずつ順に処理していく方式のこと。 クエリがJOINだけから構成される場合、select_typeは「SIMPLE」と表示される。 SIMPLEではidが全て同じ値になる。 EXPLAINの出力の順序がどのテーブルから
MySQL EXPLAINのそれぞれの項目についての覚書 - Qiita
id/select_type/table どのテーブルがどの順番でアクセスされているか id 実行順番を表す 数字が同じなら複数のクエリが１つのクエリとして実行されている select_typeの詳細 SIMPLE 単一のテーブル サブクエリが絡む場合 PRIMARY 外部クエリ SUBQUERY 相関関係の無いサブクエリ DEPENDENT SUBQUERY 相関関係のあるサブクエリ UNCACHEABLE SUBQUERY 実行する度に結果が変わる可能性のあるサブクエリ DERIVED FROM句で用いられているサブクエリ table 対象テーブルの名称 partition どのpartisionテーブルを使用したか 複数にまたがる時は複数の値が表示される type レコードアクセスタイプ typeの詳細 const pk or uniqueインデックスを使用したルックアップによるアク
【MySQL】遅いselect文の原因を調査する【explainの読み方】 - Qiita
key テーブルにアクセスするために使ったindexを示す。 ちなみに、possible_keysは「使える候補」で、実際につかったかどうかはkeyの値を見る。 key_len 選択されたキーの長さ。 インデックスのキー長が短いほうが高速になるので、迷ったら長さの短いほうにインデックスをつけるといい。 rows selectの取得件数の見積もり。 ざっくりとしたものなので、where句次第ではもっと少ない件数が返ってくることもある。 extra ほかに使用している条件などがあれば、ここに出力される。 チューニング方法の例 type=null かつ key=null の場合 →インデックスが張られてない＆テーブルのフルスキャンが行われている。 where条件で使うカラムにインデックスを張る。 もしくは、インデックスが張られたカラムをwhere条件の中に追加する。 extra=Using fi
SQL実行計画の疑問解決には「とりあえずEXPLAIN」しよう
EXPLAINステートメントとは EXPLAINは、SQLの実行計画に関する情報を取得するためのステートメントです。実行計画とは「どのインデックスを使って（あるいはインデックスを使わずにテーブルスキャンで）クエリーを処理するか」をMySQLが判断した結果のことです。「インデックスはちゃんと使われているだろうか」「インデックスでどこまでクエリーを効率的に処理できているだろうか」という疑問が湧いた時には、「とりあえずEXPLAINで」となりますよね。 EXPLAINのマニュアルはこちらに、EXPLAIN の出力結果のカラムの意味についてはこちらに記載があります。 EXPLAINの何を見るか たとえば、次のような重いクエリーがあったとしましょう。 mysql> SELECT COUNT(some_column) FROM some_table WHERE some_column = xxx; +
データベース性能を向上させる「インデックス」を理解する
あの“津崎さん”も保有する難関資格「データベーススペシャリスト」。本企画では、データベーススペシャリスト試験 午前／午後試験対策のための「基礎知識」を抜粋してお届けします。今回は「インデックス」の基礎を解説します。
DBのインデックスと複合インデックス - Qiita
データの並び順が社員コード順になっていないので、全件検索し該当レコードを探す動きになる Q:主キーインデックスと普通のインデックスの違いは？ インデックスという視点では違いはない。主キーはDBが自動でインデックスをつけ削除不可である。したがって何もインデックスを作成しなくても主キーのインデックスは必ず生成される。 ※主キー順は非常に重要である。 上記の社員テーブルにおいて社員コードのみで絞り込む要件しかない場合、 １．社員テーブル(主キー順：所属コード,社員コード) ２．社員テーブル(主キー順：社員コード,所属コード) 『１．』の主キーでは主キーインデックスが所属コード、社員コードの順となるため新しく社員コードのみのインデックスを作成する必要がある。 しかし『２．』の主キーなら主キーインデックスが社員順となるため新しくインデックスを作成する必要はない。 見た目の区分に合わせて主キーを作りた
SQLインジェクションとは何か？その正体とクラッキング対策。
世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その本質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン
シャーディング - Qiita
データベースにおける分割手法の１つで、データを複数のノードのディスクに分割配置することで、データベースへのリクエストを分散し全体のスループットを上げる目的で利用されます。 基本的にはお互いのノードではシェアードナッシングの独立したデータを持っているので、各ノードは自分の担当するデータに対してクエリを実行します。 具体的には、アプリケーションからの書き込みのリクエストが支配的で、Primary/Backupのような処理系統によるルーティングではあまり負荷の分散に繋がらないようなケースで利用されます。 e.g) - スケールしたアプリケーションサーバからの同時接続数の限界 - 巨大なデータを扱う際にbufferが溢れDisk/IOが発生する (appendix) Primary/Backup (Master/Slave) アプリケーションの処理の系統によって接続先のデータベースノードを切り替え
SQLアンチパターンもりもりDBを設計しよう！ - Qiita
概要 名著SQLアンチパターンを読み終えたので、それの復習のために悍ましいデータベースを作ろうと思った。 まず前半では、SQLアンチパターンを意図的に盛り込み、目も当てられない酷い設計をします。 そのあとリファクタリングを行なったER図に書き直していきます。 なお、真面目に書くと参考書の丸写しになってしまうので、この記事は アンチパターンもりもりのER図を見て嫌悪感を学習し、設計に役立てようという趣向のもと、詳しい説明は省きます。 とても良い本なので読んでください。 想定するシステムの概要と状況 目的において適切かはわかりませんが、とりあえず考えることの多い”お金”を扱うシステムを想定してみます。 私はブラックジョークが好きなので、今回は「ちょっと怖い金融屋さんが使う債務者管理システム」のER図を設計してみようと思います。 ざっくりした要件 債務者を登録でき、プロフィールを入力できる。 債
[補足資料] Go Conference 2019 Springでdatabase/sql入門を発表した #gocon - My External Storage
database/sql入門 | 2019 Spring Sessions データベースサーバについて DockerHubを使えば使い捨てのRDSをすぐ起動することができる。 DockerHubを見れば公式イメージがある。 mysql | Docker Hub https://hub.docker.com/_/mysql マイグレーションツールについて sql-migrateを推した。 リポジトリパターンについて 設計パターンとして、DBをあつかうときに大抵は選択するであろうリポジトリパターンを紹介した。 pospomeさんがBOOTHで販売しているpospomeのサーバサイドアーキテクチャにGoで書かれた「第4章 詳解リポジトリパターン」という章があるのでそちらを読むと良い（その前の章のアーキテクチャ設計に関する部分も大変参考になる）。 ORMについて ORMについてはizuminさんら
![[補足資料] Go Conference 2019 Springでdatabase/sql入門を発表した #gocon - My External Storage](https://cdn-ak-scissors.b.st-hatena.com/image/square/f3ca5145f819bb37539bafba90f1c2353dbe1f00/height=288;version=1;width=512/https%3A%2F%2Fbudougumi0617.github.io%2Flogos%2FGo-Logo_Aqua.png){kind=logo}
Go database/sql チュートリアル 01 - 概要 · golang.shop
Go database/sqlチュートリアルの概要の日本語意訳になります。 概要 Go言語でデータベースにアクセスするには、sql.DBを使います。この型を使用することで、ステートメントやトランザクションを生成し、クエリを実行し、結果を取得することができます。 最初に知っておくべきこととして、sql.DBはデータベース接続ではないということです。 また特定のデータベース製品でいうところの、「データベース」や「スキーマ」に対応するものでもありません。sql.DBは抽象インターフェースであり、ローカルファイル・ネットワーク経由のアクセス・メモリ内・プロセス内といった様々な種類の可能性があるデータベースの存在になります。 sql.DBはいくつかの重要なタスクを裏側で実行します。 ドライバ経由にて、実際のデータベースへの接続のオープンとクローズを実行 必要に応じて、前述の通り様々なデータベースのコ
gocon-2018-how-we-go-test-with-rdbms.pdf - Speaker Deck
Many of API servers tend to interact with RDBMS to serve structured data for frontend. Unlike other languages with full-featureed web application frameworks, it seems, at first glance, a little difficult to write tests for Go applications using RDBMS. However, knowing `database/sql` with a bit of RDBMS knowledge is just enough to write clean tests for RDBMS backed Go applications. In this talk, I'
100000
sqlx-transactionmanager github.com これは Perl でいう @nekokak さん作の DBIx-TransactionManager をベースに作ったもの。今担当している会社のプロジェクト内で github.com/jmoiron/sqlx を使っており、それの transaction manager があるといいよねーとなったので作成した。 既に sqlx を使っている場合、import に書かれているパッケージ名を次のように変えるだけで、sqlx で提供されている全てのメソッドが今までと同じように使える。 import sqlx "github.com/Code-Hex/sqlx-transactionmanager" 単純に sqlx をラップしているだけなため、これだけでエラーをあまり吐かずに置き換えることが可能。しかし、database/sq
Clean SQL Transactions in Golang | pseudomuto.com
TL;DR: Working with db transactions in Go should be simple, so I made some utilities to help with that. You can see the gist containing all the code here. The database/sql package has everything you need in order to work with db transactions for most vendors. Typically, you’ll write something like this: While this code works, there are a few of things I think could be better about it. Every transa
goでDBのテストを書くときに、go-sqlmockを使ってみた - 布団の中にいたい
goでDB周りのテストをするときに、毎度テスト用のDBにデータを流し込んで終わったら削除する、みたいなことをしていたのだけれど、若干面倒だなーと思い始めたのでgo-sqlmockを使ってみました。 go-sqlmockはgo用のmockライブラリです。 github.com 公式のサンプルではそのままdatabase/sqlを使っていますが、普通にgormでも使えて以下のような感じで使えます。 func main() { db, mock, err := sqlmock.New() if err != nil { log.Fatal(err) } gdb, err := gorm.Open("sqlmock", db) if err != nil { log.Fatal(err) } // 後は、gorm.Openの返り値を使って色々やる } gorm.Openの引数にsqlmockを使っ
もうRDBとNoSQLを選ぶ必要はない MySQLなら両方できる
2018年4月、MySQL 8.0 GAがリリースされた。早速5月23日には「Oracle MySQL Innovation Day 2018 Tokyo」が開催され、新バージョン詳細が日本のユーザーに紹介された。MySQLは世界有数の大規模Webサイトで使われるRDBでありながら、新バージョンではドキュメントストア機能を多く盛り込みNoSQLとしても使えるデータベースとなっている。当日は気になる新サービス構想についての言及もあった。 MySQL 8.0はRDBとNoSQLのハイブリッドデータモデルへと MySQL 8.0といえば、このツイートが象徴的だ。投稿者はベルギー在住のMySQLエバンジェリストでありMySQLコミュニティマネージャのフレデリック・デカン（Frederic Descamps）氏。米国カリフォルニア州レッドウッドショアー（オラクル本社）でのMySQL 8.0 GA記念
golangでデータベース(RDBMS)を扱う[MySQLの例] - write ahead log
まぁ, ドキュメント読めという話なんですが. 一々例を載せたら長くなってしまいました. とはいえ, 僕の様なコピペプログラマにはこれくらいしておいた方が... 準備 まずは有難くパッケージをgo getします. go get github.com/go-sql-driver/mysql 操作方法 では見ていきます. テーブルは以下のようにしましょう. DEPT(部署) キー 列名 意味 型 主キー DNO 部署コード 文字列(2ケタ) DNAME 部署名 文字列(20ケタ) BUDGET 予算 数値(10ケタ, 内小数2ケタ) LAST_UPDATE 最終更新日時 日付 EMP(従業員) キー 列名 意味 型 主キー ENO 従業員コード 文字列(2ケタ) ENAME 従業員名 文字列(20ケタ) 外部キー DNO 部署コード 文字列(2ケタ) SALARY 給与 数値(10ケタ, 内小数
![golangでデータベース(RDBMS)を扱う[MySQLの例] - write ahead log](https://cdn-ak-scissors.b.st-hatena.com/image/square/71cfc21447a90cfcc5c07fc56fc7f99896248379/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F6653586347147235474%2F10328749687232682671%2F1558687280)
タグ機能を実現するための便利なデータベース設計を３つ紹介 | colori
AND検索 「CSS+HTML+JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" AND tags LIKE "%HTML%" AND tags LIKE "%JavaScript%" OR検索 「CSS|HTML|JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" OR tags LIKE "%HTML%" OR tags LIKE "%JavaScript%" 引き算検索 「CSS+HTML-JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" AND tags LI
Go の Prepared Statement は Connection を気にせず使える - Qiita
コネクションプールと prepared statement database/sql は、トランザクションを除いて基本的にコネクションをユーザーに見せず、全ての操作をコネクションプール sql.DB を通して行う設計になっています。 コネクションプールと言えば、 prepared statement の実装が気になります。 prepared statement は基本的にコネクションに紐付いていて、 プレースホルダ付きのクエリを投げてコネクションローカルの「ハンドル」を貰う 「ハンドル」にパラメータを送ってクエリを実行する 「ハンドル」を閉じる（あるいはコネクション自体を閉じる） という流れになるので、コネクションプールと組み合わせて使う場合には、 毎回ハンドルを取得＆開放する (１クエリに３回通信が発生) ハンドルを開放しない (DBサーバー側のリソースを食いつぶす) コネクションごとに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go database/sql チュートリアル 06 - プリペアドステートメントの使用 · golang.shop