GitHub - kysely-org/kysely: A type-safe typescript SQL query builder
Kysely (pronounce “Key-Seh-Lee”) is a type-safe and autocompletion-friendly TypeScript SQL query builder. Inspired by Knex.js. Mainly developed for Node.js but also runs on all other JavaScript environments like Deno, Bun, Cloudflare Workers and web browsers. Kysely makes sure you only refer to tables and columns that are visible to the part of the query you're writing. The result type only has th
Kysely | Kysely
Type-safe SQL queriesKysely let's you write type-safe SQL queries. This eliminates entire classes of errors and let's you sleep peacefully at night. No magic, just SQLKysely is a light abstraction layer over SQL. This makes it easy to reason about performance, and reduces the amount of concepts you need to learn to be proficient with the library. Great autocompletionBy exposing your database schem
SQLの実行計画の読み方 |
今回は、SQLを書く上で特にパフォーマンスに影響のあるSQLの実行計画の読み方について解説します。実行計画はデータベース製品によってさまざまに差異がありますが、ここでは比較的どのデータベース製品でも共通する内容について解説します。 実行計画とは記述したSQLが実際にデータベースの内部でどのように処理されて結果を返すか、その処理方法を記述した情報です。 A5:SQL Mk-2では、SQLエディタで実行計画を見たい SQL の上にキャレットがある状態でメニューから [SQL(S)] – [SQLの実行計画(J)] または、Ctrl+E で表示できます。 表示の仕方はデータベース製品ごとに異なりますが、多くのデータベース製品ではツリー状の情報として表現されます。（このため A5:SQL Mk-2でもツリービューで実行計画を表示します。） ツリーのリーフ（端）から処理が行われ、ルート（根）に向かっ
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
DBアタマアカデミー 記事一覧 | gihyo.jp
最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す？（3） ミック 2011-04-01
DBのViewを作ったらRailsプログラムが綺麗になった話 | 自転車で通勤しましょ♪ブログ
最近データベースというかSQLについて勉強しているんですが、奥が深いですね。この前の第9回中国地方DB勉強会のときに聞いたrank関数を使って、ランキング機能をリファクタリングしよう！と思って最近頑張ってます。というのも、複雑なクエリ（遅い）を業種数分（10回くらい）呼んでいたため、Herokuだと結構ギリギリの速度になることもあったので、なんとかしなければ！と思っていたのです。 とりあえず、私の開発環境を載せておきます。 Mac Yosemite Ruby 2.2 Rails 4.2.1 PostgreSQL 9.3.4 ひとまずrank関数を使うところまで まず、NewRelicを使ってActiveRecordが出力しているSQLを取得し、それを0xDBEのコンソールに貼り付けて、rank関数を使って業種でパーティションしてランキングを出すところまでしてみました。rank関数は、関数名
実行計画が解れば怖くない。SQL実践入門 - プログラマでありたい
技術評論社さんから、SQL実践入門を献本いただきました。ありがとうございます。 SQL実践入門の主題 この本の目的は、「パフォーマンスの良いSQLの書き方、特に大量データを処理するSQLの性能向上の方法を理解すること」とあります。そのパフォーマンス向上の為の解として、SQLが内部的にどう処理されているかを表す実行計画の読み解き方を、いろいろなケースを上げながらひたすら解説しています。そして、何故その実行計画になるのか、データ構造やDBの動きとともに説明しています。ということで、実行計画大事という基本かつ当たり前のことを、正面から取り扱っている良質のSQL本です。 SQL実践入門の構成 SQL実践入門の章立ては、下記の通りです。 第1章：DBMSのアーキテクチャ──この世にただ飯はあるか 第2章：SQLの基礎──母国語を話すがごとく 第3章：SQLにおける条件分岐──文から式へ 第4章：集約
新著が出ます：『SQL実践入門』 - ミックのブログ
4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
qpstudy 2013.07の懇親会でRDBMSのインデックスに関するクイズLTをしてきた - このブログはURLが変更になりました
2013/07/28に開催されたqpstudy 2013.07の懇親会で、RDBMSのインデックスに関するクイズLTをしてきました。 発表資料はこちら。 インデックス使えてる？じぇじぇじぇ！ from Takuto Matsuu 補足事項 発表では3問出題しましたが、本家のThe 3-Minute Test: What do you know about SQL performance?は5問あります。インデックスに自信が有る方は是非チャレンジしてみてください。 資料にも書きましたが、Use The Index, Luke!はインデックスを学ぶなら必見のサイトです。是非どうぞ。 Use The Index, Luke!の内容をまとめた書籍SQL PERFORMANCE EXPLAINEDについては以前このブログで紹介したのでそちらをどうぞ。PDF版もあります。 Use The Index,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)