Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
![[小ネタ] SQLの GROUP BY / ORDER BY には数字 (1, 2...) を指定しよう - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/53a56ab3a66d4cb6943237e1b6a716a6fd2fbca3/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU1JUIwJThGJUUzJTgzJThEJUUzJTgyJUJGJTVEJTIwU1FMJUUzJTgxJUFFJTIwR1JPVVAlMjBCWSUyMCUyRiUyME9SREVSJTIwQlklMjAlRTMlODElQUIlRTMlODElQUYlRTYlOTUlQjAlRTUlQUQlOTclMjAlMjgxJTJDJTIwMi4uLiUyOSUyMCVFMyU4MiU5MiVFNiU4QyU4NyVFNSVBRSU5QSVFMyU4MSU5NyVFMyU4MiU4OCVFMyU4MSU4NiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9ZGE0YTMxMTZmMmIxMDM0NDk0YjcxOTAyZTRmYmQ3NmY%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzc2Mta3NhaXRvdSZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ODc1YWI0ZmU0Y2UxYzZjMmQ3ZTExMTdkNDJkYTBhODE%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gU1NDIFImRA%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Db1d9e6c06055f91050fb82ce614c92b6)
概要 この記事では、MySQLでのSQLクエリのパフォーマンスを最大限に引き出すための効率的な書き方を解説します。アプリケーションの応答速度を向上させることは、ユーザーエクスペリエンスの大幅な改善に直結します。この記事を通じて、初心者から中級者のデータベース管理者や開発者は、SQLクエリの基本から高度な最適化テクニックまで、幅広い知識を習得できることを目指しています。 MySQL 8.0での検証を基にしていますが、その他のバージョンでの動作は保証されません。この記事は継続的に更新されます。 主な内容 このセクションでは、検証データの作成手順を含め、インデックスの利用、JOIN操作の最適化、サブクエリとビューの利用、クエリキャッシュの活用など、効率的なクエリの書き方について解説します。 検証データの作成 MySQLサーバーへの接続方法から始め、テスト用データベースとテーブルの作成、ダミーデー
package main import ( "fmt" "log" "github.com/jmoiron/sqlx" _ "github.com/lib/pq" ) // Employee は構造体です type Employee struct { id string number string } func main() { db, err := sqlx.Connect("postgres", "host=db port=5432 user=root sslmode=disable") if err != nil { log.Fatalln(err) } var nums = []int{4445, 5432} query, args, err := sqlx.In("SELECT * FROM employee WHERE emp_number IN (?);", nums) qu
概要 この記事では、SQLクエリをより効率的に記述するためのベストプラクティスとテクニックに焦点を当てています。データベースのクエリはシステム全体のパフォーマンスに直結するため、最適な書き方を知ることは重要です。インデックスの効果的な活用方法、適切な結合の選択、そして条件の効果的な書き方など、SQLの最適化に関する具体的な手法を解説します。各SQL文に関する実行計画の結果も掲載していますので、ぜひご確認ください。 なお、Oracle19cとOracle12cでの利用実績がありますが、他のデータベースやバージョンにおいての検証は行っておりません。 新しい情報は随時追加されますので、お楽しみにしてください。 SQLの最適化に関連する基本的なアイデア 以下の通りと考えています。 1.インデックスの利用 2.正しいJOINの選択 INNER JOIN、LEFT JOIN、RIGHT JOINなど、
http://qiita.com/advent-calendar/2015/gaiax 初めまして、GaiaxAdventCalender 4日目担当の技術開発部の金田と申します。 既に熱い記事ばかりなので後続の人たちのハードルを下げる為に小ネタで行きたいと思います。 GROUP_CONCATという関数がMySQLにあるんですがそれがアツいのでみんなに教えたいという記事です。 1対多の関係のとき 普通にテーブル設計してると1対多の関係(has many)になるリレーションシップをテーブル間で張ることが多いですよね。 まぁこんな感じで。 ざっくりと記事に対して複数のタグが設定できるような作りを想定してみます。 Entryから出た線がTagは複数に枝分かれしているのがhas manyの関係です。 で、こんなデータが入ってます。 取得するとき 記事と、それに付随したタグの一覧を取得したいときは当
(3)インデックスとテーブルへのアクセス(Index Seek、Index Scanなど) https://use-the-index-luke.com/ja/sql/explain-plan/sql-server/operations 実行計画には、「インデックスとテーブルへのアクセス方法」が表れている。 SQLServerの用語は非常にシンプルで、以下の通りになっている。 ・「Scan」:インデックス全体を読み込む。 ・「Seek」:インデックスあるいはテーブルの指定された一部のみにアクセスするために、Bツリーや物理アドレス(RID)を使う処理。 ①Index Seek、Clusterd Index Seek Bツリーの走査に加えて、一致するエントリを探すのにリーフノードチェーンをたどる。 ②Index Scan、Clusterd Index Scan インデックスの全体、つまり全行を
C#でSQLite3を使ってみたのでまとめ。DBが1つのファイルで完結するって何かと便利ですよね。 このへんの記事が参考になりました。 SQLite で LINQ を使う : http://www.moonmile.net/blog/archives/7979 C# で SQLite を便利に使うサンプルコード(LINQ to SQLite): http://shinta0806be.ldblog.jp/archives/9084539.html 1.どのパッケージを使う? ここが問題。NuGetで「SQLite」で検索すると、 まずどれを使っていいかわかりません。大抵「System.Data.SQLite」をインストールするのですが、これはEntity Frameworkや、SQLiteのLINQ拡張(これを入れなくてもLINQ to SQLが使える謎)など全部入った欲張りセットで、気づ
2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか? 今回は、そんな方々にこそ
株式会社オズビジョンのユッコ (@terra_yucco) です。 オズビジョンのハピタス事業部では、社内メンバがさっくり集計をしたり本番データを見るツールとして re:dash を使っています。こちらで本日、すごく簡単な改善対応を行ったことが喜ばれたので、Qiita に個人メモとして残しておきます。 前提 Re:dash は 2.0.0+b2990 (そろそろ化石...?) Re:dash の SQL で数値を SELECT したときのカンマを削除したい デフォルト?では Re:dash は数値型を表示するときに 3 ケタ単位でカンマを入れてきます。これが不要なケースで、カンマを取りたいときの対応方法になります。 Re:dash と併用している管理画面では、対象の数値にカンマを入れていないため、わざわざカンマを手で削除してからデータ突合を行ったりしていたらしいです...大変...。 この
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較
(この記事は 地平線に行く とのマルチポストです) 本番環境でやらかしちゃった人 Advent Calendarで、このパターンのやらかしはなかったのでキーボードを叩くことにしました。 番外編のつもりでお楽しみください。 この記事が、新たな障害発生を防ぐことにつながれば幸いです。 何をやったのか ある日、ちょっとした調査のために本番データベースのデータを確認することになりました。 (個人情報が格納されているようなシステムではなかったので、必要であれば本番データベースへのアクセスが許されていました) もしメンテナンスがあればそのタイミングでやればよかったのですが、直近では特に予定はないとのことでした。そのため、システムが動いている状態のまま作業をすることにしました。 ごく単純な SELECT を実行するだけのつもりだったので、システムに影響がないと判断したためです。 その際、万が一コピペをミ
みなさんこんにちは ジーズアカデミー 主席講師 山崎ですm(_ _)m 今回はLaravelで超高速「モックアップ作成」が可能な LaravelDB.comについてMemoしておきます。 ◇Laravel DB.com を初めての人はこちらから YouTubeにて解説 [初めての人はこちらの記事から>> ] https://qiita.com/daisu_yamazaki/items/9f0dd73553367f8077f0 『Laravel Migrationファイル生成』 『クエリービルダー生成』 機能は、まだβ版ですが ER図で設計したあとにベーステンプレートのMigrationを作成、QueryBuilderだけでも、全て書かなくて良いので捗るはずです。 ※アプリ名はLaravelに寄せたので変更しました。 新機能 「ER図から Query Builder 」も生成 外部キーの制約
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く