天蠶在你身邊
不方便打電話?讓天蠶聯(lián)絡你
天蠶在你身邊
不方便打電話?讓天蠶聯(lián)絡你
天蠶重慶網(wǎng)絡公司:我們在進行系統(tǒng)或者我們叫它軟件,在開進行開發(fā)時,對它的數(shù)據(jù)庫以及結構,是需要作一些必要優(yōu)化處理的,下面來看看詳細的介紹:
1. 程序優(yōu)化
a. 當只限取前面N條記錄時,不要用 select * ,然后再用ADO分頁
改為 select top N 字段列表 這樣的語句會高效很多
b. 統(tǒng)計記錄數(shù)時不要用 select * from .... 這樣的語句,改
用 select count(1) from .... 這樣會好很多
c. 盡量避免使用 select * from table 這樣的sql語句,這樣會導致程序從數(shù)據(jù)庫里讀取太多無用的數(shù)據(jù),一般來說應該使用
select 字段1,字段2 from table 這種形式,只從數(shù)據(jù)庫里讀取必要的數(shù)據(jù),這樣能大大提高程序讀取數(shù)據(jù)庫的效率
d. 不要用嵌套查詢,比如
<%
sql = "select col1,col2 from a"
set rs = server.createobject("adodb.recordset")
rs.open sql,conn,1,1
while not rs.eof
sql2 = "select col1,col2 from b where id=" & rs("id")
set rs2 = server.createobject("adodb.recordset")
rs2.open sql2,conn,1,1 '這里用了嵌套查詢,效率會下降很多,如果數(shù)據(jù)庫的時候根本沒法運行
while not rs2.eof
response.write rs("id") & "=" & rs2("name")
rs2.movenext
wend
rs.movenext
wend
%>
如果改為
<%
sql = "select a.id ,b.name from a left join b on b.id=a.id" '使用連表操作,并用具體的字段名代替 *,程序是高效很多
set rs = server.createobject("adodb.recordset")
rs.open sql,conn,1,1
while not rs.eof
response.write rs("id") & "=" & rs("name")
rs.movenext
wend
%>
2. 數(shù)據(jù)庫結構優(yōu)化
a. 比如一些標志信息是否認證之類的字段要建索引卻沒有建
b. 表沒有設主鍵,加上主鍵
c. 外鍵一般都要加上索引
3. 對于 access 數(shù)據(jù)庫:
access 數(shù)據(jù)是一個桌面型的數(shù)據(jù)庫系統(tǒng),它只能應付一些數(shù)據(jù)量少且訪問量不大的網(wǎng)站,如果access的數(shù)據(jù)庫超過
100M 以上,性能會急速下降,并且 access 數(shù)據(jù)庫的數(shù)據(jù)庫驅(qū)動程序只能應付同時15個進程共享,也就是說它最多只能
允許15個人同時打開它,對于大訪問量的網(wǎng)站來說這是很低的一個數(shù)值,所以一般訪問量大或者是數(shù)據(jù)量大的網(wǎng)站一般
要采用 sqlserver 或者 mysql 等高性能的數(shù)據(jù)庫服務器平臺。
有很多人使用 access 數(shù)據(jù)庫時并沒有對數(shù)據(jù)庫的結構進行優(yōu)化,這也是造成網(wǎng)站程序效率低下的另一個重要原因
一般來說每個數(shù)據(jù)表都要設置一個主鍵,并且其外鍵一般都要建立索引,還有一些標志性的字段(如果標記一條信息是否是
通過審核等)如果不是布爾型的話,一般來說也應該建立索引。
在查詢程序優(yōu)化方面 , 如果用 ADODB.Recoedset 自帶的分頁功能,也是存在問題,
因為用ADO分頁的話,這個對象是先將很多的記錄選出來,加載到對象里(這將導致這個對象可能會加載成千上萬的記錄),
再在對象里通過移動記錄游標等操作來達到定位到某一行的目的,當數(shù)據(jù)量大的時候,性能也會急速下降。
如果采用 where RecID NOT IN(....) 這種結構的話,雖然記錄集不會加載很多的數(shù)據(jù),但是在數(shù)據(jù)庫引擎在查詢時
做這種NOT IN(...) 的比較是很費時間的,比如 NOT IN 的列表里有 1000 個記錄ID,這在查詢是將導致對整個數(shù)據(jù)表
的每一條記錄都跟這1000個ID進行比較,比如數(shù)據(jù)表里有 3000 條記錄,那么執(zhí)行這條 sql 的時候?qū)е?3000*1000 這么
多次的比較,效率之低是可想而知的.
對于分頁的優(yōu)化方法:
采用分步查詢,這個方法可能要對數(shù)據(jù)表的結構作一些修改.
1. 數(shù)據(jù)表本身的主鍵( 比如是 RecID )應該是數(shù)字類型的。
2. 要查詢分頁的時候
(1). 先得出不應該包含在最終查詢結果里的記錄的最大ID號,比如
比如要查詢第 100 條記錄以后的 N (N=每頁的記錄數(shù)) 條記錄,可這樣做:
<%
SQLMAXID = "SELECT MAX(RecID) FROM(SELECT TOP 100 RecID FROM ChatRec WHERE RecID>0 ORDER BY RecID)"
'這里只返回一個值,就是最大的ID
%>
(2). 執(zhí)行最終的數(shù)據(jù)查詢
比如
<%
SQL = "SELECT TOP 每頁的記錄條數(shù) * FROM ChatRec WHERE RecID>("& SQLMAXID &") ORDER BY RecID"
'這里是找出 ID > MAXID 的前 N 條記錄
%>
這樣的話避免用 NOT IN(...) 這個語句,效率會提高很多
說明:用這個方法有一點一定要注意的是子查詢跟主查詢都必須要按某個字段用相同的規(guī)則排序,比如像例子中的 ORDER BY RecID
并且一般建議用主鍵來進行排序
4.asp程序中應盡量避免用 on error resume next
很多用戶會采用 on error resume next 來屏蔽掉出錯信息,這樣雖然可以讓訪客看不到出錯信息,界面友好一些,但是這樣可能會帶來非常嚴重的問題:當程序出錯后,如果沒有及時的捕獲異常,從而中止程序執(zhí)行的話,很空間導致程序出現(xiàn)死循環(huán),導致服務器當機,所以只有在非常必要的情況下才好使用 on error resume next ,并且在使用on error resume next后及時捕獲異常,如果出現(xiàn)錯誤就中止程序執(zhí)行。比如:
<%
set conn = Server.CreateObject("ADODB.Connection")
connstr = "Driver={SQL Server};Server=db107.72dns.com;UID=abc;WD=abc;Database=abc"
on error resume next '這里的用 on error resume next 是為了屏蔽連接數(shù)據(jù)庫時出錯的信息
err.clear
conn.open connstr
if err.number<>0 then '這里開始及時捕獲異常,中止程序執(zhí)行,否則很容易死循環(huán)而令服務器當機
response.write "鏈接數(shù)據(jù)庫服務器出錯"
response.end
end if
%>
天蠶重慶網(wǎng)絡公司總結: 如果網(wǎng)站的訪問量大并且數(shù)據(jù)庫查詢操作的任務比較重,要考慮采用自動生成靜態(tài)頁面然后定時自動更新的技術
地址:重慶市渝中區(qū)上清寺鑫隆達B座28-8
郵編:400015
電話:023-63612462
EMAIL:cnjl_net@163.com