なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
WEB+DB PRESS Vol.93 SQL 高速化ガイド - rochefort's blog
WEB+DB PRESS Vol.93 作者: 原田騎郎,吉羽龍太郎,松浦隼人,須藤涼介,生沼一公,森下雅章,前島真一,鍛治匠一,伊藤直也,のざきひろふみ,うらがみ,高山温,佐々木健一,わかめまさひろ,ひげぽん,遠藤雅伸,海野弘成,はまちや2,竹原,藤田正訓,WEB+DB PRESS編集部出版社/メーカー: 技術評論社発売日: 2016/06/24メディア: 大型本この商品を含むブログを見る MySQLを主とした話でした。 スロークエリ、EXPLAINの説明、よくある問題などの説明がされており、とても良い内容でした。 （pt-query-digest は知らなかった） 以下は個人的に気になったとこ。 mysqldumpslow mysqldumpslow -s t mysql-slow.log ソートオプション 項目 説明 t/at 実行時／平均実行時間 l/al ロック時間／平均ロック時
MySQLのタイムゾーン - tmtms のメモ
YAPC::Asia 2015 のセッションで、MySQL のタイムゾーンの話が出ていましたが、以前タイムゾーン周りで少しはまったことがあったのを思い出したので書いてみます。 MySQLのデフォルトのタイムゾーンは mysqld 起動時のシステム設定です。TZ 環境変数の値か、変数が設定されていなければ /etc/localtime(Ubuntu の場合) です。 # TZ=Japan /usr/sbin/mysqld mysql> SHOW VARIABLES LIKE '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | JST | | time_zone | SYSTEM | +---------
Doma へようこそ — Doma ドキュメント
Doma へようこそ DomaはJavaのデータベースアクセスフレームワークです。Domaには様々な強みがあります。 コンパイル時にアノテーションプロセッサーを使用して、ソースコードを検証および生成します。 型安全なCriteria APIを提供します。 Kotlinをサポートします "two-way SQL"と呼ばれるSQLテンプレートをサポートします。 他のライブラリに依存しません。 このドキュメントは、以下のセクションで構成されています。 ユーザー向けドキュメンテーション Domaについて リンク集 私たちのドキュメントの改善とローカライズをお手伝いください。 ドキュメントに関する英語版および一般的な問題については、 GitHub リポジトリ に issue や pull request を追加してください。 日本語にローカライズするには、Crowdin プロジェクト を介して翻訳
初心者のためのSQLガイド???? : SQLを直感的に理解しよう | POSTD
SELECT * WHERE a=b FROM c ？ それとも SELECT WHERE a=b FROM c ON * ？ もしあなたが私のようなプログラマだったら、SQLは、初めは優しく見える言語の1 つかもしれません（ただ単に普通の英語通り読めばいいですから）。ですが、何かしらの理由で、なんてことのないクエリにもいちいち正しいシンタックスをググらなければいけないでしょう。 いずれJOINにAGGREGTATION、サブクエリにたどり着くでしょうが、読んだとしてもさっぱりでしょう。例えば次のような感じです。 SELECT members.firstname || ' ' || members.lastname AS "Full Name" FROM borrowings JOIN members ON members.memberid=borrowings.memberid JOIN
Sql基礎の基礎
4. SQL？ SQL : Structured Query Language（構造化問合せ言語） リレーショナルデータベース: RDBとデータをやりとりする ための言語 5. RDB？ RDB: Relational Data Base（リレーショナルデータベース） 行と列の表形式でデータを保存 RDBMS: Relational Data Base Management System （リレーショナルデータベースマネージメントシステム） 例）SQLite3, MySQL, PostgreSQL, MongoDB ... SQL ？ クライアント (Rails,ターミ RDBMS RDB ナルetc.) データ データ 6. データの型 SMALLINT, INT, FLOAT, REAL, DEC, NUMERIC ...数値 CHAR, NATIONAL CHAR, VARCHAR
ORDER BYで、単純な昇順降順「以外」で並べる！ - なからなLife
いやー、知らないって怖いね。 なんだこのキモいSQLは、って思ってしまったけど、調べているウチに、これちゃんとSQL構文に則ってる！こちらが間違ってた！って事がわかっていきました。 あえて、知らなかった所から勢いで書いていたのを、そのままにしてみました。 キモいSQLコードを偶然見つけた SQLにおけるORDER BYって、その後にカラム（およびそのエイリアス）を並べてソート順として使用するわけですが、MySQL案件のお仕事の中で偶然こんなものを見つけて、絵に描いたような二度見リアクションしました。 SELECT * FROM tbl ORDER BY id = 23; -- (1) SELECT * FROM tbl ORDER BY FIELD( id, 23, 234, 543, 23 ); -- (2)こうした、「ORDER BYに、あたかもWHERE句で絞り込む条件指定のような使
ディレクターがSQLを使えてよかった話 - クックパッド開発者ブログ
こんにちは。ディレクターの川原田です。 クックパッドでお気に入りレシピを保存する「MYフォルダ」のサービス開発や、保存・記録に関する新規サービスの検討・開発を担当しています。 ディレクターの仕事は様々ありますが、今回は私が身につけたことで仕事領域が広がった！と感じているSQLについてお話ししたいと思います。 いきなりですが、SQLが使えてよかった点をまとめると以下です。 よかったこと 数値抽出から分析まで自己完結 エンジニアとのコミュニケーションがスムーズに 仕事が増えていそうで実は効率アップ 周囲の知的好奇心を刺激 それぞれ具体例を交えてお話します。 数値抽出から分析まで自己完結 事例１：ログ構造を理解でき後の仕事がスムーズに 昨年、アプリのサービス開発を担当した際、エンジニアの設定したログが、実際に送信されるかどうかを事前チェックをしました*1。 アプリのリリースはタイミングが決められ
とあるイルカの近況報告
2016/07/02 YAP(achimon)C::Asia Hachioji 2016 mid in ShinagawaRead less
Oracle文化が根強いSIerと一緒にMySQL案件に関わると質問される5つのこと - なからなLife
タイトル通りですが、とりあえず列挙 STATSPACK的なもの、ないの？ ありません。 価格差考えてください。 TuningPack的なもの、ないの？ （ｒｙ 過去に実行したSQL、誰がいつ実行したか追えないの？ いわゆる監査ログってやつ。 無料でやりたいなら、generarl_logで全SQL吐いてください。 あとは有償/無償でプラグイン追加すればできるようになりますよ。 I/Oなり、なんらかのリソースを食うけどね。 監査やらない前提で必要スペック見積もっておいて、事故ってから騒ぐのやめてください。 クエリ遅いんだけど！ Oracleと同じ感覚で一文でバッチリ取ってくる数百行のクエリ書いて悦に入ってないで、実行計画まず見てくれ。 MySQLで相関サブクエリが死ぬほど遅いってことは、一度でも自分で調べる意思があってググッていれば、嫌でも目に入るだろ。 まさにggrks（死語？ この相談を受
ORDER BY RAND()はしたくないけどそれなりにランダムな結果セットを返すいくつかの方法を考える
ORDER BY RAND()といえば、「結果セットをランダムにソートし、LIMITと組み合わせることでランダムに指定件数をピックアップしたかのように見える」黒魔術。 ( ´-｀).oO(そういえばこれも ORDER BY FIELD と一緒で構文だと思っていた人がいたな。。 これもまあRAND()関数を使ってるだけなので、select_listに放り込めば何やってるかわかりやすい。 mysql56> SELECT num, val, RAND() AS rand_val FROM t1 ORDER BY rand_val LIMIT 3; +-------+----------------------------------+-------------------------+ | num | val | rand_val | +-------+---------------------
MySQLでランダムにレコードを取得する場合の手法 - Qiita
概要 レコード数が少ない間はそれほど問題になりませんが、 レコード数が多いテーブルからランダムで取得する際、処理速度が遅くなる場合があります。 いくつか手法に関して調べてみました（ほぼSQLアンチパターンの受け売りですが…）。 準備 テーブル作成 ローカル環境で以下のようなテーブルを作り、複数の手法を試します。 CREATE TABLE `sandbox` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `param` INT NOT NULL, `content` VARCHAR(255) NOT NULL, `created_at` DATETIME NOT NULL, PRIMARY KEY (`id`) );
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
SQLスタイルガイド - Qiita
はじめに 本文書はSQLのスタイルガイドです。 PythonやRubyのようなプログラミング言語には有名なスタイルガイドがあり、共通のレイアウトルールに沿ったインデントや命名規則に則ったコードが生み出されています。 一方、SQLには知名度のある統一されたスタイルガイドがありません。 そのため、思いのままに書かれたSQLが散見されます。 もちろん、SQLを使ってアドホックな分析を行う場合は、必ずしもルールに沿う必要はなく、効率よく書いても良いと思います。 しかし、Webサービスやバッチの中に組み込むようなもの、つまり自分以外の誰かに読まれるSQLは、多くのプログラミング言語同様に何らかのスタイルガイドに沿うことで多くのメリットを享受できると思います。 クエリが構造化され、可読性が高まる バグの発見や修正が容易になる 改行位置やインデントなどのフォーマットの悩みが解消される スタイルガイドを共
なぜ、いま リレーショナルモデルなのか（理論から学ぶデータベース実践入門読書会スペシャル）
1. なぜ、いまなぜ、いま リレーショナルモデルリレーショナルモデル なのかなのか 奥野 幹也 Twitter: @nippondanji mikiya (dot) okuno (at) gmail (dot) com @ 「理論から学ぶデータベース実践入門」読書会スペシャル 3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● トラブルシューティング全般 ● Q&A 回答 ● パフォーマンスチューニング など ● ライフワーク – 自由なソフトウェアの普及 ● オープンソースではない ● GPL 万歳！！ – 最近はまってる趣味はリカンベントに乗ること ● ブログ – 漢のコンピュータ道 – http://nippondanji.blogspot.com/
なにこれ楽しい！SQLをブラウザ上で学習できるSQLZOO！ - 嗚呼、学習の日々
みなさまごきげんよう！ 嗚呼蛙でございます！ 一昨日amazonアソシエイトの審査を無事通過したことを祝って、露骨なアフィ目的記事を書いてみました。 今日はデータベースの操作を行う言語『SQL』を実践的に学習できるサイトを発見したので、それについて書いていこうと思います。 SQLってなに？ ブラウザ上でSQLの学習ができるサイト 日本語でのSQL学習 SQLってなに？ SQLを知らない方のためにSQLについて簡単に説明しておくと、例えばネットショップで買い物をする時にこんな感じで「会員情報」「送付先」」「購入品」を登録しますよね。 【会員情報】 【送付先】 【購入品】 すると、ブラウザから入力された情報は、SQLを使ってこんな感じでデータベースに書き込まれます。 【会員テーブル】 【送付先テーブ】 【売上テーブル】 こんな風にブラウザから送られた情報をデータベースに書き込んだり、蓄積された
PostgreSQLアンチパターン
37. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 38. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 ユーザの削除フラグを見る 39. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users
LIKE句のSQLインジェクション | Yakst
GitHubのエンジニアがデータベースのスローログから見つけた、LIKE句を使ったクエリーのパフォーマンス問題につながる可能性のある文字列。問題の仕組みと、それを回避するためのスニペット。 先日、例外情報のトラッカーを見回していたら、目を引くスロークエリーログを発見しました。SELECT ... WHERE ... LIKEといったクエリーのLIKE句にたくさんのパーセントが付いているのです。この部分はユーザが入力した部分なのは明らかで、最初私はSQLインジェクションを疑いました。 [3.92 sec] SELECT ... WHERE (profiles.email LIKE '%64%68%6f%6d%65%73@%67%6d%61%69%6c.%63%6f%6d%') LIMIT 10 コードを見てみると、ここで解釈されるメタ文字(%や_や\)のチェックをまったくせずにユーザが指定し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
やっぱり SQL を書きたい派に送る jOOQ
SQL 脳から見た Ruby
