なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub｜Webエンジニアのキャリアを考える！

なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ

[lazex]

sqlみたいな宣言型なものって中を理解して速度に優れるSQL書くんじゃなくて何がほしいかをわかりやすく書いて、SQLが違っても欲しいものが同じなら同じように実行するようDB側ですべきだと思うんだよなー。

[f_oggy]

この程度のDBエンジニアにとっては当たり前のことでも土方プログラマにはなにそれ？なことって多い。ちょっとした教育を受けるだけでも違ってくるのにコストがそれを許さない環境が多すぎる

[sds-page]

MySQLはなぜ遅くなるのか。サブクエリが遅いって言ったら「有償版買えば早くなりますよ」って返してきたOracleの営業許さん

[anoworl]

「それでも後方一致検索をしたい」場合ぐらいなら、文字順を逆にして格納するという小技を使うと、インデックスを効かせられる。MySQLも仮想列に対応したし、頑張ればある程度は。

[penalty]

途中でmysqlのことかー！！とおもったらmysqlのこと言っていた

[knjname]

ただただ普通のことしか書いてない

[lbtmplz]

なるほど “MySQLは、「複雑なアルゴリズムはなるべくサポートしない」という設計思想に基づいて作られているからです。その代わりに、「よく使われる機能を高速にすること」を重視しています”

[rx7]

中身の前に、画像の素材として秀逸...

[tmatsuu]

経験的に「DISTINCTとGROUP BYを同時に使っている」も挙げたい。大抵の場合そのようなクエリーはもっとシンプルにできる。

[t-wada]

わかりやすく充実したインタビュー記事。『SQLパフォーマンス詳解』の良い紹介にもなっている。

[kotaroooo0]

“──次は、「複合インデックスを適切に使えていない」。どのようなときに、この問題は発生するのでしょうか？ ”

[tjmtmmnk]

気をつける8箇条

[yooks]

“し”

[mrpotas]

ORMのクエリ観ると、自分そんなの頼んでない、みたいなクエリが出てくることがあってビビる

[ElizaAcolyte]

アホほど重たい処理なんだから重たくなるのは当たり前で、なぜ早くできるのか？って思考のほうが実情に即している気がする。まぁ言葉遊びだけど。

[Mikatsuki]

SQLのパフォーマンスをなんとかする件

[akima9936]

ほーん

[nayuneko]

データベースってデータ量が少ないテスト環境だと問題にならないけど本番にリリースして大量のデータが登録されてから問題が顕著化してはじめてスロークエリのありがたみがわかるから難しい

[Iridium]

アーキテクチャの問題です。データ生成をプリコンパイル型にすれば解決すると常々思ってる。どうせ事前に確定する情報がほとんどでしょ。全部リアルタイムに取ろうとするから遅いんですよ。

[issy_s16]

良記事

[gologius]

“ORM”

[lowpowerschottky]

“データベースの仕組みを理解する”

[junk-boy]

“松浦 有名なORMのほとんどには、JOIN句を生成するなどN＋1問題を回避するための機能が備わっています。その機能をきちんと理解し、適切に使用するといいでしょう。 ”

[poppon555]

indexを正しく使おう

[dk19810313]

ごくごく当たり前の事しか書いてないね

[nyop]

あるある。だけどこんなことも知らないエンプラ系IT土方がいっぱいいる。

[nakag0711]

PostgreSQLにはクラスタ化インデックスがないという弱点が

[shields-pikes]

あとでも読む。

[tamtam3]

SQLは僅か数行の組み方一つで簡単に数百〜数千倍早くなったり遅くなったりするからね。処理が軽くなれば当然運用コストも大きく差がつくし利用者の満足度も向上するから極めて重要なポイントですね

[clotho_moirai]

基本だけど忘れそうなボトルネック

[rasterson]

ORMは使わない方がいいよね。少し【原因⑧】にも関係するけど、連番発行するテーブルでロック待ちになって速度が落ちているのを見たことある。安易に連番発行テーブルを作らない方がいいよ。よくみかける設計だけど。

[kanehama]

基礎中の基礎。ORMでクエリ意識ないといけないとかORMとは。って感じする。

[perl48]

SQLが重たくなったら読み返す。

[ku__ra__ge]

『USE THE INDEX, LUKE』もおすすめ。インデックスがどう働くかを理解してSQLを速くする方法が判る　http://use-the-index-luke.com/ja

[shun_libra]

現状、PGの場合は最初の段階でSQL使う仕事をやってるかどうかで、この辺の「基礎体力」の有無が決まってしまう。本番と同等のデータでサブクエリ使ったことあれば、検索範囲の局所化とかすぐ分かると思うので。

[gusyazero]

覚えておきたいけど、毎度忘れる内容… なので、懲りずに読む。

[ttop]

有用なの？あとで読む

[morinaga3]

SQL

[masarizm]

言語にパフォーマンスを求めるという事がそもそもナンセンス

[jaguarsan]

id:lazex の言うものがまさにORMだと思うんだが、残念ながら今の技術では足を引っ張る1番目に挙げられる悲しみ…