1 数据库优化：尝试将数据库表设计优化，包括索引和表结构。使用合适的索引可以加快数据查询的速度，而合理的表结构可以减少查询的开销。
2 缓存：使用缓存可以减少对数据库的查询次数。将热门数据缓存在内存中，可以直接从内存中读取数据，减少数据库的压力。
3 分页查询：将数据分页查询，一次只查询一部分数据，可以减少查询的开销。
4 升级硬件：如果您的服务器硬件配置比较低，可以考虑升级硬件，增加服务器的内存和CPU。
综上所述，卡顿问题可能是由于数据库查询效率低下导致的，可以通过数据库优化、缓存、分页查询和升级硬件等方式来解决。
我们在使用服务器时，有很多细节不注意就会使服务器遭受攻击，因此使用服务器租用服务，您需要进行一些设置，来防止最常见的安全威胁。
一、使用默认管理帐户
在Linux下，默认管理帐户是“root”，大多数Linux发行版在初始安装后都在使用，黑客通常将这个帐户作为暴力攻击的目标，以获得管理控制权。因此，root帐户应该被禁用。对于Windows，默认管理账户是“administrator”，也应禁用以减少攻击几率。
二、管理账户密码强度弱
这是最简单最基础的安全缺陷，但它值得需要被一遍又一遍的提及，因为每年都有数量庞大的服务器由于管理账户密码安全问题，导致被恶意入侵、数据泄露。
服务器租用时，默认密码通常简短且可预测。您应该保证您的管理帐户登录密码至少应包含大写字母、小写字母、数字和特殊符号。密码长度不能少于8个字符。避免使用连续性的英文单词或拼音作为密码。使用简单且简短的密码，可以使暴力破解密码的破解速度比一个高强度密码快得多。强密码是防止黑客入侵的第一道大门。
三、未更改Linux/Windows默认远程访问端口
黑客通常扫描默认的开放端口进行远程访问，以尝试暴力破解和其他漏洞尝试。对于Linux，SSH远程访问的默认端口是22，应该更改。Windows远程桌面访问的默认端口是3389，也应该更改。一定要记住更新任何防火墙规则，以免被黑客锁定目标。
四、未启用并锁定您的防火墙
很多服务商提供的默认Windows和Linux配置通常包括大量额外的软件，您可能永远不会使用，并可通过互联网访问。在许多情况下，这个软件通常可能存在您不知道的漏洞。最好的做法是关闭你未使用的任何端口，只保留使用服务器所需的端口。
在对Web服务器进行优化时要根据真实的Web应用系统的情况和特征来采取有针对性地优化方案。1根据不同的网络特性来看：
11局域网
在局域网中，降低M T U (最大传输单位)值对可以避免复制数据和要求校验，而通过优化select系统调用或在Socket事件处理器中执行计算可以优化请求并发管理，利用>A能耗的根源
云计算系统有几个不可或缺的部分。首先，它需要大量的硬件设备来存储并处理数据。这些硬件设备包括放置在机柜内的计算和存储服务器，以及处理器、内存、硬盘等服务器组件。其次，在服务器之间，服务器与用户之间需要连接，所以网络也必不可少，它是连接用户与计算、存储等云资源的桥梁。此外，数据中心还需要专门的软件来监控和管理云计算的基础设施，这些软件就是云管理系统（简称CMS）。最后，云服务商还需要安装合适的应用软件，帮助用户使用云服务。
这几个部分都需要消耗大量的能源，也都会损失和浪费很多能源，比如在夜间温度较低时，散热系统仍在全速运行，或者系统在运行，却没有为用户提供服务。2003年，单机柜服务器的功率密度在025千瓦到15千瓦之间，而到了2014年，这个数字上升至10千瓦，预计到2020年会上升至30千瓦。而且，大多数服务器空载时的功率超过峰值功率的50%，服务器的平均利用率一般只有10%到50%。因此，一部只以20%性能运行的服务器的能耗，可能相当于它满载时能耗的80%。考虑到仅在2013年最后一个季度，新服务器的出货量就超过250万台，提高服务器的能效就成为第一要务。
而在网络环节，主要有3个地方会消耗能源：数据中心内部的连接、不同数据中心间的网络连接，以及让外部用户访问的固定网络和无线网络。在目前的数据中心，网络成本占所有运营费用的10%，这个数字还可能随着互联网流量的增加上涨到50%。
如果服务器空载，就会耗费大量能源。如果网络架构不适合云应用，信息的传输途径也会发生改变，网络的某些部分就无法得到充分利用，能源浪费就会加剧。
由于信息技术的能耗越来越高，在数据中心的设备中，监控和管理云计算的基础设施就变得很重要，云管理系统的作用就是提高数据中心的能效。如果使用不当，云管理系统本身也会浪费能源。应用设备（如Java虚拟机）的运行通常都会产生日常能源消耗，如果应用设备性能不佳，就需要更多服务器，消耗更多的能源。
B硬件优化之路
提高能效的第一步是升级网络设备，增加节能模式，减少网络设施在未被充分使用时的耗电量。如果能把未使用的端口、连接和交换机完全关闭，它们就不会因为空转而耗能了。
升级后，设备的热载荷也会下降，这又会降低散热系统的能耗，提升系统的稳定性。不过，只调整网络设备是不够的，因为当网络连通性降低时，系统性能也会下降。所以，还需要调整网络结构，让网络流量可以沿着多个路径传播，或只通过少数几个高能耗的关键路径发送，而网络中的其他部分则进入低能耗模式。这种方案还可用于数据中心间的网络，充分挖掘网络带宽，因为批量传输所需的成本比单独传输要低。
除了降低数据传输的能耗，优化网络结构还可以降低基站的发射功率——基站是云端与终端之间传输信息的桥梁。连接手机的大型基站覆盖面积较大，基站和手机间的距离通常也很远，所以需要相当大的发射功率，才能保证大范围内的手机通信，但这样一来，能耗无疑很高。为了降低能耗，我们可以充分利用与用户更近的小型基站。现有的研究表明，在城市地区使用小型基站，可以使空载模式下的能耗降低至原来的1/46。
服务器和网络设备相似，如果可以根据负载自动调节功率和性能，就能降低能耗。今天的CPU、内存和硬盘都可以选择负载和空载两种模式，并相应调节电压和频率以降低能耗。为了延长硬盘空载时间，CPU会优先从缓存中读取信息，只有在缓存中找不到数据时，服务器才会访问硬盘。缓存本身也能优化甚至关掉部分未用缓存。最终，新的低功耗缓存技术可以和现有技术相结合，在保持性能的同时降低能耗。
服务器机柜的设计也会影响散热和供电的能效。研究人员发现，与使用机房空调相比，能对特定组件进行局部散热的服务器机柜有更好的节能效果。比如，通过一些特殊的冷却技术，可消除由处理器产生的热量。此外，还可以通过调节组件本身（比如调节内存数据吞吐量），避免热损失的发生。从供电环节开始限制能量输入，或对数据中心的能耗设置一个上限，也可以降低单一组件或整个服务器机架的能耗。最后，使用紧凑的服务器配置，直接去掉未使用的组件，也是减少能量损失的好办法。
C云管的秘密
使用云管理系统的主要目的，是对基础设施（包括服务器、虚拟机和应用程序）进行调度以实现负载平衡。虚拟机是体现云服务优越性的最佳范例，它借助软件模拟出计算机系统，具有硬件功能，可以在完全隔离的环境中运行。有几种虚拟机的使用方法能提高云计算的能效。首先，可以让虚拟机根据负载情况重新调配资源；其次，可以为虚拟机的布置选择能效最高的物理机；最后，可以将未充分利用的虚拟机迁移至数量更少的主机上，并把一直未使用的虚拟机关闭。
不过，这些步骤需要CPU软件功耗模式来实现。该模式下，软件和硬件彼此协调以共同调整能耗。而且，服务器本身也可以通过调整实际负载来降低能耗。研究表明，即便使用简单的试探法（比如在服务器持续空载一段时间后关闭服务器），也能节约大量能源。
下一步措施是在更宏观的范围内实施管理措施，比如合并多个数据中心。但是，这会增加虚拟机迁移所需的开销，在输入输出两端都要消耗能量。为了弄清楚合并数据中心能否提高能效，我们可以借助一些模拟工具，如CloudSim，它可以评估云计算管理系统消耗和节约的电量，并进一步比较服务质量的变化。显然，如果既能降低能耗，又不会影响用户使用云服务，这种合并就有利于降低云计算的能耗。云管理系统不仅可以控制服务器，还可以控制网络系统，甚至控制散热和供电，因为云管理系统“知道” 需要哪些资源，不需要哪些资源，因此可以选择合适的虚拟技术，并在服务器空载时关闭散热设备。
云管理系统的建立方式也很重要，采用模块化方式来建立云管理系统就很有优势，因为这允许技术人员在实际需要某个模块时加载相应模块。比如，在需要监控某些特定组件时，技术人员可以在原有系统中添加某些插件；而在不需要监控这些组件时，技术人员也可以终止运行这些插件。
同时，研究人员也在开发高能效的软件，降低应用程序在空载状态下的能耗。比如，限制用户远程唤醒服务器可以延长空载状态时间，尽量向用户发送消息而非让用户或客户端向云服务器主动发起请求，可以让软件在真正需要其运行之前保持休眠，对资源（如磁盘）的批量访问也可以减少不必要的唤醒。
不在现实世界部署高能效方案并没有看上去那么简单。服务器组件的低能耗模式只有在服务器长期空载的情况下才有益处，而这种情况在实际使用中并不常见。而且，尽管服务器在执行轻量级任务时的使用率很低，但为了满足访问高峰时的需求，仍有必要保持适当的“d性”。因此，可自我扩展的服务器组件必须与软件组件相关联，否则调节CPU模式的技术会被错误应用，导致CPU运行频率过低，应用程序的运行时间变长，最终导致CPU的整体能耗上升。另一个目标是让空载组件的能耗接近于零，这可以通过合并未充分利用的服务器来实现。
D治标又治本——整体解决方案
为云计算提供支持的数据中心是一套高度耦合的系统，几乎可以视作一台大型计算机。因此，除了从数据中心的每个部分着手，降低能耗之外，还得把整个数据中心视作一个整体，分析各个基础设施之间的相关性，进而寻找节能方案。
应用设备是云计算中可管理的最小单位，但它们的性能可以影响所需服务器的数量，从而产生多米诺效应，进一步影响网络规模和支持性的设备——比如散热和供电设备的数量。因此，为目标应用程序选择适当的硬件资源，可能会对数据中心的总体能耗产生重大影响。这里的实例包括，用GPU而不是CPU运行可以高度并行的应用程序（有些程序可以在成千上万个处理器上同时运行，节省运算时间）。和CPU相比，GPU上的计算单元非常密集，可以同时执行很多任务，更适合并行计算，同时能耗更低。
但是，使用新的硬件需要对应用程序进行更深的研究和更细致的分级，在特定的应用程序和潜在的硬件资源之间建立联系。云计算的实现需要多种基础设施的协同，这又需要建立一个灵活、全面、监控能力出色的云管理系统。作为最基本的要求，云管理系统必须要监测数据中心中正在运行的进程、硬件性能、运行状态、数据规模等多种信息。管理系统还要对分布在不同地理位置的数据系统进行优化，让不同的云设施合并。这些方法既需要单个数据中心中的软件和硬件实现良好的交互，也需要让全球各地的数据中心互换信息、负载和数据。
要实现这些目标还是要依靠网络，利用网络可以把计算资源和数据存储资源放在可以利用可再生能源或凉爽的地方，降低散热产生的能耗。当然，优化网络设备的同时也需要改进其他设备和组件。比如，数据和处理器距离用户很远且分布不均，会导致云服务的性能大打折扣，而采用好的设备和云管理系统能降低网络流量，也就可以解决这个问题。除了改进数据中心，将数据中心整合到云计算概念里能在更大规模上提升能效。1 使用SET NOCOUNT ON 选项：
缺省地，每次执行SQL语句时，一个消息会从服务端发给客户端以显示SQL语句影响的行数。这些信息对客户端来说很少有用。通过关闭这个缺省值，你能减少在服务端和客户端的网络流量，帮助全面提升服务器和应用程序的性能。为了关闭存储过程级的这个特点，在每个存储过程的开头
包含“SET NOCOUNT ON”语句。
2 正确使用UNION和UNION ALL：
许多人没完全理解UNION和UNION SELECT是怎样工作的，因此，结果浪费了大量不必要的SQLServer资源。当使用UNION时，它相当于在结果集上执行SELECT DISTINCT。换句话说，UNION将联合两个相类似的记录集，然后搜索重复的记录并排除。如果这是你的目的，那么使用UNION是正
确的。但如果你使用UNION联合的两个记录集没有重复记录，那么使用UNION会浪费资源，因为它要寻找重复记录，即使你确定它们不存在。
所以如果你知道你要联合的记录集里没有重复，那么你要使用UNION ALL，而不是UNION。UNION ALL联合记录集，但不搜索重复记录，这样减少SQLServer资源的使用，从而提升性能。
3 尽量不用SELECT ：
绝大多数情况下，不要用 来代替查询返回的字段列表，用 的好处是代码量少、就算是表结构或视图的列发生变化，编写的查询SQL语句也不用变，都返回所有的字段。但数据库服务器在解析时，如果碰到 ，则会先分析表的结构，然后把表的所有字段名再罗列出来。这就增加了
分析的时间。
4 慎用SELECT DISTINCT：
DISTINCT子句仅在特定功能的时候使用，即从记录集中排除重复记录的时候。这是因为DISTINCT子句先获取结果集然后去重，这样增加SQLServer有用资源的使用。当然，如果你需要去做，那就只有去做了。
当如果你知道SELECT语句将从不返回重复记录，那么使用DISTINCT语句对SQLServer资源不必要的浪费。
5 少用游标：
任何一种游标都会降低SQLServer性能。有些情况不能避免，大多数情况可以避免。所以如果你的应用程序目前正在使用TSQL游标，看看这些代码是否能够重写以避免它们。如果你需要一行一行的执行 *** 作，考虑下边这些选项中的一个或多个来代替游标的使用：
使用临时表
使用WHILE循环
使用派生表
使用相关子查询
使用CASE语句
使用多个查询
上面每一个都能取代游标并且执行更快。 如果你不能避免使用游标，至少试着提高它们的速度，找出加速游标的方法。
6 选择最有效率的表名顺序：
SQLSERVER的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表（基础表driving table）将被最先处理，在FROM子句中包含多个表的情况下，必须选择记录条数最少的表作为基础表，当SQLSERVER处理多个表时，会运用排序及合并的方式连接它们。首先
，扫描第一个表（FROM子句中最后的那个表)并对记录进行排序；然后扫描第二个表（FROM子句中最后第二个表)；最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。
例如: 表 TAB1有 16384 条记录，表 TAB2 有5条记录，选择TAB2作为基础表 (最好的方法)：
select count() from TAB1 a, TAB2 b
选择TAB1作为基础表 (不佳的方法)：
select count() from TAB2 a, TAB1 b
如果有3个以上的表连接查询，那就需要选择交叉表（intersection table）作为基础表，交叉表是指那个被其他表所引用的表。
7 使用表的别名(Alias)：
当在SQL语句中连接多个表时，请使用表的别名并把别名前缀于每个Column上，这样可以减少解析的时间并减少那些由Column歧义引起的语法错误。
8 SARG你的WHERE条件：
ARGE来源于"Search Argument"（搜索参数）的首字母拼成的"SARG"，它是指WHERE子句里，列和常量的比较。如果WHERE子句是sargable（可SARG的），这意味着它能利用索引加速查询的完成。如果WHERE子句不是可SARG的，这意味着WHERE子句不能利用索引（或至少部分不能利用），
执行的是全表或索引扫描，这会引起查询的性能下降。
在WHERE子句里不可SARG的搜索条件如"IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE"和"LIKE '%500'"，通常（但不总是）会阻止查询优化器使用索引执行搜索。另外在列上使用包括函数的表达式、两边都使用相同列的表达式、或和一个列（不是常
量）比较的表达式，都是不可SARG的。
并不是每一个不可SARG的WHERE子句都注定要全表扫描。如果WHERE子句包括两个可SARG和一个不可SARG的子句，那么至少可SARG的子句能使用索引（如果存在的话）帮助快速访问数据。
大多数情况下，如果表上有包括查询里所有SELECT、JOIN、WHERE子句用到的列的覆盖索引，那么覆盖索引能够代替全表扫描去返回查询的数据，即使它有不可SARG的WHERE子句。但记住覆盖索引尤其自身的缺陷，如此经常产生宽索引会增加读磁盘I/O。某些情况下，可以把不可SARG的WHER
E子句重写成可SARG的子句。例如：
WHERE SUBSTRING(firstname,1,1) = 'm'
可以写成：
WHERE firstname like 'm%'
这两个WHERE子句有相同的结果，但第一个是不可SARG的（因为使用了函数）将运行得慢些，而第二个是可SARG的，将运行得快些。
如果你不知道特定的WHERE子句是不是可SARG的，在查询分析器里检查查询执行计划。这样做，你能很快的知道查询是使用了索引还是全表扫描来返回的数据。仔细分析，许多不可SARG的查询能写成可SARG的查询。下面分几点讲解WHERE条件的SARG。
81 WHERE子句中的连接顺序
SQLSERVER采用自下而上的顺序解析WHERE子句，根据这个原理，表之间的连接必须写在其他WHERE条件之前，那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。例如：
(低效)
SELECT FROM EMP E
WHERE SAL > 50000
AND JOB = ‘MANAGER’
AND 25 < (SELECT COUNT() FROM EMP WHERE MGR=EEMPNO)
(高效)
SELECT FROM EMP E
WHERE 25 < (SELECT COUNT() FROM EMP WHERE MGR=EEMPNO)
AND SAL > 50000
AND JOB = ‘MANAGER’
82 避免困难的正规表达式：
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：
SELECT FROM customer WHERE zipcode LIKE "98_ _ _"
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT FROM customer WHERE zipcode >="98000"，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：
SELECT FROM customer WHERE zipcode[2，3] >"80"
在where子句中采用了非开始子串，因而这个语句也不会使用索引。
83 避免对大型表行数据的顺序存取：
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（
学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序 *** 作：
SELECT FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT FROM orders WHERE customer_num=104 AND order_num>1001
UNION ALL
SELECT FROM orders WHERE order_num=1008
这样就能利用索引路径处理查询。
84 EXISTS和IN的使用：
在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接。 在这种情况下，使用EXISTS(或NOT EXISTS)通常将提高查询的效率。在子查询中，NOT IN子句将执行一个内部的排序和合并。无论在哪种情况下，NOT IN都是最低效的，因为它对子查询中的表执行
了一个全表遍历。为了避免使用NOT IN，我们可以把它改写成外连接(Outer Joins)或NOT EXISTS。
85 避免在索引列上使用IS NULL和IS NOT NULL：
避免在索引中使用任何可以为空的列，SQLSERVER将无法使用该索引。对于单列索引，如果列包含空值，索引中将不存在此记录；对于复合索引，如果每个列都为空，索引中同样不存在此记录。如果至少有一个列不为空，则记录存在于索引中。
如果唯一性索引建立在表的A列和B列上，并且表中存在一条记录的A,B值为(123,null)，SQLSERVER将不接受下一条具有相同A,B值（123,null）的记录插入。
如果所有的索引列都为空，SQLSERVER将认为整个键值为空，而空不可能等于空，因此你可以插入1000条具有相同键值的记录，当然它们都是空！因为空值不存在于索引列中，所以WHERE子句中对索引列进行空值比较将使SQLSERVER停用该索引。下面的代码将会很低效（索引失效）：
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL
86 避免在索引列上使用计算：
WHERE子句中，如果索引列是函数的一部分，优化器将不使用索引而使用全表扫描。 例如下面的语句低效 ：
SELECT … FROM DEPT WHERE SAL 12 > 25000
而下面的语句将是高效的：
SELECT … FROM DEPT WHERE SAL > 25000/12
请务必注意，查询中不要对索引列进行处理，如：TRIM，substring，convert等等 *** 作。
87 用WHERE子句替换HAVING子句：
避免使用HAVING子句，HAVING只会在检索出所有记录之后才对结果集进行过滤，这个处理需要排序、统计等 *** 作。如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销。
9 避免或简化排序：
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
l 索引中不包括一个或几个待排序的列；
l group by或order by子句中列的次序与索引的次序不一样；
l 排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
10 临时表的使用：
临时表有很多特殊的用途，象用来替代游标，不过它们仍能引起性能问题，如果这个问题能消除，SQLServer将执行得更快。在永久表和临时表的数据行相同的条件下，使用临时表没有永久表快。但有时还必须得使用临时表，如先从存储大量数据的永久表中提取符全条件的存放到临时
表，然后在临时表上执行 *** 作。如果是直接在存储大量数据的永久表上执行 *** 作（如：统计、循环等），其性能将大打折扣。所以，使不使用临时表，何时使用临时表，需要具体情况决定。
11 是否使用视图：
视图最大的用途是处理安全相关的问题，而不是一些懒惰的开发人员用来存储经常使用的查询的方法。例如，如果你需要允许用户访问特定SQLServer的数据，那么你也许可以考虑为用户（或组）创建一个视图，然后给用户访问视图而不是基表的权限。另一方面，在应用程序里，从视图选
择数据没有好的理由，相反，绕过视图直接从需要的表里获取数据。原因是许多视图（当然不是全部）返回比SELECT语句所需更多的数据，增加不必要的开销。
例如，假定有一个视图从两个连接表里返回10列。你想要从视图里使用SELECT语句返回其中7列。实际上发生的情况是基于视图的查询先运行，返回数据，然后你的查询针对这些数据运行。既然你仅需要7列，而不是视图返回的10列，更多不必要的数据被返回。浪费SQLServer的资源。
长久以来，大家在争论是查询视图速度快还是直接查询快，本人也不敢轻易下结论，因此作了多次试验，其结果是：基于视图查询，性能确实不会比直接写查询语句快，对于简单的查询，最多是在同一水平上。
当然，上面的测试是在没有为视图创建索引的情况下，SQLServer2000以上可以为视图创建索引，视图索引与表的索引在作用方式上非常相似。与表一样，视图可以有一个集簇索引（clustered index）和多个非集簇索引。创建视图索引后能够提高视图的性能。
如果视图不包含索引，则数据库中不保存视图返回的结果集。有的时候，我们可能要创建涉及大量记录或必须进行复杂计算的视图，比如要进行聚合分组处理或多重连接 *** 作。如果每次引用这些视图的时候让sql server重新生成结果集，数据库开销将非常大。
12 让事务尽可能的短：
保持TSQL事务尽可能的短。这会帮助减少锁（所有类型的锁）的数量，有助于全面提升SQLServer的性能。如果有经验，你也许要将长事务分成更小的事务组。
13 用存储过程代替直接写查询语句：
存储过程为开发人员提供了很多好处，包括：
n 减少网络流量和响应时间，提升应用程序性能。例如，通过网络发送一个存储过程调用，而不是发送500行的TSQL将更快，资源使用更少。当每次执行SQL时，都会执行解析SQL语句、估算索引的利用率、绑定变量、读数据块等等工作。
n 存储过程执行计划能够重用，驻留在SQLServer内存的缓存里，减少服务器开销。
n 客户端执行请求更有效率。例如，如果应用程序需要插入大量的二进制值到一个image数据列而不使用存储过程，它必须转化二进制为字符串（大小会增加一倍），然后发送给SQLServer。当SQLServer接收到后，它必须把字符串值转回二进制格式。大量的浪费开销。存储过程能
消除这个问题通过将应用程序传给SQLServer的二进制格式作为参数，从而减少开销提升性能。
n 存储过程帮助提供代码重用。虽然这些不直接提升应用程序的性能，通过减少代码量和减少调试时间来提升开发人员的效率。
n 存储过程能封装逻辑。你能够改变存储过程代码而不影响客户端（假定你保持参数相同也不移除任何结果集的列）。这节约开发人员的时间。
n 存储过程为你的数据提供更好的安全性。如果你仅使用存储过程，你可以移除直接对表的SELECT、INSERT、UPDATE和DELETE权限从而强迫开发人员使用存储过程访问数据。这会节约DBA的时间。
n 作为首要的常规，所有的TSQL代码都应该通过存储过程调用。
131 存储过程名不要以 sp_ 开头：
对这一准则，可能很多人会感觉纳闷，是的，我开始也纳闷过。如果创建的存储过程不是运行在Master数据库里，不要使用以sp_为前缀的名称。这个特别的前缀是为系统存储过程保留的。尽管使用这个前缀不会禁止用户定义的存储过程的运行，但会稍微降低一些执行效率。这是因为
SQLServer在执行以sp_为前缀的任何一个存储过程时缺省地首先试图在Master数据库里寻找，尽管那儿没有，这就浪费了寻找存储过程的时间。如果SQLServer在Master数据库里不能找到存储过程，那么接下来会将存储过程的拥有者作为DBO去解析。如果存储过程在目前的数据库里，那么
它会执行。为了避免不必要的延迟，不要用前缀为sp_命名你的任何一个存储过程。
132 存储过程的拥有者要相同：
为了最好的性能，同一个存储过程里调用的所有对象的拥有者都应该相同，DBO更适宜。如果不是那样，即对象名相同而拥有者不同，那么SQLServer必须执行名称判断。当发生这样的情形时，SQLServer不能使用存储过程里在内存里的执行计划，相反，它必须重新编译存储过程，从而
影响性能。当从应用程序里调用存储过程时，使用分隔符名称来调用也是重要的。如：
EXEC dbomyProcedure
代替：
EXEC myProcedure
这样做有两个原因，其中一个和性能有关。首先，使用完全有分隔符的名称有助于消除那些和你要运行的存储过程有潜在的混淆，有助于禁止BUG和潜在的问题。但更重要的是，这样做SQLServer能更直接的访问存储过程执行计划，而不是轮流访问，从而加速了存储过程的性能。当然性能
提升很小，但如果你的服务器每小时要运行成千上万或更多的存储过程，这些节约的小段时间加起来就很可观了。
14 完整性使用下的约束和触发器：
数据库里不要执行多余的完整性特点。例如，如果你正使用主键和外键约束来强迫引用完整性，则不要添加触发器来实现相同的功能而增加不必要的开销。同样既使用约束又使用默认值或既使用约束又使用规则也会执行多余的工作。
15 在SQL中捕捉异常：
这一条准则应该不能算是优化方面的，只是编写要求。现在SQLServer2005中，新增了BEGIN TRY…END TRY和 BEGIN CATCH…END CATCH二个成对语句，用于捕捉运行时出现的异常。在Oracle中，可用 BEGIN…EXCEPTION…END 语句捕捉异常。
把SQL代码块中加入捕捉异常的语句内，有二个好处：一是可以在SQL语句内部得到异常并作错误处理，如在错误代码块内返回自定义错误信息、ROLBACK等。这样可减少应用程序捕捉异常带来的资源开销；另外一个好处就是可以防止死锁情况的发生，当出现死锁时，SQLServer2005会抛出
异常，我们就可捕捉到。
下面列出一些索引的概念，有助于设计表结构和编写SQL语句：
按照存储规则来分：
l 聚集索引：该索引中键值的逻辑顺序决定了表中相应行的物理顺序。因此一个表只能包含一个聚集索引，但该索引可以包含多个列（组合索引）。检索效率比普通索引高，但对数据新增/修改/删除的影响比较大。
l 非聚集索引：与聚集索引相对，不影响表中的数据存储顺序，检索效率比聚集索引低，对数据新增/修改/删除的影响很少。
按照维护与管理的角度来分：
l 唯一索引：惟一索引可以确保索引列不包含重复的值，可以用多个列，但是索引可以确保索引列中每个值组合都是唯一的。
l 主键索引：在数据库关系图中为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的。当在查询中使用主键索引时，它还允许快速访问数据。
l 普通索引：由关键字KEY或INDEX定义的索引，唯一任务是加快对数据的访问速度。因此，应该只为那些最经常出现在查询条件或排序条件中的数据列创建索引。只要有可能，就应该选择一个数据最整齐、最紧凑的数据列(如整数类型的数据列)来创建索引。允许有重复的列存在
。
l 复合索引：如果在两上以上的列上创建的索引，则称为复合索引。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）