LINQ to Entities（クエリ式）と生のクエリってそんなに実行速度が異なるのですか？

Question

現在インターンでとある会社のアプリケーションのスタッフツールの速度改善を行っております。
環境はwindows(intel corei-5)、ASP.NET MVC5,VisualStudio2017,EntityFrameWork6.2,MySql.Data8.03です。

基本的に放置気味な感じで体感で表示して遅いなってところを直してみてといった感じの要求がざっくりしている内容である為、stopwatch.Start();、stopwatch.Elapsed;等のストップウォッチ系のプロパティを置いて実行速度を計って遅そうな箇所を調べていました。（あとはchromeの検証<network画面を見たりという感じです）

調べた結果やはり実行に時間がかかるのがDBとのやり取りで、2万件ほどある顧客の情報をListとして取ってくるといった処理には少々時間がかかっていました。
とは言ってもそれを画面に表示するのにかかる時間は大体5秒くらいで、表示やページングを除く、リスト取得のメソッドが実行されるまでには大体2.5秒ほどかかるものでした。なので言うほど改善するべき箇所か疑問です。ログにそのLINQ式をSQLとして吐き出してみたのですが、書き方もとんでもなく冗長な形になっていましたし、それをべた書きして実行するのもどうかと思いました。。

特に他の箇所では無駄なループが回っていたりするようには見えないですし、高速化するといっても構文レベルの問題ではないでしょうし困っています（緩いインターンではあるので別にアウトプットをそこまで求められているものではないのですが）。
C#（.NET MVC）のDB周りの高速化について調べていると、生のSQLを発行させることが一番速いといった記事をよく目にしました。しかし記事によっては誤差の範囲や、そこまで変わらないといったものも目にしました。

質問をまとめるとアプリケーションのパフォーマンスを上げる上でLINQ to Entitiesと生のクエリを書くことはそこまで違いが出るものなのでしょうか？
またサイトパフォーマンスを上げたい際はどのようなことに着目すればよいでしょうか？
抽象的な質問で申し訳ございませんがよろしくお願い致します。

Answer 1

こんにちは。

EntityFrameworkはどうやっても生SQLよりは遅くなります。Linq to Entitiesはクエリの組み立てにもある程度のコストが掛かってしまうからです。
しかし、それで生SQLに置換したところで速度が改善できるかというと、その箇所がネックになっていない限りは労力に見合わない結果になります。
まずは、以下を確認してみてください。

1. EntityFrameworkが吐いたクエリと「同じもの」を返すクエリを自分で書いてみて、それぞれを直接発行したときに速度に明らかな違いがあるかどうか
2. EntityFrameworkが発行したクエリの中で、実際には必要の無いデータを取得していないかどうか

この2つを調査し、それにより明らかに速度に差が出るというのであれば、生SQLに置換することで速度の改善が見込めるということになります。
2番については、Linq to Entitiesの記述を見直すことで改善できる可能性もあります。

その他に、速度低下を起こしやすいものというと、「ループで呼び出している部分が実は内部でIO処理を行っていた場合」ですかね。例えば、2万件のループで2万回DBに接続している、とか。こういうのは社内フレームワークの中に埋もれていたりすることがままあるので注意する必要があります。

Answer 2

生のSQLを発行させることが一番速い

意図するところは、冗長な記述を排除し、適切なインデックスが使用されるように、SQLチューニングが可能であるという事です。

サイトパフォーマンスを上げたい際はどのようなことに着目すればよいでしょうか？

実際に出力されているその冗長なSQLに対し実行計画を取得して、不足のインデックスを追加するなどは行えるのでは無いかと思います。

ただ、

2万件ほどある顧客の情報をListとして取ってくるといった処理には少々時間がかかっていました。
とは言ってもそれを画面に表示するのにかかる時間は大体5秒くらいで、表示やページングを除く、リスト取得のメソッドが実行されるまでには大体2.5秒ほどかかるものでした。

画面の描画の方が時間が掛かっていますので、手当てするのは画面の方が改善効果は望めそうです。
つくり的なところもあると思いますので、具体的手当については言及できませんけれど。