なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
表の確認／作成／変更／削除 － ＠IT
CREATE [GLOBAL TEMPORARY] TABLE [schema.]table (column datatype [SORT] [DEFAULT expr] [inline_constraint [inline_constraint …]] [, column datatype [SORT] [DEFAULT expr] [inline_constraint [inline_constraint …]] … ] ) [out_of_line_constraint [out_of_line_constraint …]] [ON COMMIT {DELETE | PRESERVE} ROWS] [PCTFREE integer] [PCTUSED integer] [INITRANS integer] [STORAGE (storage [storage …])] [TABLES
日付データ演算の達人技を伝授する 【第2話】
本連載はSQLの応用力を身に付けたいエンジニア向けに、さまざまなテクニックを紹介する。SQLの基本構文は平易なものだが、実務で活用するには教科書的な記述を理解するだけでは不十分だ。本連載は、著名なメールマガジン「おら！オラ！ Oracle - どっぷり検証生活」を発行するインサイトテクノロジーのコンサルタントを執筆陣に迎え、SQLのセンス向上に役立つ大技小技を紹介していく。（編集局） 花粉の攻撃をくぐり抜け、箱根へのツーリングも快適な今日このごろです。前回に引き続き今回も日付データについてのお話です。今回は特にデータ型を掘り下げていきましょう。 DATE型とTIMESTAMP型 日付を格納するデータ型としては、従来のDATE型に加えて、Oracle9iからTIMESTAMP型が使用できるようになりました。TIMESTAMP型とDATE型の大きな違いは、その精度です。 DATE型
＠IT：Oracle管理者のためのSQLリファレンス
Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか （2017/7/26） データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します ドメイン参加後、SQL Serverが起動しなくなった （2017/7/24） 本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します さらに高度なSQL実行計画の取得」のために理解しておくべきこと （2017/7/21） 日本オラクルのデータベーススペシャリストが「DBAがすぐ
3-6 Oracleのオプティマイザ
8 April, 1998 Updated PCDN OracleWG S.Yamazaki 普段、SQL文を書いているときは、期待した結果が得られた文が最適であると思いがちです。しかし、果たしてそれが最適かどうかは疑問が残ります。最適なSQL文を書くことはプログラマの責任であり、アプリケーションの応答時間の短縮や、利用する資源の競合の減少を図る上では避けて通れない問題です。 ここで説明することが、SQL文のチューニングの最終到達点である「最適なアクセスパス」を選択できるように少しでもお役に立てれば幸いです。 最適なSQL文とは 最適なSQL文とは何をもって「最適」とするのでしょう。オペレーターが期待するデータ集合をDBから抽出するとき、さまざまなSQLの書き方を想定すると思います。その時、オペレーターはある程度の応答時間を想定してSQLを書くと思います。では、試行錯
.xyz Domain Names | Join Generation XYZ
Latest news from .xyz 08/09/2024 – XYZ Registry: Continuing our commitment to combating online abuse08/19/2024 – Web3 platform Datalayer.xyz aims to revolutionize blockchain and AI with user-owned innovations Follow us on Twitter @xyz 04/12/2024 – 5 tips for building community through your online presence08/15/2024 – Data availability network Dill.xyz aims to revolutionize blockchain performance08
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「MySQL でクエリを分割せずに Error 1093 を回避するには?」（1） Database Expert － ＠IT
リレーショナル・データベースの世界
OracleとSQL Server、チューニングの違いを知る
＠IT：Databaseフォーラム全記事インデックス オラクルパーティショニング
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19207-01/stats.html