我正在處理非常慢的數據庫。我們使用ASP.NET來訪問/填充數據庫。我是數據庫的新手，我發現有些東西沒有正確完成。我想獲得更多關於這些知識的見解。SQL：long varchar和對性能的影響
在我們的數據庫中，varchar（255）幾乎用於包括zip_codes，text_ids，名稱，地址和電話號碼的所有字符類型字段。一張桌子中大約有60張，其中一些也用於比較。我的問題是性能有多大的阻力？我應該改變它還是保持原樣。我特別希望找到能夠突出顯示性能問題的答案。
編輯：所以我認爲我需要在連接而不是varchar上工作。有人可以發佈回答我的問題Can I use connection pooling with SQLDatasource?。登錄需要大約20秒，之後它變得可以接受，但仍然很慢。數據庫和應用程序在同一臺機器上。
保持原樣。這個定義應該沒有問題（至少只要MS SQL Server上的總記錄大小不超過8KB）。您的問題很可能與您的查詢有關，因此隱含地指向索引定義和用法。
由於您除了主鍵以外沒有任何索引，因此應該檢查運行緩慢的查詢並將索引添加到WHERE子句中的篩選字段。你可能要考慮有關SQL Server性能的提示以下編譯：
添加一個註釋：根據您的答案中的鏈接，我應該減少列的寬度，並把它們的索引，因爲我將在WHERE子句中使用一些。我認爲縮小寬度使得索引效率更高。 –
的varchar字段的長度是不是利用他們像郵政編碼，電話號碼等
數字佔用LOT比字符串更少的空間。例如：
28245作爲smallint需要2字節
'25245'爲varchar(255)需要（5個字節用於數據）+（2個字節來存儲長度）= 7字節
也將有奇怪的問題與排序，因爲字符串排序不同於數字。
這就是說，varchar(20)和varchar(255)之間沒有性能差異。 Varchar是varchar是varchar，唯一的區別是它們在該字段中可以佔用的空間的限制。
不要將郵政編碼存儲爲數字！他們並不總是隻有在所有國家的數字！ – HLGEM
不要擔心這一點。首先你需要看看索引。接下來，您需要查看調整特定的長時間運行的查詢。根據我的經驗，糟糕的查詢寫作是表現不佳的最常見原因之一。但是，聽起來像你基本上沒有索引，所以必須先來。
除非您在此表中有大量數據，否則我不認爲字段類型會影響性能。每當我被要求關注提高數據庫的性能時，我通常可以通過改進訪問數據的查詢併爲已存在的數據創建更好的索引來產生重大影響。
此外，是數據庫和網站運行在同一臺服務器上或可能有一個緩慢的連接之間，造成延遲？
都在同一臺PC上，並且不涉及HTTP。我認爲連接可能是一個大問題。我們使用SQLDatasource，我認爲它不支持連接池。我們應該改用ADO.NET嗎？ –
你設置了索引鍵嗎？你使用哪種存儲引擎？ – blejzz
只有在主鍵索引，它是從之前 –