ぐるぐるSQLは止めてくださいという話 - Qiita
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
カーディナリティについてまとめてみた - Qiita
カーディナリティとは テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティという。 具体例 カーディナリティが低い場合 例えば性別なら、男と女の二種類である。 カラムのデータの種類が、テーブルのレコード数に比べて二種類と少ない。このことを カーディナリティが低い という。 カーディナリティが高い場合 一方顧客番号ならたくさんの種類(番号)が存在することになる。 カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い という。 カーディナリティを踏まえたインデックスの張り方 基本的に、 カーディナリティの高い列に作成する 必要がある。 はじめに、カーディナリティは カラムの値の種類の絶対値と書いたが、先程の例で言うと性別のカーディナリティは2になる。他にも例えば１年間の日付なら1〜
MySQLのチューニングについて - Qiita
MySQLのSELECT時にORDER BYを使用した時のソートの話 テーブルにINDEXが貼られている事が前提ですが、 例えば３テーブルを結合し、ソートをかける時などに、 全てのテーブルの結合を行った後にマスターとなるテーブルで並び替えると、 Using filesortが発生し、SELECTの実行が遅くなる場合があります。 回避方法として、カラムの表示用のマスターテーブルと、ソート用に使うマスターテーブル(別名付け)を用意し 用途を分けたSELECT文にするなどがあります。 sample.sql SELECT tbl1.col1, tbl2.col2, tbl3.col3 FROM tbl1,tbl2,tbl3 INNER JOIN tbl1 AS tbl4 ON tbl1.col1 = tbl4.col1 WHERE tbl1.col1 = tbl2.col1 AND tbl2.co
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インデックスを使用したルックアップによるアク
Scikit learnより グリッドサーチによるパラメータ最適化
Grid search とは scikit learnにはグリッドサーチなる機能がある。機械学習モデルのハイパーパラメータを自動的に最適化してくれるというありがたい機能。例えば、SVMならCや、kernelやgammaとか。Scikit-learnのユーザーガイドより、今回参考にしたのはこちら。 3.2.Parameter estimation using grid search with cross-validation Example:Parameter estimation using grid search with cross-validation やったこと 手書き数字(0~9)のデータセットdigitsをSVMで分類 GridSearchCVを使って、交差検定でハイパーパラメータを最適化 最適化時のモデルの評価関数にはf1を使用 データの準備 手書き数字のdigitsをインポ
scikit-learnでDBSCAN(クラスタリング) - Qiita
クラスタリングアルゴリズムの一つであるDBSCANの概要や簡単なパラメータチューニングについて， 日本語記事でまとまっているものがないようでしたのでメモしました。 DBSCANの概要は，wikipediaの(雑な)和訳ですのでご容赦ください。 DBSCANとは Density-based spatial clustering of applications with noiseの略 クラスタリングアルゴリズムの一つ アルゴリズムの概要 1.点を３つに分類する Core点 : 半径ε以内に少なくともminPts個の隣接点を持つ点 Reachable点(border点):半径ε以内にminPts個ほどは隣接点がないが，半径ε以内にCore pointsを持つ点 Outlier : 半径ε以内に隣接点がない点 2.Core点の集まりからクラスタを作成し，Reachable点を各クラスタに割り当て
MySQLのスロークエリをslackに通知できるようにする - Qiita
やりたいこと こんな感じで、MySQLでボトルネックになりそうなslowクエリをslackに通知させて、 継続的に、クエリチューニングできるようにしたい。 なので、Mysqlで出力されたスロークエリログをfluentdで取得し、 そのクエリに対して、explainを実行させて、クエリの内容と一緒に、 explainの結果をslackに通知できるようにする。 1. 準備 slackの投稿先webhookURLを用意する IncomingWebHookのキー発行は以下から取得する https://xxx.slack.com/services/new 参考URL: http://qiita.com/vmmhypervisor/items/18c99624a84df8b31008 2. 環境構築 fluentd インストール
MySQLクエリパフォーマンス改善簡易まとめ - Qiita
数年やってないと記憶の彼方に飛んでいきそうだったので、MySQLのクエリ改善方法のテンプレを自分用に明記。 スロークエリを除去する事。 初めはとにかく観察。スロークエリを出力させて、観察する。 indexが効かないクエリを排除する。 indexが予期できない条件分岐によるクエリを廃止する。 場合によってはソートをさせない。コード側でソートさせる。 JOINをわざとさせないのも一つの手。後にDB分離レベルのシャーディング等が発生する可能性のあるようなシステムでは、JOIN禁止にする事は決して間違ってはいない。 indexを必ず効かせる レコード数に応じて、割当たるindexが異なることがあるので、必ず同じデータ数か実際の運用環境で検証すること。 但し、indexを増やし過ぎると、挿入時に更新対象が増えるため、必要最低限にすること。 explain してindexを確認する 特に注目しなければ
MySQL 5.5系で slow queryを見張る設定 - Qiita
私は出力先がTABLEのほうがいろいろツブシがきいて好きなのだが、ファイルにする場合にはパスなどもあわせて設定すること。 long_query_timeを0に指定すると全部slow query扱いになる。0.3という指定もここでは独断と偏見でしているが、プロジェクトの要求仕様に応じても最初から厳しい値にしておいたほうがいい。0.1とか。 見る select * from mysql.slow_log order by start_time desc limit 10 などすれば、どんなクエリが遅かったのかを確認できる。 muninで見張る mysqlのプラグインがあるので見張る。とても便利。サンプルとして2枚ばかり貼る。 前述した見る、だと、どうしても手間がかかるので、本番が近くなってくると、こういうので確認し、つぶしていくとよい。 運用が始まったら始まったで、DBが原因で遅いのか？など確
MySQL InnoDBのIndex - Qiita
mysqlのInnoDBではclustered indexというのを採用していて、indexを貼る際に注意が必要ということでメモ 結論から言うと InnoDBでは... * Primary Key(以下PK)はできるかぎり設定して、できるかぎりauto_incrementの整数型が良い * PKの検索は速いが、secondary indexやcount(*)での検索は若干遅い * PKのupdateは避ける * 無闇やたらとsecondary indexを付けない * covering indexを狙えると速い かんたんに解説 図とか用意したかったけど気力がなかった。 indexの構造 InnoDBのインデックスではB-Treeというデータ構造が使われている。B-Treeの解説はwikipediaに任せる。 ツリー構造の一番下のリーフブロックに目的の行の物理的な位置が記録されている。ルート
クエリチューニング: GROUP BY から LATERAL への書き換え - Qiita
「ユニークキーの GROUP BY」 を 「LATERAL」 に書き換えることで、クエリを性能改善できる可能性があります。 ここでは、非常にシンプルな書き換えの例を示します。 テーブルの準備 まずは、以下のような「部署」、「書籍」、「部署ごとの書籍在庫数」を管理する3つのテーブルを準備します。 なお、「書籍」テーブルは、データベースの状況をイメージしやすいように用意しているだけで、以降のクエリ書き換えでは特に使いません。 -- 部署のIDと名前を管理するテーブル department を作成 CREATE TABLE department (dept_id INTEGER PRIMARY KEY, name TEXT); -- 部署の情報を5件登録 COPY department (dept_id, name) FROM stdin; 1 総務部 2 開発部 3 財務部 4 企画部 5 購
【Rails】レプリケーション対応によりDB負荷を半分に減らした - Qiita
こんちは freee K.K. という会計・給与などの クラウドサービスを提供している会社にて会社員をやっとります @futoase です。 今日は弊社サービスで利用しているDB(RDS)の負荷を半分に減らしてみた、 ということで軽く書いていきたいと思います。お付き合いください。 今期ずっと見続けられてるアニメは、 ゆるゆりとおそ松さんです。 ここで話すRuby/Ruby on Railsの世界とは Ruby 2.1系 Rails 4.2系 以上の世界観となってます。 Ruby 2.1系なのは今月中に2.2にします...(2.3が出てしまう前に...) ベンチマーク方法 について予め言っておきますと、 nginxで収集したaccess.log(staging環境なので開発者がアクセスしたログしかないですよ)を元に 特定のController#Actionへの負荷計測をsiegeに食わしてシ
N+1問題は1+N問題 - Qiita
N+1というからほわっつ？ってなって、1+Nって言われると理解しやすいと思った。 このページ非常にわかりやすい。 http://www.techscore.com/blog/2012/12/25/railsライブラリ紹介-n1問題を検出する「bullet」/ 上のページでいう、PrefectureとShopが一対多の関係になっているときに、Shopの方から、eachの中でshop.prefecture.name みたいにすると、shopの数だけprefecture探すSQL文が発行されることになる。 このページ（参考）では、N+1問題をシンプルに、「全レコードの取得に一つ＋各レコード分だけ SQL を発行してしまう問題」と定義していて、要はただこれだけの問題だと感じた。 例えば100万レコードあったら100万回SQL発行されるのかって考えると、さすがにだれでもやばみ感じると思う。 実際にサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tcpdump と pt-query-digest でクエリ分析 - Qiita