一、数据库布局的设计
假如不能设计一个公道的数据库模子，不只会增加客户端和处事器段措施的编程和维护的难度，并且将会影响系统实际运行的机能。所以，在一个系统开始实施之前，完备的数据库模子的设计是必需的。
在一个系统阐明、设计阶段，因为数据量较小，负荷较低。我们往往只留意到成果的实现，而很难留意到机能的单薄之处，比及系统投入实际运行一段时间后，才发明系统的机能在低落，这时再来思量提高系统机能则要耗费更多的人力物力，而整个系统也不行制止的形成了一个打补丁工程。
所以在思量整个系统的流程的时候，我们必需要思量，在高并发大数据量的会见环境下，我们的系统会不会呈现极度的环境。（譬喻：对外统计系统在7月16日呈现的数据异常的环境，并发大数据量的的会见造成，数据库的响应时间不能跟上数据刷新的速度造成。详细环境是：在日期临界时（00：00：00），判定数据库中是否有当前日期的记录，没有则插入一条当前日期的记录。在低并发会见的环境下，不会产生问题，可是当日期临界时的会见量相当大的时候，在做这一判定的时候，会呈现多次条件创立，则数据库里会被插入多条当前日期的记录，从而造成数据错误。），数据库的模子确定下来之后，我们有须要做一个系统内数据流向图，阐明大概呈现的瓶颈。
为了担保数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽大概的低落数据的冗余。（譬喻用户表的地域，我们可以把地域别的存放到一个地域表中）假如数据冗余低，数据的完整性容易获得担保，提高了数据吞吐速度，担保了数据的完整性，清楚地表达数据元素之间的干系。而对付多表之间的关联查询（尤其是大数据表）时，其机能将会低落，同时也提高了客户端措施的编程难度，因此，物理设计需折衷思量，按照业务法则，确定对关联表的数据量巨细、数据项的会见频度，对此类数据表频繁的关联查询应适当提高数据冗余设计但增加了表间毗连查询的操纵，也使得措施的变得巨大，为了提高系统的响应时间，公道的数据冗余也是须要的。设计人员在设计阶段应按照系统操纵的范例、频度加以平衡思量。
别的，最好不要用自增属性字段作为主键与子表关联。未便于系统的迁移和数据规复。对外统计系统映射干系丢失（******************）。
本来的表格必需可以通过由它疏散出去的表格从头构建。利用这个划定的长处是，你可以确保不会在疏散的表格中引入多余的列，所有你建设的表格布局都与它们的实际需要一样大。应用这条划定是一个好习惯，不外除非你要处理惩罚一个很是大型的数据，不然你将不需要用到它。（譬喻一个通行证系统，我可以将USERID，USERNAME，USERPASSWORD，单独出来作个表，再把USERID作为其他表的外键）
表的设计详细留意的问题：
1、数据行的长度不要高出8020字节，假如高出这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，低落查询效率。
2、可以或许用数字范例的字段只管选择数字范例而不消字符串范例的（电话号码），这会低落查询和毗连的机能，并会增加存储开销。这是因为引擎在处理惩罚查询和毗连回逐个较量字符串中每一个字符，而对付数字型而言只需要较量一次就够了。
3、对付不行变字符范例char和可变字符范例varchar 都是8000字节,char查询快，可是耗存储空间，varchar查询相对慢一些可是节减存储空间。在设计字段的时候可以机动选择，譬喻用户名、暗码等长度变革不大的字段可以选择CHAR，对付评论等长度变革大的字段可以选择VARCHAR。
4、字段的长度在最大限度的满意大概的需要的前提下，应该尽大概的设得短一些，这样可以提高查询的效率，并且在成立索引的时候也可以淘汰资源的耗损。
二、查询的优化
担保在实现成果的基本上，只管淘汰对数据库的会见次数；通过搜索参数，只管淘汰对表的会见行数,最小化功效集，从而减轻网络承担；可以或许分隔的操纵只管分隔处理惩罚，提高每次的响应速度；在数据窗口利用SQL时，只管把利用的索引放在选择的首列；算法的布局只管简朴；在查询时，不要过多地利用通配符如SELECT * FROM T1语句，要用到几列就选择几列如：SELECT COL1,COL2 FROM T1；在大概的环境下只管限制只管功效集行数如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些环境下用户是不需要那么多的数据的。
在没有建索引的环境下，数据库查找某一条数据，就必需举办全表扫描了，对所有数据举办一次遍历，查找出切合条件的记录。在数据量较量小的环境下，也许看不出明明的不同，可是当数据量大的环境下，这种环境就是极为糟糕的了。
SQL语句在SQL SERVER中是如何执行的，他们担忧本身所写的SQL语句会被SQL SERVER误解。好比：
select * from table1 where and tID > 10000
和执行:
select * from table1 where tID > 10000 and
一些人不知道以上两条语句的执行效率是否一样，因为假如简朴的从语句先后上看，这两个语句简直是纷歧样，假如tID是一个聚合索引，那么后一句仅仅从表的10000条今后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，尔后再按照限制条件条件tID>10000来提出查询功效。
事实上，这样的担忧是不须要的。SQL SERVER中有一个“查询阐明优化器”，它可以计较出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。固然查询优化器可以按照where子句自动的举办查询优化，但有时查询优化器就会不凭据您的本意举办快速查询。
在查询阐明阶段，查询优化器查察查询的每个阶段并抉择限制需要扫描的数据量是否有用。假如一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，而且可以操作索引快速得到所需数据。
SARG的界说：用于限制搜索的一个操纵，因为它凡是是指一个特定的匹配，一个值的范畴内的匹配可能两个以上条件的AND毗连。形式如下：
列名 操纵符 <常数 或 变量> 或 <常数 或 变量> 操纵符 列名
列名可以呈此刻操纵符的一边，而常数或变量呈此刻操纵符的另一边。如：
Name=’张三’
价值>5000
5000<价值
Name=’张三’ and 价值>5000
假如一个表达式不能满意SARG的形式，那它就无法限制搜索的范畴了，也就是SQL SERVER必需对每一行都判定它是否满意WHERE子句中的所有条件。所以一个索引对付不满意SARG形式的表达式来说是无用的。
所以，优化查询最重要的就是，只管使语句切合查询优化器的法则制止全表扫描而利用索引查询。
详细要留意的：
