MSSQL编程：关于SQL Server的多少注重事项

每个Rows_log_event中包含event_type,可选值为WRITE_ROWS_EVENT、UPDATE_ROWS_EVENT、DELETE_ROWS_EVENT。从宏名字就能看出用途。server
关于SQLServer的多少注重事项

假如你正在卖力一个基于SQLServer的项目，大概你方才打仗SQLServer，你都有大概要面对一些数据库功能的成绩，这篇文章会为你供应一些有效的引导（个中年夜多半也能够用于别的的DBMS）。

在这里，我不盘算先容利用SQLServer的秘诀，也不克不及供应一个包治百病的计划，我所做的是总结一些履历----关于怎样构成一个好的计划。这些履历来自我已往几年中承受的教导，一向来，我看到很多一样的计划毛病被一次又一次的反复。

你懂得你的工具吗？

不要不放在眼里这一点，这是我在这篇文章中报告的最关头的一条。大概你也看到有良多的SQLServer程序员没有把握全体的T-SQL命令和SQLServer供应的那些有效的工具。

“甚么？我要华侈一个月的工夫来进修那些我永久也不会用到的SQL命令？？？”，你大概会如许说。对的，你不必要如许做。可是你应当用一个周末扫瞄一切的T-SQL命令。在这里，你的义务是懂得，未来，当你计划一个查询时，你会记起来：“对了，这里有一个命令能够完整完成我必要的功效”，因而，到MSDN检察这个命令切实其实切语法。

不要利用游标

让我再反复一遍：不要利用游标。假如你想损坏全部体系的功能的话，它们却是你最无效的首选举措。年夜多半的初学者都利用游标，而没无意识到它们对功能酿成的影响。它们占用内存，还用它们那些难以想象的体例锁定表，别的，它们几乎就像蜗牛。而最糟的是，它们可使你的DBA所能做的统统功能优化即是没做。不知你是不是晓得每实行一次FETCH就即是实行一次SELECT命令？这意味着假如你的游标有10000笔记录，它将实行10000次SELECT！假如你利用一组SELECT、UPDATE大概DELETE来完成响应的事情，那将无效率的多。

初学者一样平常以为利用游标是一种对照熟习和温馨的编程体例，可很不幸，这会招致糟的功能。明显，SQL的整体目标是你要完成甚么，而不是如何完成。

我已经用T-SQL重写了一个基于游标的存储历程，谁人表只要100,000笔记录，本来的存储历程用了40分钟才实行终了，而新的存储历程只用了10秒钟。在这里，我想你应当能够看到一个不称职的程序员事实在干了甚么！！！

我们能够写一个小程序来获得和处置数据而且更新数据库，如许做偶然会更无效。记着：关于轮回，T-SQL力所不及。

我再从头提示一下：利用游标没有优点。除DBA的事情外，我历来没有看到过利用游标能够无效的完成任何事情。

标准化你的数据表

为何不标准化数据库？也许有两个托言：出于功能的思索和地道由于怠惰。至于第二点，你早晚得为此支付价值。而关于功能的成绩，你不必要优化基本就不慢的器材。我常常看到一些程序员“反标准化”数据库，他们的来由是“本来的计划太慢了”，可了局却经常是他们让体系更慢了。DBMS被计划用来处置标准数据库的，因而，记着：依照标准化的请求计划数据库。

不要利用SELECT*

这点不太简单做到，我太懂得了，由于我本人就常常如许干。但是，假如在SELECT中指定你所必要的列，那将会带来以下的优点：

1削减内存泯灭和收集的带宽

2你能够失掉更平安的计划

3给查询优化器时机从索引读取一切必要的列

懂得你将要对数据举行的操纵

为你的数据库创立一个强健的索引，那但是好事一件。可要做到这一点几乎就是一门艺术。每当你为一个表增加一个索引，SELECT会更快了，可INSERT和DELETE却年夜年夜的变慢了，由于创立了保护索引必要很多分外的事情。明显，这里成绩的关头是：你要对这张表举行甚么样的操纵。这个成绩不太好掌控，出格是触及DELETE和UPDATE时，由于这些语句常常在WHERE部分包括SELECT命令。

不要给“性别”列创立索引

起首，我们必需懂得索引是怎样减速对表的会见的。你能够将索引了解为基于必定的尺度上对表举行分别的一种体例。假如你给相似于“性别”如许的列创立了一个索引，你仅仅是将表分别为两部分：男和女。你在处置一个有1,000,000笔记录的表，如许的分别有甚么意义？记着：保护索引是对照费时的。当你计划索引时，请遵守如许的划定规矩：依据列大概包括分歧内容的数量从多到少分列，好比：姓名+省分+性别。

利用事件

请利用事件，出格是当查询对照耗时。假如体系呈现成绩，如许做会救你一命的。一样平常有些履历的程序员都有体味-----你常常会碰着一些不成意料的情形会招致存储历程溃散。

当心逝世锁

