提高网站的访问速度、安全、扩展性方面问题

来源:互联网 发布:mac怎么显示图片尺寸 编辑:程序博客网 时间:2024/06/05 08:54

--提高网站的访问速度和安全方面问题
  提高系统数据库访问性能主要体现在:外围:网络,硬件、数据库参数设置;
   应用程序:源代码和sql语句
    sql语句的优化主要在于:数据库表的设计,表的主键,索引的建立,数据库表 字段的类型的长度;
    sql语句的查询尽量避免查询出不需要的字段,查询条件设置在外层,避免LIKE和统配符同时使用
    源代码提高性能:对于变量的使用完后要销毁对象,变长和定长字符串、减少模块的数量、减少循环的次数;减少变量空间的定义;


  1、生成静态页
  2、如果数据库较大的话要考虑数据库表的设计,简历是适当索引
一、表的设计
当在表中添加字段的时候,应该选择长度最小的数据类型,这样表在内存中每页可以存储更多的记
录。如:“姓名”字段一般设置为TEXT类型,长度为10一般就够用,则比默认的255要好的多。整
型Integer的长度是2,在使用整型Integer就可以解决问题的地方不要使用Single、Long、
Double、Currency,因为它们的长度分别为4、4、8、8,都比2大。在建立表后一定要建立
索引,这可以大大提高查询速度,是提高速度最基本的要求。
二、压缩数据库
JET数据库的查询优化是有代价的,随着数据库的不断扩大,优化将不再起作用。压缩数据库会改
变数据库的状态,并重新优化所有查询。同时,随着数据库的增大,会产生很多碎片。而压缩数据
库可以把一个表中的数据数据写到硬盘中连续的页里,提高了顺序搜索的速度。
压缩数据库使用CompactDatabase命令,下面的语句压缩数据库并产生一个数据库备份:
DBEngine.CompactDatabase “C:\VB\BIBLIO.MDB”, “C:\VB\BIBLIO2.MDB”
   Kill “C:\VB\BIBLIO.BAK”   Name “C:\VB\BIBLIO.MDB” As “C:\VB\BIBLIO.BAK”
   Name “C:\VB\BIBLIO2.MDB” As “C:\VB\BIBLIO.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*"
而下列语句根本没有使用索引:
   Like "*sen"
   Like "*sen*"
十四、测试合并约束
如果要在合并中使用表达式约束一个字段的数值,需要测试表达式放在合并的一侧,还是其他地
方,看哪种查询的速度较快。在一些查询中,表达式放在合并关键词join一侧反而比较快。
十五、使用中间结果表
用SELECT INTO建立工作表,尤其是结果集用于几个查询的时候,尽量使用中间结果表。在查询前
做的准备工作越多,查询速度越快。
十六、避免子SELECT语句和NOT IN同时使用
子SELECT语句和NOT IN同时使用很难优化,取反嵌套的查询或OUTER JOINs影响很大。
下列事例查询不在orders表中的用户:
优化前:
      SELECT Customers.*
      FROM Customers
      WHERE Customers.[Customer ID]
            NOT IN (SELECT [Customer ID] FROM Orders);
优化后:
      SELECT Customers.*
      FROM Customers LEFT JOIN Orders
           ON Customers.[Customer ID] = Orders.[Customer ID]
      WHERE ((Orders.[Customer ID] Is Null));

 

 

 

 

--扩展性

 

可扩展性有时被定义成“具备可扩展性的系统或组件,可以很容易被修改以适用于问题域”。这个定义非常模糊,让人困惑。其实可扩展性很容易定义。一个可扩展的系统有三个简单特性:
 
1.系统能够容纳使用率的增加
 
2.系统能够容纳数据集的增加
 
3.系统可维护
 
      在深入这些具体条目之前,先谈谈可扩展性不是什么,消除在当前Web开发中常见的一些谬误。
 
可扩展性不是指原始速度。性能和可扩展性是不同的问题。你很容易就可以有一个不可扩展的高性能系统,虽然反过来的情况并不常见——一个系统可以扩展,那么你总能通过扩展它来提高性能。一个系统在1000个用户和1 GB数据的情况下非常快,并不意味着它是可扩展的,除非它能够在10倍当前用户和10倍当前数据的情况下仍然保持现在的速度。
 
      可扩展性跟用不用Java无关。用任何语言任何工具构建的系统都能变得可扩展,虽然不同语言和工具造成的相对难度肯定会是个问题。Java近来和可扩展性走得如此之近,以至于很多人把两者当成是相同的。再重复一次:不用Java就可以构建一个可扩展的应用程序。类似的,编译语言不是设计可扩展系统的必要条件。本地代码,即时编译,和编译过的字节码虚拟机能做到又好又快,但那是性能问题,而不是可扩展性的问题。不管怎么说,这一段可不是专门为了打压Java的。使用Java来创建可扩展的应用程序完全是可能的,只是说具体实施语言和系统的可扩展性之间的关系很小。
 
      实际上,可扩展性跟使用特定的技术完全无关。另一个常见的误解是XML是可扩展性的核心——这完全是胡说。XML对互操作性很有用,但互操作性和可扩展性两者不是一回事。你可以拥有既不读也不写XML的可扩展的程序。在James Clark想出这个特别的缩写之前,可扩展的系统早就存在很久了

原创粉丝点击