SQLチューニングとは宣言型言語でリファクタリングをするということ
これはなに ども、レバテック開発部のもりたです。 タイトルの通りなんですが、SQLチューニングってつまり宣言型言語でリファクタリングするってことだよね、というのを書きます。なお具体的なリファクタの方法とか実行計画の読み方とかはスコープ外です（別で書く予定）。 SQLチューニングはリファクタリング まずSQLチューニングというと、パフォーマンス改善みたいな意味合いが強いと思います。ただ、SQLチューニングは本質的にはリファクタリング的な行為であるはずです。リファクタリングの定義を確認すると、 リファクタリングとは、ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業を指します。 引用元: 『リファクタリング 既存のコードを安全に改善する 第2版』 雑にいえば、結果を変えないでコードを改善することです。ここでいう改善とは内部品質を向上させることで、例えば保守容易性であったり
スロークエリを改善したらECSの負荷が爆下がりした話(TypeORM)
TL;DR TypeORMで発生していたスロークエリを改善 スロークエリを改善したらECSの負荷も減少 はじめに スロークエリを改善したら、ECSコンテナ側の負荷も下がってなんでだろ？と思ったので記事にしようと思います。 環境 TypeORM v0.3.20 Node.js v18.x バックエンドインフラ ECS on Fargate => Amazon Aurora MySQL 負荷改善の前と後 まずはどのくらい改善したのかを示します。 この時ECSコンテナ8台動いてました。(4vCPU 8GBMem) 改善前 改善後 改善前と改善後は一日前の同じ時間帯のものです。 ちゃんと動いてるのか不安になるくらい下がってました笑 どのような対応をしたのか スロークエリの出ていたクエリでMySQLの実行計画を確認しました。 TypeALL,index, Using Filesort等はなかったので
GitHub - nulltea/zk-SQL: ZK-based engine for self-sovereign SQL queries
This project provides basic tools and infrastructure for proving the correctness of the SQL queries performed against the database hosted in an untrusted environment. As a demo, this project implements a platform that connects "data miners" running SQL-prover nodes and users that wish to outsource their data and are willing to pay for such service. Other use cases of the zk-SQL include running it
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
第37回 文字符号化方式にまつわるジレンマ Page 1
前回は「C XML and SGML (Non-Normative)」と「D Expansion of Entity and Character References (Non-Normative)」を読んだ。JIS X 4159では「附属書C（参考）XMLおよびSGML」と「附属書D（参考）実体参照および文字参照の展開」である。前者は、XMLとSGMLの関係について記述されている。どちらかといえば好奇心から見るべき文書であり、歴史の一端を垣間見るのに有用だろう。逆に後者は、生々しい現在進行形のXMLのディープな領域を正しく理解するのに有益だろう。もちろん、ここまでDTDやパラメタ実体を含む参照を活用する利用者は多くないかもしれない。しかし、ある種のXMLの応用は、間違いなくこれらのディープな参照の挙動を活用して行われている。もちろん、ここに書かれているのは、規定ではなく、分かりやすくする
[SQL] Where句とHaving句の違い | DevelopersIO
はじめに PostgreSQL始めました。 SQLを学ぶ過程でWhere句とHaving句の違いがわからずに悩んだ時期があったので、その時感じたことを書いておきます。 環境 MacOS 10.10.5 PostgreSQL 9.4.5 Where句でもHaving句でも同じ結果が出るけど何が違うんだろう？ 結論から言うと Where句はselect句の結果からwhere句で指定した抽出条件を実行する Having句はGroupBy句でグルーピングした結果からHaving句で指定した抽出条件を実行する という違いがあります。 同じ結果が出ることを確認 PostgreSQLのチュートリアルにあるデータベースを使います。手を動かして確認したい方はこちらを見てデータベースを用意していただければと思います。 今回使用するカスタマーテーブルは以下のようになっています。 select * from cu
![[SQL] Where句とHaving句の違い | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/d9d7a9e19a3c5979fc0b83efa7beeec666f705bb/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F07%2Fsql.png)
第18回 MySQL5.7のデフォルトのSQLモードを確認してみる | gihyo.jp
長い間MySQLを使ってアプリケーションやサービスを提供していると、セキュリティの都合や機能の高性能化によってアップグレードが求められることがあります。アップグレードを行った際にアプリケーションがそのまま動いてくれる場合もあるのですが、SQLモードの設定によって動かなくなってしまうこともあります。 アプリケーションが動かなくなってしまい、仕方がないのでよくわからないけどSQLモードの設定を空にする、なんて事はありませんか？ 今回はそんなSQLモードの確認方法や、デフォルトの設定がどのような意味を持っているのかを紹介していきたいと思います。 デモンストレーション環境 この原稿を書いている時点で最新版である5.7.12を第5回 Dockerで複数バージョンのMySQLを開発環境に用意するで作成した環境で実行して確認していきます。 また、今回使用するデータは第2回 MySQLにはじめてのデータを
MySQLでSQLの結果を変数に格納する - Qiita
やりたかったこと 開発用のローカルDBを作るのに本番DBからのダンプデータを使いたい。 ただし全件ではデータが膨大でマスク処理やリストアに時間が掛かるので、直近登録の1000件のユーザを除いて古いユーザデータを削除したい。 どうやったか 直近1000件のユーザIDを取得して関連データを削除する。 set構文 最初はset構文を使い手動でid降順で1000件目のidを変数へ代入していました。 > select MIN(id) from (select id from users order by id desc limit 1000) hoge; +---------+ | MIN(id) | +---------+ | 4001 | +---------+ > SET @min_user_id = 4001; > SELECT @min_user_id := `id` FROM users
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
サブクエリとSQLインジェクション
はじめに SQLインジェクションという攻撃手法(脆弱性)は10年以上前から基本的な原理は変わっていません。しかし攻撃される対象であるデータベースそのものは少しずつ進化し、新たな機能や文法、関数をサポートしていきます。そのため、SQLインジェクションの脆弱性が存在する場合に、そこから「どのように攻撃して、その結果何ができるか？」という点については、データベースの進化に合わせた変化があります。 WAFは防御対象となるウェブアプリケーションに脆弱性がある前提でSQLインジェクション攻撃を見つけるものであるため、データベースの比較的新しい機能や文法を使われたとしても、きちんと見つけることができるようになっていることが理想的です。 Scutumにおいてもデータベースが比較的最近サポートするようになった文法等に合わせて防御を強化しています。今回はサブクエリを使ったSQLインジェクションを例として紹介し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://developer.hatenastaff.com/entry/2019/01/15/120431
高橋光 | データコンサル on Twitter: "『SQLを教えるときは、社内にある実データを使って実際の課題解決にとり組むのが一番早い』 これはまさにその通りだと思っていて、自分の組織でSQL勉強会を実施したときも意識した事の1つ。 実際のデータで実際にSQLを触る環境を用… https://t.co/gU0wShxMV8"
逆引きSQL構文集
SQL実践講座
HAVING句の力
SQLアンチパターン メンター用資料
Andy on Twitter: "発行するSQLに応じて動的に型が得られるDEMOも撮った。 ほんとこれ革命的じゃない？ Node.jsのORM論争とか全てがどうでもよくなる気がしてる。 Query validatorの実装にも力を入れていきたいのでコントリビ… https://t.co/p4kpuqtlGx"