MSSQL编程：优化其索引的小技能

Federated将不同的Mysql服务器联合起来，逻辑上组成一个完整的数据库。非常适合分布式应用<pstyle="TEXT-INDENT:2em">关于索引的知识：影响到数据库功能的最年夜要素就是索引。因为该成绩的庞大性，我只大概复杂的谈谈这个成绩，不外关于这方面的成绩，今朝有好几本不错的书本可供你参阅。我在这里只会商两种SQLServer索引，即clustered索引和nonclustered索引。当考查创建甚么范例的索引时，你应该思索数据范例和保留这些数据的column。一样，你也必需思索数据库大概用到的查询范例和利用的最为频仍的查询范例。<pstyle="TEXT-INDENT:2em"><pstyle="TEXT-INDENT:2em">索引的范例<pstyle="TEXT-INDENT:2em">假如column保留了高度相干的数据，而且经常被按次会见时，最好利用clustered索引，这是由于假如利用clustered索引，SQLServer会在物理上按升序（默许）大概降序重排数据列，如许就能够敏捷的找到被查询的数据。一样，在征采把持在必定局限内的情形下，对这些column也最好利用clustered索引。这是由于因为物理上重排数据，每一个表格上只要一个clustered索引。<pstyle="TEXT-INDENT:2em"><pstyle="TEXT-INDENT:2em">与下面情形相反，假如columns包括的数据相干性较差，你可使用nonculstered索引。你能够在一个表格中利用高达249个nonclustered索引――只管我设想不出实践使用场所会用的上这么多索引。<pstyle="TEXT-INDENT:2em"><pstyle="TEXT-INDENT:2em">当表格利用主关头字（primarykeys），默许情形下SQLServer会主动对包括该关头字的column(s)创建一个独占的cluster索引。很明显，对这些column(s)创建独占索引意味着主关头字的独一性。当创建外关头字（foreignkey）干系时，假如你盘算频仍利用它，那末在外关头字cloumn上创建nonclustered索引不掉为一个好的办法。假如表格有clustered索引，那末它用一个链表来保护数据页之间的干系。相反，假如表格没有clustered索引，SQLServer将在一个仓库中保留数据页。<pstyle="TEXT-INDENT:2em"><pstyle="TEXT-INDENT:2em">数据页<pstyle="TEXT-INDENT:2em">当索引创建起来的时分，SQLServer就创建数据页（datapage），数据页是用以减速搜刮的指针。当索引创建起来的时分，其对应的添补因子也即被设置。设置添补因子的目标是为了唆使该索引中数据页的百分比。跟着工夫的推移，数据库的更新会损耗失落已有的余暇空间，这就会招致页被拆分。页拆分的成果是下降了索引的功能，因此利用该索引的查询会招致数据存储的分崩离析。当创建一个索引时，该索引的添补因子即被设置好了，因而添补因子不克不及静态保护。<pstyle="TEXT-INDENT:2em"><pstyle="TEXT-INDENT:2em">为了更新数据页中的添补因子，我们能够中断旧有索引偏重建索引，偏重新设置添补因子（注重：这将影响到以后数据库的运转，在主要场所请审慎利用）。DBCCINDEXDEFRAG和DBCCDBREINDEX是扫除clustered和nonculstered索引碎片的两个命令。INDEXDEFRAG是一种在线操纵（也就是说，它不会堵塞别的表格举措，如查询），而DBREINDEX则在物理上重修索引。在尽年夜多半情形下，重修索引能够更好的打消碎片，可是这个长处是以堵塞以后产生在该索引地点表格上别的举措为价值调换来得。当呈现较年夜的碎片索引时，INDEXDEFRAG会花上一段对照长的工夫，这是由于该命令的运转是基于小的交互块（transactionalblock）。<pstyle="TEXT-INDENT:2em"><pstyle="TEXT-INDENT:2em">添补因子<pstyle="TEXT-INDENT:2em">当你实行上述措施中的任何一个，数据库引擎能够更无效的前往编进索引的数据。关于添补因子（fillfactor）话题已超越了本文的范围，不外我仍是提示你必要注重那些盘算利用添补因子创建索引的表格。<pstyle="TEXT-INDENT:2em"><pstyle="TEXT-INDENT:2em">在实行查询时，SQLServer静态选择利用哪一个索引。为此，SQLServer依据每一个索引上散布在该关头字上的统计量来决意利用哪一个索引。值得注重的是，经由一样平常的数据库举动（如拔出、删除和更新表格），SQLServer用到的这些统计量大概已“过时”了，必要更新。你能够经由过程实行DBCCSHOWCONTIG来检察统计量的形态。当你以为统计量已“过时”时，你能够实行该表格的UPDATESTATISTICS命令，如许SQLServer就革新了关于该索引的信息了。<pstyle="TEXT-INDENT:2em"><pstyle="TEXT-INDENT:2em">创建数据库保护企图SQLServer供应了一种简化并主动保护数据库的工具。这个称之为数据库保护企图导游（DatabaseMaintenancePlanWizard，DMPW）的工具也包含了对索引的优化。假如你运转这个导游，你会看到关于数据库中关于索引的统计量，这些统计量作为日记事情并准时更新，如许就加重了手工重修索引所带来的事情量。假如你不想主动按期革新索引统计量，你还能够在DMPW当选择从头构造数据和数据页，这将中断旧有索引并按特定的添补因子重修索引。
使为了数据安全，我们搭建了主从。但实时主从备份只能防止硬件问题，比如主库的硬盘损坏。但对于误操作，则无能为力。比如在主库误删一张表，或者一个update语句没有指定where条件，导致全表被更新。

外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。

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

但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。

仓酷云

至于淘汰的问题，只能说在你的项目周期之内，微软应该都不会倒闭。

数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。

分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。

呵呵，这就是偶想说的

多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。