程序设计中的数据库优化技巧 - 网站源码_资源分享

一、表的结构设计

当在附注加进表头的这时候,假如优先选择宽度最轻的正则表达式,这种Amancey缓存中整本能储存更多的历史记录。如：“联系电话”表头通常增设为TEXT类别，宽度为10通常就绰绰有余，则比预设的255要好的多。authInteger的宽度是2，在采用authInteger就能补救的地方性千万别采用Single、Long、Double、Currency，即使它的宽度分别为４、４、８、８，都比２大。在创建Caura很大要创建检索，这能大大提升查阅速率，是提升速率最基本上的明确要求。

二、填充资料库

JET资料库的查阅强化是有付出的，随著资料库的不断增加，强化将无须起促进作用。填充资料库会发生改变资料库的状况，并再次强化大部份查阅。与此同时，随著统计数据库的减小，会造成许多碎块。而填充资料库能把两个附注的统计数据统计数据写到硬碟中已连续的页里，提升了顺序搜索的速率。

填充资料库采用CompactDatabase指示，上面的句子填充资料库并造成两个资料库储存：

DBEngine.CompactDatabase “C:VBBIBLIO.MDB”, “C:VBBIBLIO2.MDB”

Kill “C:VBBIBLIO.BAK” Name “C:VBBIBLIO.MDB” As “C:VBBIBLIO.BAK”

Name “C:VBBIBLIO2.MDB” As “C:VBBIBLIO.MDB”

特别注意，假如资料库非常大不然，可能将须要彻夜的天数来填充资料库。

三、防止查阅输入里头累赘的排序

当查阅的结论做为除此之外两个查阅的管理工具的这时候，可能将引发查阅强化难题。在那个这时候第二次查阅里头尽量减少大批的排序。在如下表所示实例中，Query1是第两个查阅的结论，接着它做为第三个查阅的统计数据源。

Dim DB As Database

Dim RS As RecordSet

Set DB = DBEngine.Workspaces(0).Opendatabase(“Biblio.MDB”)

DB.createQueryDef(“Query1”, _

“select IIF(Au_ID=1,’Hello’,’Goodbye’) AS X FROM Authors”)

Set RS = DB.OpenRecordSet(“select * FROM Query1 where X=’Hello’”)

由于在第两个查阅 Query1中的IIF()表达式不能被强化，，所以在第三个查阅中的where子句也不能被强化。假如两个表达式在两个查阅树中埋藏的很深不然，则那个查阅不可被采用，它是不可强化的。

假如可能将不然，把那个SQL句子合并为两个没有嵌套的SQL句子：

Set RS = DB.OpenRecordSet(“select * FROM Authors where Au_ID=1”)

对于更灵活的嵌套查阅，尽量在SQL句子中采用表头名，如：

DB.createQueryDef(“Query1”, _

“select IIF(Au_ID=1,’Hello’,’Goodbye’) AS X, Au_ID, FROM Authors”)

Set RS = DB.OpenRecordSet(“select * FROM Query1 where Au_ID=1”)

假如在查阅输入中实在无法防止排序式不然，尽量把排序式放在最外层，千万别放在最内层。

四、只输入须要的表头

在创建查阅的这时候，仅返回须要的表头，这种能节省不必要的开支。假如某个表头不是你须要的，千万别在查阅句子中出现。上面的事例正说明了那个难题。

五、分组、合并及汇总

这里要说明的主要是合并，当你须要把两个表合并，就是说：当你要根据“Customer Name”对两个表进行合并，要肯定GROUP BY field (Customer Name)和汇总(Sum, Count, and 等)的表头是来自同一张表。

例如：下列句子强化性较差，即使SUM子句来自Ord表，而GROUP BY子句来自Cust表：

select Cust.CustID,

FIRST(Cust.CustName) AS CustName,

SUM(Ord.Price) AS Total

FROM Cust INNER join Ord ON Cust.CustID = Ord.CustID

GROUP BY Cust.CustID

假如按照Ord.CustID分组，查阅性能就好的多了：

select Ord.CustID,

FIRST(Cust.CustName) AS CustName,

SUM(Ord.Price) AS Total

FROM Cust INNER join Ord ON Cust.CustID = Ord.CustID

GROUP BY Ord.CustID

六、尽量减少分组的表头

SQL句子中分组（GROUP BY）的表头越多，执行查阅的天数越长。在GROUP BY子句中尽量用aggregate函数来减少表头的数量。

如：

GROUP BY As Few Fields As Possible

select Cust.CustID,

Cust.CustName,

Cust.Phone,

SUM(Ord.Price) AS Total

FROM Cust INNER join Ord ON Cust.CustID = Ord.CustID

GROUP BY Cust.CustID, Cust.CustName,Cust.Phone

能改为：:

select Ord.CustID,

FIRST(Cust.CustName) AS CustName,

FIRST(Cust.Phone) AS Phone,

SUM(Ord.Price) AS Total

FROM Cust INNER join Ord ON Cust.CustID = Ord.CustID

GROUP BY Ord.CustID

七、在合并之前嵌套GROUP BY子句

假如要合并两张表，而且只在一张附注分组，把查阅分为两个select句子要快的多。

如：

select Ord.CustID,

FIRST(Cust.CustName) AS CustName,

FIRST(Cust.Phone) AS Phone,

SUM(Ord.Price) AS Total

FROM Cust INNER join Ord ON Cust.CustID = Ord.CustID

GROUP BY Ord.CustID

可改为：

查阅1:

select CustID, SUM(Price) AS Total

FROM Ord

GROUP BY CustID

查阅2:

select Query1.CustID, Cust.CustName, Cust.Phone, Query1.Total

FROM Cust INNER join Ord ON Cust.CustID = Ord.CustID

八、在合并的这时候两边的表头都增设检索

在合并表的这时候，尽量使两边的表头都增设检索。这在执行查阅的这时候查阅强化器能更多的采用sophisticated 内部合并策略。

当然，在关系型资料库中，表要结构设计的尽量小，（最好1-2K页），这种删除表的检索的这时候要快的多，这是即使缓存中读入了很少的页。这须要根据实际情况多次测试。

九、加进检索来提升查阅和排序的速率

为合并或查阅条件中的大部份采用表头创建检索。Microsoft Jet 2.0极其以后版本的资料库引擎采用采用了Rushmore查阅强化技术，因此支持一张表的复合检索。

要尽量减少在查阅条件中进行排序或在查阅条件中采用未索引的表头。排序更是如此，绝对要防止排序或采用未检索的表头。

十、采用可强化的表达式

再次构造查阅句子，以便于Rushmore技术能对其进行强化。Rushmore是一种统计数据访问技术，采用它能提升历史记录集的查阅速率。采用Rushmore的这时候，若在查阅条件中采用具体类别的表达式，查阅速率将非常快。Rushmore不会自动为你的查阅提升速率，你必须按照具体的方法修改查阅句子，以便于Rushmore能强化它。

十一、用COUNT(*)代替 COUNT([Column Name])

Microsoft Jet资料库引擎有特别的强化方法，它在采用COUNT(*)要比用COUNT([Column Name])快得多。

特别注意，这两个运算符是有差别的：

Count(*) 排序大部份的行。

Count([Column Name])排序大部份Column Name非空的行。

十二、在变量中防止采用like

由于在查阅完成的这时候变量的值不确定，所以无法采用检索，这种，创建的检索就失去了意义，这就严重制约着查阅速率。

十三、防止like和统配符与此同时采用

假如要把like运算符同统配符一起采用，为了采用检索，必须把统配符放在后面。

如，下列句子利用了检索。

like “Smith”

like “Sm*”