MSSQL编程：InnoDB 中文参考手册 --- 11 表和索引结...

出于效率方面的考虑，InnoDB数据表的数据行级锁定实际发生在它们的索引上，而不是数据表自身上。显然，数据行级锁定机制只有在有关的数据表有一个合适的索引可供锁定的时候才能发挥效力。参考|参考手册|索引|中文InnoDB中文参考手册---犬犬(心帆)翻译11表和索引布局
MySQL在数据库目次下的.frm文件中存储它的数据字典信息。可是每一个InnoDB范例表也一样在InnoDB表空间内的外部的数据字典中存在它本人的进进点。当MySQL移除(drop)一个表或一个数据库时，它将同时删除.frm文件，和在InnoDB的数据字典中绝对应的进进点。这就是为何不克不及经由过程复杂的删除.frm文件为移除数据库中的InnoDB范例表的缘故原由，和为何在MySQL版本<=3.23.43的版本中，DROPDATABASE不克不及用于InnoDB表的缘故原由。

每个InnoDB表都有一个被称为聚簇索引的特别索援用于保留纪录行信息。假如一个表界说一个PRIMARYKEY，那末主键的索引就是聚簇索引。

假如表没有界说一个PRIMARYKEY，MySQL将选出第一个NOTNULL字段的UNIQUE键做为主键，InnoDB也将用这个键的索引做为聚簇索引。假如表中没有如许的键，InnoDB将在外部发生一个聚簇索引，它是由按InnoDB分派给它们的rowid按次排序的纪录行构成。这个rowid是一个单调地增添并拔出新行的6-byte字段。因此由rowid排序的纪录按次也就是拔出时的物理按次。

经由过程聚簇索引会见一个纪录行长短常快的，由于纪录行数据与引诱我们查找到它的索引在统一个页面上。在年夜多半的数据库体系中纪录行数据与索引纪录一般并非放在统一个页面上的。假如一个表太年夜了，那末聚簇索引系统一般比传统的体例更能削减磁盘I/O。

在非-聚簇索引(non-clusteredindexes)中的纪录(我们一般称它为帮助索引secondaryindexes)，在InnoDB中会为这行包括主键值。InnoDB将利用这个主键值来在聚簇索引中查找这行。注重假如主键太长，那末帮助索引将会占用更多的空间。

InnoDB在对照分歧长度的CHAR和VARCHAR时，较短字串的过剩长度将被空格(spaces)添补。
11.1索引的物理布局
AllindexesinInnoDB中一切的索引是索引纪录寄存在树的叶页面(leafpages)上的B-trees。一个索引页面的巨细默许为16kB。当新的纪录被拔出时，InnoDB将试图为未来的拔出与更新索引纪录保存页面的1/16空余。

假如索引纪录以一个一连的(升序或降序)被拔出，那末索引页面的将会被利用约15/16。假如以一个随机的按次拔出，那末页面约莫利用了1/2-15/16。假如一个索引页面被打消(drop)地低于1/2，那末InnoDB将延长索引树并开释页面空间。
11.2拔出缓冲
主键是一个独一标识符，新的纪录以主键的升序被拔出，这在数据库体系中是一个广泛的情况。因此在聚簇索引内拔出的值不必要在硬盘上随便读取。

另外一方面，帮助索引一般长短独一的(non-unique)，拔出在帮助索引中是相称随便的按次。假如在InnoDB中不利用一个特别的机制这将会引发大批随机的磁盘I/O。

假如一个索引纪录被拔出到一个非独一的帮助索引中往，InnoDB将反省帮助索引页面是不是已在缓冲池(bufferpool)中。在这类情况下，InnoDB间接地将它拔出到索引页面中往。可是，假如在缓冲池中没有发明索引页面，InnDB将索引纪录拔出到一个特别的拔出缓冲布局中往。拔出缓冲被把持地如些小以致于能够完整放在缓冲池中，因此拔出速率很快。

拔出缓冲会准时地合并到数据库中的帮助索引树中往。为了削减磁盘I/O，一般将统一个页面上的几个拔出同时合并到索引树上。拔出缓冲能够进步向一个表中拔出速率15倍。
11.3顺应性的散列索引(Adaptivehashindexes)
假如一个数据库几近占满了一切主同存，那末在其上运转查询的一个快速之路就是利用散列索引(hashindexes)。InnoDB有一个用于监督在表界说的索引上的索引搜刮举措的主动调剂布局，假如InnoDB发明一个散列索引对查询无益，那末它将主动地制作这个散列索引。

可是要注重地就是散列索引一般是基于表中已存在的B-tree创立的。InnoDB大概经由过程B-tree中界说的任何长度的键的前缀来构建散列索引，这依附于InnoDB察看B-tree上索引的形式。一个散列索引能够是部分的：它在缓冲池中其实不必要有全部B-tree索引的高速缓冲。InnoDB依照必要来为常常会见的索引页面构建散列索引。

在实际上，经由过程这个顺应性的散列索引机制，InnpDB使它本人更合适于年夜的主存(amplemainmemory)，更靠近于主存储器数据库体系系统(thearchitectureofmainmemorydatabases)。
11.4纪录的物理布局InnoDB中每一个索引纪录都包括一个6字节的头。这个头部用于联连相联贯的纪录，也一样用于行锁定。聚簇索引中的纪录包括了一切用户界说的字段。别的，有一个6-byte字段用于纪录事件id(transactionid)和一个7-byte字段用于行指针(rollpointer)。在一个表中，假如用户没有界说一个主键，那末每一个聚簇索引纪录包括一个6-byte的行id字段(rowidfield)。每一个帮助索引纪录包括为聚簇索引键界说的一切字段。一个索引包括着一个指向对应字段纪录的指针。假如一个纪录的一切字段总长度<128bytes，那末这个指针为1byte，不然为2bytes。InnoDB在外部也是以一个流动长度来存储定长的字符型字段，好比CHAR(10)。关于VARCHAR型字段，InnoDB将截往开头的空间。注重，MySQL大概外部地将CHAR转换为VARCHAR。检察MySQL用户手册有关“列规约的默许地改动”(Silentcolumnspecificationchanges)。假如存储一个变长的字段，一个SQLNULL为一个0bytes被存储，可是假如是一个定长字段将以流动的长度被存储。以响应的NULLs存储定长的空间的目标地就在于在将NULL字段值更新为非NULL的值时不至发生索引页面的磁盘碎片。mysqld进程在一个写入当中被杀死;计算机的意外关闭(例如，如果计算机掉电);一个硬件错误。

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

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。

财务软件要用SQL也只是后台的数据库而已,软件都是成品的,当然多学东西肯定是有好处的..

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

仓酷云

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

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

这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。