開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
Where狙いのキー、order by狙いのキー
2015/10/03 phpcon 2015 updated at 2016/01/13 about default_password_lifetime's default will be 0
ストアドプロシージャの作成
今回から数回にわたり、ストアドプロシージャの作成に挑戦します。ストアドプロシージャの利用については、前回の「システム・ストアドプロシージャを用いたロールの詳細設定」の中で取り上げました。今度は、Transact-SQLを使用して、ユーザー定義のストアドプロシージャを作成します。 では早速、例題を実行しながら、SQLの確認をしていきましょう。 SELECTを実行するストアドプロシージャ 最初に、非常に簡単なストアドプロシージャを作成してみましょう。作成するのは、Customerテーブルから「顧客ID（CustomerID）」「会社名（CompanyName）」「担当者名（ContactName）」「電話番号（Phone）」を抽出するストアドプロシージャです。クエリアナライザから下記のSQLを実行してみましょう。
SQL講座
データベースの種類と概要 リレーショナル型・データベースをはじめデータベースの種類とその概要の解説 SQLの概要 SQLの構成などSQLの概要 リレーショナル・データベースの関係演算 リレーショナル型・データベースの関係演算である選択、射影と結合の解説 「データベース/スグ解る！最新「データベース」機能」 キーマンズネットのデータベースの基礎の解説 Accessで試してみよう C言語やVisual Basicなどのプログラム言語の習得と同じで、SQLも実際にSQL文を入力して実行することでより早く、確実にマスターすることができる。ここではAccessでSQLを実行する方法を解説している。 MySQLで試してみよう 無料で使えるMySQLでデータベースとSQLを操作する方法を解説 MySQLのダウンロード MySQLのダウンロード方法 MySQLのインストール MySQLのインストール方法の
CakePHP2でどんなSQLが発行されてるのか確認する方法 | kanonjiのブログ
ちょっと説明用も兼ねて、基本的なsql_dumpエレメントからDebugKit, DataSourceのgetLog()を使った方法まで、まとめました。 sql_dumpエレメントで確認する <?php echo $this->element('sql_dump'); ?> https://github.com/cakephp/cakephp/blob/2.3.6/app/View/Layouts/default.ctp#L60 CakePHPデフォルトのレイアウトであるdefault.ctpからは、この様にSQLダンプ用のエレメントが読み込まれてます。 既に開発が進んでるプロジェクトだったり、配布されてるレイアウトをベースにしていたりすると、sql_dumpエレメントの読み込みが削除されてるかもしれないけど、普通は一番簡単にSQLを確認出来るところです。 if (!class_exis
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編） こんにちは nob です。 前編 これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） の記事から１年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を（システム編）としてお届けいたします！ 今回の（システム編）で紹介するツボは 4 つです。（クエリ編）のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 （ツボ１）Load Average < (1 + (cpu数-1)/3) （ツボ２）Checkpoint Age が水平線になったら要注意 （ツボ３）MyISAM は無いよね監視 （ツボ４）万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL
MySQLで複数行を一括でUPDATEする - Qiita
FrogApps 技術ブログ始めました！ RailsやiOS、HTML5の情報を発信中!! → http://qiita.com/teams/frogapps データベースを運用していると、一気にデータを投入したり、更新する必要が出てきます。 MySQLではINSERT文では複数行同時に更新できますが、UPDATEでは用意されていません。 そこで、UPDATEとJOINを組み合わせて、既存のテーブルを一気に更新してみます。 例) original_dataテーブルのbodyの値を複数行一気に更新する まずは元データを作ります。 CREATE TABLE tbl1(id INTEGER PRIMARY KEY, body VARCHAR(255)); INSERT INTO tbl1(id, body) VALUES(1, '001'); INSERT INTO tbl1(id, body)
SQLアンチパターン - ジェイウォーク
社内勉強会資料 追記: 2013-10-31 ついったで指摘( https://twitter.com/akuraru/status/395822183777202176 )を受けたので入れ子集合のノード追加の説明の所を修正しました。
O/Rマッパー当たり前な時代だからこそSQLテクニックを磨こう·SQL Fiddle MOONGIFT
SQL FiddleはColdFusion製のソフトウェア（ソースコードは公開されていますがライセンスは明記されていません）です。 開発環境をセットアップするというのは意外に面倒で、せっかく学習しようと思ってもその時点で頓挫してしまいます。もしあなたがSQLを学んでみたいと思うならばSQL Fiddleを使ってみましょう。 こちらがメイン画面です。左に構造、右に実行するSQLを書きます。 実行例。結果はテーブルで下に表示されます。 SQLを変えれば実際に結果も変わります。 対応するデータベースは多様です。 SQL FiddleはJSFiddleに代表されるWebプレイグラウンドサービスで、SQLをWebブラウザ上で実行、確認ができます。最初のテーブルのCreate文からはじまり、任意のSQLを実行してその結果をテーブル表示で確認できます。MySQL/PostgreSQL/MS SQL Se
SQLアンチパターン - ナイーブツリー
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
初級〜中級者のためのSQL特訓 - 忘れないようにメモっとく
SQLで木と階層構造のデータを扱う――入れ子集合モデル