SQL：長いvarcharとパフォーマンスへの影響

Question

非常に遅いデータベースで作業しています。私たちは、ASP.NETを使用してデータベースにアクセス/データを取り込みます。私はデータベースが初めてで、いくつかのことが適切に行われていないことがわかりました。私はこれらについてもっと精通した意見を得たいと思う。

私たちのデータベースでは、zip_codes、text_ids、名前、住所、電話番号を含むほぼすべての文字型フィールドにvarchar（255）が使用されています。 1つのテーブルには約60個のテーブルがあり、そのうちのいくつかは比較テーブルにも使用されています。私の質問は、パフォーマンスにどれくらいの牽引力がありますか？私はそれを変更したりそのまま残すべきですか？私はパフォーマンスの問題を強調することができる答えを探しています。

編集：だから私はvarcharではなく接続で作業する必要があると思います。誰かが私の質問Can I use connection pooling with SQLDatasource?に回答を投稿できますか？ログインには約20秒かかりますが、その後は受け入れられますが遅くなります。データベースとアプリケーションは同じマシン上にあります。

Answer 1

そのままにしてください。この定義には問題はありません（少なくとも、MS SQL Serverでは合計レコードサイズが8KBを超えない限り）。あなたの問題はあなたのクエリに関係している可能性が非常に高いので、暗黙のうちにインデックスの定義と使用法に関係しています。

プライマリキーのインデックス以外のインデックスがないため、実行速度の遅いクエリを確認し、インデックスをWHERE句のフィルタフィールドに追加する必要があります。

SQL Server Performance Tips and Guidelines

Answer 2

varcharフィールドの長さ等

郵便番号、電話番号、などの数値のためにそれらを使用するよりも問題が少ないです：あなたは、SQL Serverのパフォーマンスに関するヒントの次のコンパイルを検討する必要があります

数字はです。LOT文字列よりもスペースが少なくなります。例えば：smallintとして

28245はvarchar(255)として

'25245'が（データの5バイト）+（2バイトストア長さ）= 7バイトも

移動します2バイト取り文字列は数値とは異なるソートをするので、ソートには奇妙な問題があります。

つまり、varchar(20)とvarchar(255)の間にパフォーマンスの違いはありません。 Varcharはvarcharがvarcharであり、唯一の違いはフィールドで取ることができる空間のLIMITです。

Answer 3

これは心配しないでください。まず、索引付けを見る必要があります。次に、実行中の特定の長期実行クエリのチューニングを調べる必要があります。クエリの書き方が悪いのは、私の経験ではパフォーマンスの悪い最も一般的な原因の1つです。しかし、あなたは基本的にインデックスがないので、最初に来なければならないようなサウンドです。

Answer 4

この表に大量のデータがある場合を除き、フィールドの種類がパフォーマンスに影響するとは思われません。データベースのパフォーマンスを向上させることを求められるときは、通常、データにアクセスするクエリを改善し、既に存在するデータに対してより良いインデックスを作成することによって大きな影響を与えることができます。

また、データベースとWebサイトが同じサーバー上で実行されているか、その間に接続が遅いために遅延が発生する可能性がありますか？