You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
こんにちは。麦芽系エンジニアasmzです。麦芽は東北産を使用しています。そろそろビアガーデンとか行きたいです。誰か誘って下さい。よろしくお願いします。 さて、私はこれまで engineering.otobank.co.jp engineering.otobank.co.jp とかでちょいちょい弊社Hubot(otobot君)に機能追加してきて、「この人Hubotばっかりやってるけど、実はオトバンクのHubot開発担当の人なのかしら?何なのかしら?窓際社員なのかしら?」と思われがちです。違います。何ですかHubot開発担当って。 まぁ主に仕事に疲れた時の気晴らしとかに、一人で勝手に作ってます。何故か深夜にプルリク出ることが多いやつです。 otobot君も最初はそんなに社内で活用されてたわけでも無いのですが、otobot image me でおもしろ画像表示して遊ばれたり(専用のSlackチャ
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら全般的に共通の考え方で対応できると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく、またインデックスを乱立すると複数の条件がある時などにオプティマイザが誤作動を起こす要因ともなります。よって本当にインデックスがないことが原因なのか?を熟考する必要があります。 基本的にルールベースと違いコストベースになるのでオプティマイザによって作成される実行計画が望み通りの計画になっているのかを見ながらチューニングしていく必要があります。 今まで見てきた遅いSQLはとんでもない結合順や使用されるインデックスがなんでここから?といった実行計画になっていた事が大半でした。 そういう時に正しい実行計画をオプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く