2017/06/26 14:00:59
kakerukaeru
ｷｬｰﾏﾂｳﾗｻｰﾝ!!
2017/06/26 14:15:02
rx7
中身の前に、画像の素材として秀逸...
2017/06/26 14:41:22
garage-kid
58
2017/06/26 15:29:44
t-wada
わかりやすく充実したインタビュー記事。『SQLパフォーマンス詳解』の良い紹介にもなっている。
2017/06/26 15:50:02
bell_chime_ring238
これ。こういうこと知りたかった。本も買おう。
2017/06/26 16:12:37
masudaK
丁寧な記事
2017/06/26 16:37:27
lazex
sqlみたいな宣言型なものって中を理解して速度に優れるSQL書くんじゃなくて何がほしいかをわかりやすく書いて、SQLが違っても欲しいものが同じなら同じように実行するようDB側ですべきだと思うんだよなー。
2017/06/26 16:40:51
mmm-mao
“使って物理的なアクセスを減らすといった方法がおすすめです。”
2017/06/26 16:41:24
kuniku
RDBは10-20年経過しても、大きく変わってないよね。diskがmemmoreyには変わりつつある。プログラマーからはSQLは本質じゃないように見えている。
2017/06/26 16:54:44
minoton
商用RDBなら有償の最適化ツールやアドバイザが使えますよ！まあ、使いこなすにもこれらの知識が必要ではあるけど
2017/06/26 17:03:56
nozipperar
LIKEではなくてGLOBを使えば良いのでは　SQLは基本短くだな
2017/06/26 17:13:04
akuwano
まっさん！まっさんやないか！
2017/06/26 17:33:01
f_oggy
この程度のDBエンジニアにとっては当たり前のことでも土方プログラマにはなにそれ？なことって多い。ちょっとした教育を受けるだけでも違ってくるのにコストがそれを許さない環境が多すぎる
2017/06/26 17:48:46
lbtmplz
なるほど “MySQLは、「複雑なアルゴリズムはなるべくサポートしない」という設計思想に基づいて作られているからです。その代わりに、「よく使われる機能を高速にすること」を重視しています”
2017/06/26 18:07:45
hiby
ああ良い記事だー
2017/06/26 18:10:01
sakichi33
あと「プログラマのためのSQL」も定番。https://www.amazon.co.jp/dp/4798128023/
2017/06/26 18:16:14
nabe1121sir
内容は同意なんだけど、アーキテクチャの選定にプログラマが参加できない場合が多いというかほとんどなので、どうしようもないことも多い。
2017/06/26 18:49:09
suthio
いい記事
2017/06/26 19:05:40
Andrion
壁|∀ﾟ)つ NoSQL
2017/06/26 19:27:47
anoworl
「それでも後方一致検索をしたい」場合ぐらいなら、文字順を逆にして格納するという小技を使うと、インデックスを効かせられる。MySQLも仮想列に対応したし、頑張ればある程度は。
2017/06/26 19:53:22
tripleshot
吉田戦車のマンガに出てきそうなビジュアル！ (すみませんまだ記事本文ちゃんと読んでません)
2017/06/26 19:55:54
iww
謎ポーズ集
2017/06/26 20:24:10
frkw2004
複合インデクスはsqlに書いた列順に関わらずオプティマイザが適切に直してくれなかったっけ？　確認しないと。
2017/06/26 20:40:19
baronhorse
現実だけど、それでいいならあの宣言的な文法邪魔でしかないよね。手続き的なインタフェースそのまま出せよと思う。
2017/06/26 20:43:33
penalty
途中でmysqlのことかー！！とおもったらmysqlのこと言っていた
2017/06/26 20:51:20
deokisikun
苦手マン😣
2017/06/26 20:54:50
Shinwiki
un
2017/06/26 21:01:16
matsukaz
これが画像素材として話題の記事ですか（違う） 。良記事！
2017/06/26 21:17:00
mouseion
これを応用してクロームや火狐にある重い原因である複数タブを同時に開いた状態も解決できるのではと思うけど、多分有識のエンジニアたちがこれまでに何度も挑戦して破れて行ったはずだから難しいのだろうか。
2017/06/26 21:22:48
aaaaaaaaaa10
図解が分かりやすい
2017/06/26 21:31:50
uunfo
インデックスなんかそれこそ自動学習で適切なものを適宜張ってくれよと思う
2017/06/26 21:58:58
komutan1
5番はやんわり書かれてるけど完全なMySQLディス。
2017/06/26 22:14:37
lenore
昔の知見は意外とまだまだ有効なんだな。
2017/06/26 22:22:41
hakaikosen
オプティマイザが優秀なRDBを使えばいいと思う。
2017/06/26 22:24:24
tea2ka
パフォーマンスチューニングもせずに、問題起きると、DBのせい、NWのせいとか、インフラ的外的要因にしたがる開発者に見せたいもの。
2017/06/26 22:56:29
s-tomo
さすがにそれでネステッドループ結合だけだと使い物にならなくね？と思いかけたが「行数分だけ2つ目のテーブルのソートと走査」はあくまで最悪ケースであって適切なインデックスがあればそりゃ使われるか。
2017/06/26 23:11:17
rgfx
MySQLはF1と言われる所以。どのプロダクト・プロジェクトも目的に合った実装で特徴を出すことにより生き残っているのであり、それを踏まえずにレベルの低いORM理想論ぶっこいても何の足しにもならないんだよな。
2017/06/26 23:30:16
wata88
だよなーという気持ちになった
2017/06/26 23:30:30
nilab
SQL (というかRDBMSだろうか) はぜんぜん進化しないなぁ。いつまでたっても開発者が気をつけないといけないのか。
2017/06/26 23:58:19
knjname
ただただ普通のことしか書いてない
2017/06/27 00:02:05
masatomo-m
アプリエンジニア（だと思ってる）でもちょっとpercona toolkit使った高速化に手をつけたことがあれば通った道の話であった。求めすぎない度が良い
2017/06/27 00:29:57
lasherplus
i'm
2017/06/27 00:35:00
kirifue
"MySQLは、「複雑なアルゴリズムはなるべくサポートしない」という設計思想に基づいて作られているからです" -> お、おう。 #開発 #データベース
2017/06/27 03:33:13
toritori0318
良さ
2017/06/27 05:21:52
Dursan
S：ソースが Q：急に L：ロードされたので
2017/06/27 08:25:37
punkwozhey
sql
2017/06/27 08:42:15
sds-page
MySQLはなぜ遅くなるのか。サブクエリが遅いって言ったら「有償版買えば早くなりますよ」って返してきたOracleの営業許さん
2017/06/27 08:47:09
djwdjw
最後の10秒/0.1秒の話だけちょっと場合による…。
2017/06/27 08:48:54
perl-o-pal
SIerで仕事してる人は、驚くほどSQL読めないからORMの出力が全てと思っているフシがある。あとチューニング=メモリをガン積みしてバッファキャッシュに全部のっける、だからな。
2017/06/27 09:02:08
vanbraam
2度"指数関数的"という表現が出てくるが,本当に?と疑ってしまう.指数関数ってy=a^x,即ちxが10倍になると処理量がaの10乗倍になるという代物.ソートの計算量b:id:entry:263458306見ても指数関数になるとは思えないのだが
2017/06/27 09:19:45
uturi
分かりやすい記事。データベース系エンジニアにとっては普通の内容なのだろうけども。
2017/06/27 09:50:49
taruhachi
トップコメントの、「オプティマイザが頑張るべき。」(意訳)は正しいし、実際に開発側も頑張っている。しかし何処に最適化すべきかは利用アプリケーションによって異なるので色んな製品がありそれぞれ特徴がある。
2017/06/27 10:30:12
xlc
オブジェクト指向好きがSQLを学ぶ努力を怠ってるだけ。正規表現を知らずに自前のパーサを書くくらい馬鹿げてる。
2017/06/27 10:34:07
rjge
当たり前のことを当たり前にやってけばいいだけなんだけど、そもそも当たり前って前提がずれてるんだろうなとこの手の話を読むたびに思う。ずれた当たり前を補って伝えるの難しい。
2017/06/27 10:39:02
turanukimaru
対策としてはテーブルをシンプルに保つしかないと思ってる。だが追加情報や機能を削ってテーブルをシンプルに保つべきだという主張が通ったことはない。
2017/06/27 12:22:53
yogasa
何故彼女は重たくなるのか？
2017/06/27 12:43:56
masaru_b_cl
初心者の次に読ませてあげたい
2017/06/27 13:07:06
houyhnhm
まあ、所詮物理実体が存在するので、そこ考えないと無理で、問い合わせ側のSQLだけでチューニングするような話でもないです。／そもそも、社員IDと部署IDを組み合わせての複合インデックスが微妙だが。
2017/06/27 13:31:19
umiyosh
松浦さんだ
2017/06/27 13:59:36
qtamaki
常識の範囲内だった
2017/06/27 14:02:59
yanbow
sql
2017/06/27 14:17:50
kabacsharp
適切に索引張って、索引レンジスキャンすべきクエリと、フルテーブルスキャンすべきクエリを使い分けるだけでも、そこそこ回るよ
2017/06/27 17:24:23
yood
RDBMS全般の問題かと思いきや、プロダクト個別の問題だった。
2017/06/27 18:49:49
IGA-OS
MS Access任せになってるから、根本は勉強しておきたいネタ。
2017/06/27 19:57:00
wannabeahacker
SQL アーキテクチャ
2017/06/27 22:07:23
n_y_a_n_t_a
うちのSEさんたちには「そんなこと常識だろ」と言って欲しい
2017/06/28 01:18:40
koiwaiyon
スロークエリ監視も書いたほうがいいのでは
2017/06/28 13:51:58
shimooka
読み進めたけど、新しいことは何もなかった
2017/06/28 14:05:07
djshigy
SQL
2017/06/28 20:22:30
fire_0218
[] なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
2017/06/28 20:55:16
gologo13
割と普通の内容。設計思想は参考になった