依照必定的序次来会见你的表。假如你先锁住表A，再锁住表B，那末在一切的存储过程当中都要依照这个按次来锁定它们。假如你（不经意的）某个存储过程当中先锁定表B，再锁定表A，这大概就会招致一个逝世锁。假如锁定按次没有被事后具体的计划好，逝世锁是不太简单被发明的。

不要翻开年夜的数据集

在CSDN手艺论坛中:），一个常常被提出的成绩是：我如何才干敏捷的将100000笔记录增加到ComboBox中？这是不合错误的，你不克不及也不必要如许做。很复杂，你的用户要扫瞄100000笔记录才干找到必要的纪录，他必定会咒骂你的。在这里，你必要的是一个更好的UI，你必要为你的用户显现不凌驾100或200笔记录。

不要利用服务器端游标

与服务器端游标比起来，客户端游标能够削减服务器和收集的体系开支，而且还削减锁准时间。

利用参数查询

偶然，我在CSDN手艺论坛看到相似如许的成绩：“SELECT*FROMaWHEREa.id=AB，由于单引号查询产生非常，我该怎样办？”，而广泛的回覆是：用两个单引号取代单引号。这是毛病的。如许治本不治标，由于你还会在其他一些字符上碰到如许的成绩，更况且如许会招致严峻的bug，除此之外，如许做还会使SQLServer的缓冲体系没法发扬应有的感化。利用参数查询，釜底抽薪，这些成绩一切不存在了。

在程序编码时利用年夜数据量的数据库

程序员在开辟中利用的测试数据库一样平常数据量都不年夜，可常常的是终极用户的数据量都很年夜。我们一般的做法是不合错误的，缘故原由很复杂：如今硬盘不是很贵，可为何功能成绩却要比及已无可挽回的时分才被注重呢？

不要利用INSERT导进多量的数据

请不要如许做，除非那是必需的。利用UTS大概BCP，如许你能够一举而兼得天真性和速率。

注重超时成绩

查询数据库时，一样平常数据库的缺省都对照小，好比15秒大概30秒。而有些查询运转工夫要比这长，出格是当数据库的数据量不休变年夜时。

不要疏忽同时修正统一纪录的成绩

偶然候，两个用户会同时修正统一纪录，如许，后一个修正者修正了前一个修正者的操纵，某些更新就会丧失。处置这类情形不是很难：创立一个timestamp字段，在写进前反省它，假如同意，就兼并修正，假如存在抵触，提醒用户。

在细节表中拔出记录时，不要在主表实行SELECTMAX(ID)

这是一个广泛的毛病，当两个用户在统一工夫拔出数据时，这会招致毛病。你可使用SCOPE_IDENTITY，IDENT_CURRENT和@@IDENTITY。假如大概，不要利用@@IDENTITY，由于在有触发器的情形下，它会引发一些成绩（详见这里的会商）。

制止将列设为NULLable

假如大概的话，你应当制止将列设为NULLable。体系会为NULLable列的每行分派一个分外的字节，查询时会带来更多的体系开支。别的，将列设为NULLable使编码变得庞大，由于每次会见这些列时都必需先辈行反省。

我并非说NULLS是贫苦的本源，只管有些人如许以为。我以为假如你的营业划定规矩中同意“空数据”，那末，将列设为NULLable偶然会发扬很好的感化，可是，假如在相似上面的情形中利用NULLable，那几乎就是自讨苦吃。

CustomerName1
CustomerAddress1
CustomerEmail1
CustomerName2
CustomerAddress2
CustomerEmail3
CustomerName1
CustomerAddress2
CustomerEmail3

假如呈现这类情形，你必要标准化你的表了。

只管不要利用TEXT数据范例

除非你利用TEXT处置一个很年夜的数据，不然不要利用它。由于它不容易于查询，速率慢，用的欠好还会华侈大批的空间。一样平常的，VARCHAR能够更好的处置你的数据。

只管不要利用一时表

只管不要利用一时表，除非你必需如许做。一样平常利用子查询能够取代一时表。利用一时表会带来体系开支，假如你是用COM+举行编程，它还会给你带来很年夜的贫苦，由于COM+利用数据库毗连池而一时表却自始至终都存在。SQLServer供应了一些替换计划，好比Table数据范例。

学会剖析查询

SQLServer查询剖析器是你的好同伴，经由过程它你能够懂得查询和索引是怎样影响功能的。

利用参照完全性

界说主健、独一性束缚和外键，如许做能够勤俭大批的工夫。




恢复到之前的某个状态，是需要数据的。这数据可以是a)回滚步骤或者b)操作之前的数据状态原文。

如果我们从集合论（关系代数）的角度来看，一张数据库的表就是一组数据元的关系，而每个SQL语句会改变一种或数种关系，从而产生出新的数据元的关系（即产生新的表）。

记得在最开始使用2k的时候就要用到这个功能，可惜2k没有，现在有了作解决方案的朋友会很高兴吧。

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

不过话说回来了，绝大多数的性能优化准则与对sqlserver存储的结构理解息息相关

总感觉自己还是不会SQL

比如日志传送、比如集群。。。

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.

无法深入到数据库系统层面去了解和探究