履歴テーブルから最新の1件を取ってくる方法 - そーだいなるらくがき帳
例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
Where狙いのキー、order by狙いのキー
データモデリングの方法論について解説資料を作りました。ご意見がありましたら、お願いいたします。Twitter: https://twitter.com/hidekatsu_izuno 以下に移行します。今後はこちらがメインとなります。 https://speakerdeck.com/hidekatsu_izuno/detamoderingutekunituku
津島博士のパフォーマンス講座 第11回 良いSQLについて（2） | oracletech.jp
皆さんこんにちは、だいぶ寒くなってきましたが体調はいかがでしょうか。私は多少寒気がするのですが、どうにか頑張っております。 今回は、以前に説明して好評だったので「パフォーマンスの良いSQL文ついて」の続きを説明しようと思いますので、参考にして下さい。 ■1．SQL文について まずは、続きで良いSQL文についてですが、以前にも言いましたが無駄なリソースをできるだけ使用しないことです。無駄なリソースを使用しないとは、同じ処理や不必要な処理をできるだけ実行しないことです。そのため、以下のような無駄な処理を行わないや視認性の良いSQL文を記述するのが良いと思います。視認性が良いことでミスを防げたり無駄な処理を見つけることができたりします。 今回はこのような作成する上での役に立つポイントをまとめてみました。 無駄なソート処理をしない ファンクションを使用する 繰り返し使用する副問合せはWIT
津島博士のパフォーマンス講座 第9回 良いSQLついて | oracletech.jp
皆さんこんにちは、まだまだ暑いですが体調はいかがでしょうか。私はどうにか頑張っております。 今回は、詳しく聞きたいというご要望のありました「パフォーマンスの良いSQL文ついて」まとめて説明しようと思います。すべてのパターンについて解説はできませんが、第4回で少し説明した実行計画を使用して説明しますので、実行計画などを見るときの参考にもして下さい。 ■1．良いSQL文とは まずは、良いSQL文とはどのようなものなのかを説明します。簡単に言うとリソースをできるだけ使用しないようにすることですが、なかなか難しいと思いますので参考になるポイントをまとめてみました。 高速にアクセスするには、索引を使用してアクセスするのが一般的ですから、索引が使用されないSQL文を記述しないことです。そのため、どのようなときに索引が使用されないかを知っておくことも大事になります。それから、テーブルの結合やソー
INDEX FULL SCANを狙う - MySQL Casual Advent Calendar 2011 - SH2の日記
2011年8月のkazeburoさんのエントリに対する解説記事です。結論から言うとkazeburoさんの案に賛成なのですが、本日はどうしてそうなったのかというところを確認していきたいと思います。本記事はMySQL Casual Advent Calendar 2011の17日目のエントリです。16日目はakira1908jpさんでした。 当時の内容を覚えていない方は、先にkazeburoさんのエントリをご一読ください。また、テストケースがGitHubに公開されていますのでカジュアルに再現試験をすることも可能です。 Covering Index と self-join と MySQL - blog.nomadscafe.jp kazeburo's gist: 1150842 - Gist 問題のSQLをチューニングするには、MySQLがインデックスに対してどのようにアクセスするかという点につ
指定した範囲の行を取得するクエリ - HHeLiBeXの日記 正道編
DB2 Express-C v9.7.2のWindows版で使えていたLIMIT/OFFSETが同Linux版で使えなくて、プラットフォームによって違うのかと思ってしまい、同等のことができる構文をいろいろと調べた挙句、インストール直後の設定が違っていただけという。 で、せっかくなので、調べたいろいろをまとめてみようということで。 ただDBごとに並べても面白くないので(謎)、構文ごとにまとめてみるというアプローチで(更謎)。 前提として、次のようなテーブルを作っておく。 CREATE TABLE hoge(str VARCHAR(8)) INSERT INTO hoge(str) VALUES('bbb') INSERT INTO hoge(str) VALUES('ddd') INSERT INTO hoge(str) VALUES('fff') INSERT INTO hoge(str)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日付FROM-TOのデータを穴埋めする - Qiita
DataGrip: The Cross-Platform IDE for Databases & SQL by JetBrains