エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント2件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
:selectで取得するカラムを絞ったらパフォーマンスが倍に - ひげろぐ
最近管理しているDBサーバで継続的にスロークエリが出るようになったので、チューニングしてみたら気持... 最近管理しているDBサーバで継続的にスロークエリが出るようになったので、チューニングしてみたら気持ちの良い結果が出た。 結論から言うとカラム数が多いテーブルに対しては:selectで取得するカラムを絞るのがかなり有効かと思う。 現状把握 今回スロークエリの発生していたテーブルの状況を整理したのが以下。 レコード件数は110万件くらい カラム数は30程度 インデックスは効いている(explainで確認済み) 処理の性質的にキャッシュは使えない スロークエリになっているのはもっぱら以下のクエリ。 select * from pages order by updated_at limit 100; Railsのコードで見るとこんなかんじ。 Page.all(:order => 'updated_at', :limit => 100) こんな単純なクエリが実行に2秒から10秒程度もかかってスローク
2012/06/11 リンク