MySQLのGROUP_CONCATがアツい - Qiita
http://qiita.com/advent-calendar/2015/gaiax 初めまして、GaiaxAdventCalender 4日目担当の技術開発部の金田と申します。 既に熱い記事ばかりなので後続の人たちのハードルを下げる為に小ネタで行きたいと思います。 GROUP_CONCATという関数がMySQLにあるんですがそれがアツいのでみんなに教えたいという記事です。 1対多の関係のとき 普通にテーブル設計してると1対多の関係(has many)になるリレーションシップをテーブル間で張ることが多いですよね。 まぁこんな感じで。 ざっくりと記事に対して複数のタグが設定できるような作りを想定してみます。 Entryから出た線がTagは複数に枝分かれしているのがhas manyの関係です。 で、こんなデータが入ってます。 取得するとき 記事と、それに付随したタグの一覧を取得したいときは当
GROUP BY を使用せずに HAVING を使う - Qiita
例えば下記のように複雑な条件に基づいてレコードを抽出する場合、WHERE を使うと残念なことになります。 SELECT T.id, ( CASE WHEN /*難解極まりない条件1*/ false THEN 1 WHEN /*難解極まりない条件2*/ false THEN 2 WHEN /*難解極まりない条件3*/ false THEN 3 ELSE 0 END ) AS stat FROM tbl T WHERE ( CASE WHEN /*難解極まりない条件1*/ false THEN 1 WHEN /*難解極まりない条件2*/ false THEN 2 WHEN /*難解極まりない条件3*/ false THEN 3 ELSE 0 END ) = 2 とても保守性が低いと思います。 WHERE を無くして stat を使用してアプリケーションレイヤーで絞り込むことも出来ますが、そうす
Where狙いのキー、order by狙いのキー
Perl Hobby Programming - Games::BeLike::EightBIT ターミナルで8ビット風ゲームをつくろうkeroyonn
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
長年の議論に終止符 -- MySQL、MariaDB、PostgreSQLのオプティマイザ/エクゼキュータ比較 - interdb’s blog
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、４つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記：オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 ＊念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
SQLに対するMySQLと、NoSQLに対するMongoDBは似ている――主に有害な意味で | Yakst
MySQLのジョインが遅いことでSQL全般のジョインが遅いと思われることがあるように、NoSQLの中でもMongoDBが比較的広く使われるようになってきた今、MongoDBの欠点がNoSQLの欠点だと勘違いされるようになってきているのではないか。「SQL Performance Explained」著者Markus Winand氏の指摘。 昨日(9/30)の夕方、私は「SQLに対するMySQLのように、NoSQLに対するMongoDBにはよくない面がある」とツイートをした。あいにくそのツイートには説明が欠けていた。とはいえ1つのツイートに全ての必要な説明を含むことはできないだろうから、この記事で説明しよう。ツイートへの返事として受け取ったいくつかの疑問に答えられればと思う。 まず最初に、私は多言語永続化の考え方に賛同はするが、NoSQLの熱狂的支持者ではないということを知っておいてほしい。
チューニンガソン5の復習 MySQL 5.6 新機能編 - SH2の日記
というわけで、MyNA(日本MySQLユーザ会)会 2013年3月に参加して発表をしてきました。とてもリラックスして話をすることができました。司会進行の坂井さんをはじめ日本MySQLユーザ会のみなさま、日本オラクルのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは前回のエントリの続きということで、MySQL 5.6の新機能Optimizer Traceを活用しながら正攻法でのチューニングを行っていきました。とはいえ途中から正攻法ではなくなっていた気もします。MySQL 5.6でRDBMSとしての土台はしっかりしてきたと思いますので、今後は高度な統計情報を使用したSQL実行計画の最適化といったところにも機能強化が施されていくのではないかと期待しています。 プレゼンテーション資料 (PDF) EXPLAINとOptimizer Traceの出力結果 プ
GROUP_CONCAT関数の便利さは異常 - 開発の風景 〜KKZのSE日記〜
http://dev.mysql.com/doc/refman/5.1/ja/group-by-functions.html GROUP_CONCAT(expr) この関数は、グループからの連結された非 NULL 値を伴うストリング結果を戻します。非NULL 値がない場合は NULL を戻します。MySQL では、式のコンビネーションの連結された値を得ることができます。DISTINCT を使用することで、重複した値を除くことが可能です。結果の値をソートしたい場合は、ORDER BY 句を使用してください。逆順でソートするには、DESC ( 降順 ) キーワードを、ORDER BY 句のソートするカラムの名前に加えてください。デフォルトでは昇順になっています。これは、ASC を使うことで明示的に指定することができます。SEPARATOR の後には、結果の値の間に挿入されるべきストリング値が続
MySQL SQLオプティマイザのコスト計算アルゴリズム - SH2の日記
いちいさんにお誘いいただいて、勉強会で発表をすることになりました。 InnoDB Deep Talk #1 : ATND おそらく初見では内容が難しいと思いますので、先に資料を公開しておきます。 プレゼンテーション資料 (PDF) テストデータ生成スクリプト (JdbcRunnerで利用します。) プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Bugs: #64567: Last_query_cost is not updated when executing an unique key lookup Understanding and Control of MySQL Query Optimizer: Traditional and Novel Tools and Techniques: MySQL Conference & Expo 2009 - O'R
Covering Index と self-join と MySQL - blog.nomadscafe.jp
某サービスのクエリチューニングのお話。 ブログとか日記とかそういうサービス系で次のようなテーブルがあったとします。 CREATE TABLE entries ( id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, user_id INT UNSIGNED NOT NULL, posted_by TINYINT UNSIGNED NOT NULL, --#PC、mobileなどどこから投稿されたかのフラグ title VARCHAR(512) NOT NULL, body TEXT NOT NULL, created_at DATETIME NOT NULL, updated_at TIMESTAMP NOT NULL, status TINYINT UNSIGNED NOT NULL, INDEX (user_id,created_at
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
MySQL 5.1のmysqldumpslowで快速チューニング - SH2の日記
MySQL 5.1のmysqldumpslowを使うとチューニングが楽になる！という話題です。 mysqldumpslowはもともとMySQLに付属しているツールで、スロークエリログを集計してくれるものです。これ自体はMySQL 5.1で特に変わったところはありませんが、スロークエリログ本体の方が機能強化されているため、組み合わせるとなかなか便利になっています。MySQL 5.1におけるスロークエリログの主な機能強化は以下の三点です。 long_query_timeに1秒未満の値を設定できるようになった。 出力先を設定できるようになった。 これらの設定をオンラインで変更できるようになった。 これでどうなるかというと、MySQLの性能分析をしたいと思ったときに、サーバを止めずにその場で mysql> set global slow_query_log = 1; mysql> set glob
1:nなデータを検索しやすくDBに入れたい (2008-03-20)
手元に資料があるもので適当に問題を置き換えたので例が悪いが、とにかくこういうデータをどういうスキーマで格納するかを考える。教科書どおりに沿って考えると、このデータは正規化されていないので、正規形に変える必要があるだろう。 夜行バス ID名前行き先片道運賃 1
mysql:2641
From: <cotton@xxxxxxxxxx> Date: Sun, 22 Oct 2000 15:57:18 +0900 Subject: [mysql 02641] Re: SQL 文の長さについて。 有難うございます。 １６Mもあるんですか、、、意外に大きいです。 私が参考にしたのは http://www2p.biglobe.ne.jp/~sakurait/cstrue/chap4.htm#bm4.18 の、 ＞気を付けなければならないこととして、発行する SQL文字列の長さに制限があ ＞るということです。Microsoft SQL Server では 120Kバイト程度 (実用上はもっと ＞小さいのではないかと思いますが)、Oracle ODBC Driver & SQL*Net2.X では約 ＞30Kバイト程度です。Oracle ODBC Driver & SQL*Net１.
Prepared statementを使うとQuery cacheが効かない - フツーな日常
4.1の日本語化されたマニュアルばかり読んでいたらこの動作への言及が無かったため見落していたが、5.0に対応したオリジナルである英語版にはちゃんと注意が書いてあった。 道理ででnot_cachedばかりが増えていくわけだ。それだけコード側でのprepared statementの利用が徹底されているということは、それはそれで良いのだけど、どうしよう。繰り返し利用しないようなSQLでパラメータも固定のものはprepareしないでいきなり実行するように書き換えてしまうべきか。無論、Injection対策になる部分を無理矢理書き換える必要はないんだけど。 機能として同じような場所で動くものだから協調して動作させるのが難しそうではあるが、本質的に共存不可能なものではないので実装自体が改善してくれると嬉しい。 (追記) よくよく考えると共存はかなり面倒な実装になりそう。そもそもPrepared st
MySQL :: MySQL 4.1 リファレンスマニュアル :: 5.2.8 MySQL による ORDER BY の最適化
余分なソートを行わずに ORDER BY または GROUP BY の要求に応じるために、MySQL はインデックスを使用する場合があります。 全ての使用されていないインデックス部分と他の部分が WHERE 節内で定数であるカラムである場合、ORDER BY がインデックスに完全にマッチしない場合でもこのインデックスを使用できます。 次のクエリではインデックスを使用して ORDER BY / GROUP BY 部分を解決します。 SELECT * FROM t1 ORDER BY key_part1,key_part2,... SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2 SELECT * FROM t1 WHERE key_part1=constant GROUP BY key_part2 SELECT * FR
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Query Optimizations
Schemasync.org
Introducing MySQL Visual Explain
Explain