SQLを速くするぞ―お手軽パフォーマンス・チューニング
このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL 第2版』の受け売りがほとんどなので、この本を読んでいただければ、本稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック（一番遅いところ）を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基本を承知していただいた
業務でどれだけSQL力がつくのか ~SQLアンチパターンを用いて確認~ 前編
はじめに こんにちは。 GMOアドマーケティングのKONCEです。 新卒で入社し、数年経ちました。日々の業務で学ぶことは多いですが、今年度は技術の深堀りをテーマにやっていきたいと思っています。 今回は入社してDBやSQLに関しては業務内で学ぶことが多く、特別訓練をしていたわけではなかったのですが、「SQLアンチパターン」を用いて学びながら、改めて自分の現状を見つめ直していけたらと思います。 今回は学習を行う側面と自分自身のレベルについて見直していきたいので 知っていた → ○ 部分的に知っていた → △ 知らなかった → × を付けてみようと思います。 目次 SQLアンチパターンについて Ⅰ部 データベース論理設計のアンチパターン 2-1. [○]1章 ジェイウォーク（信号無視） 2-2. [×]2章 ナイーブツリー（素朴な木） 2-3. [○]3章 IDリクワイアド（とりあえずID） 2
SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
websec-room.com - websec room リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
SELECT文の評価順序の話 - Qiita
はじめに この投稿はアイスタイル Advent Calendar 2015の25日目の記事です。 最終日の記事になりますが、今回もDBAの@toshifusaが、RDBMS関連の話題を、地味に淡々と書かせていただきます。 SELECT文とは SQLの構文のうち、データを取得する文がSELECT文になります。 最近はORMがSQLを生成してくれるため、素でSQLを書く機会が減ってきているかと思いますが、ORMのSQL生成は完璧ではありません。 必ずしも効率の良いSQLを生成する訳でも、自動的に必要なインデックスを作成してくれる訳でもありません。 RDBMSをブラックボックスにせず、何をやっているのかを理解して、ORMと付き合っていくのが正しい態度ではないかと思います。 こんな疑問がわいた経験ないですか？ LIMITで出力件数を数件に制限しているのに、なんでこのクエリは遅いんだろう ASで別名
分析SQLのコーディングスタイル - クックパッド開発者ブログ
SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析
OTN Japan マニュアル
お探しのものを見つけるために、以下の項目を試してみてください。 キーワード検索のスペルを確認してください。 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。 新しい検索を開始してください。
図でイメージするOracle DatabaseのSQL全集 第7回 再帰with句 | Oracle 日本
木構造なデータの探索 親子条件を満たす行を再帰的に出力 再帰with句で木構造なデータの探索を行うことができます。 create table TreeData(ID primary key,OyaID) as select 1,null from dual union all select 2, 1 from dual union all select 3, 1 from dual union all select 4, 2 from dual union all select 5, 3 from dual union all select 10,null from dual union all select 11, 10 from dual union all select 12, 10 from dual;
SQLアンチパターン「IDリクワイアド」の再検討 - 極北データモデリング
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る話題のSQLアンチパターンの目次に「アンチパターン：すべてのテーブルにID列を用いる」とあるのを見て、大胆にもサロゲートキーを否定しているのかと思って読んでみたが、どうも主張がはっきりしない。論点が尽くされていないような... 「SQLアンチパターン」の主張 第3章には以下のようなことが書いてある。 「IDリクワイアド」アンチパターン IDリクワイアドは「すべてのテーブルに"id"という列名の無意味な連番の列を追加し、PRIMARY KEY制約を付与する」というパターンのこと。 何がいけないのか 自然キーにUNIQUE制約を付けないなら、自然キーの重複を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Oracleの階層問い合わせ一覧
OTN Japan マニュアル
OTN Japan マニュアル
OTN Japan マニュアル
オラクルから最新の製品技術情報を入手できます
OTN Japan マニュアル
https://blogs.oracle.com/otnjp/post/oracle-sql-image-001