由于sqlserver在同一张表不支持一个以上的级联删除（on delete cascade）但在实际开发的时候、还是需要使用到的、所以我们不得不使用触发器来完成这项工作问题又来了、由于从表存在外键、直接删除主表肯定是不行的、而sqlserver的触发器没有oracle的befo

多个操作语句的触发器为什么在执行时，只执行了第一句？ 这个问题困扰了我好久，记得第一次遇到这个问题是半个月前，做牛腩新闻发布系统的数据库遇到这个问题，是关于级联删除的：当我们删除新闻类别的时候，由于外键的原因，我们无法删除新闻类别下有新闻内容的记录，但是通过如下触发器，我们就可以实现： create trigger trigcategorydelete on

两张用户表，修改其中一张表a的密码字段，另一张表b也同时更新字段。同理的，修改表b的密码字段，另一张表a也同时更新字段。分别为两张表创建触发器，这样就会出现，两个触发器会陷入死循环，处理方法如下： CREATE TABLE [T_users]( [yhbm] [varchar](20) NOT NULL, [pwd] [varchar](20) NULL)CREATE

当视图向表中插入数据时，insert触发器会自动执行，此时系统会自动创建一个insert表，新的记录被添加到触发器和inserted表中，触发器可以检查inserted表，确定执行触发器动作和如何执行触发器动作

今天第一次写项目中的触发器。虽说以前也看过一些关于触发器的书籍，自己也知道语法，但是却从没有在真正的大项目中写过。按照项目的需求和触发器的语法，我成功创建了一个触发器。另我感到奇怪的是，原本会定时自动向数据库里插入数据，却在创建触发器后不再插入了，而触发器的编译却没有错误。不过通过手动插入一条数据时，pl/sql还是锁定到了触发器异常上。于是，我决定测试此触发器。以前测试过程，函数时只

同一主机复制触发器： 如果是跨主机复制触发器：注意他的提示 此时在复制触发器： 注意：如果复制中提示错误，从错误的触发器开始以后的触发器不会执行复制，此时应该将两个数据库中的触发器对比，哪个触发器没有复制，重新复制

触发器和存储过程的优缺点 (一) 缺点： 1、可移植性是存储过程和触发器最大的缺点。 2、占用服务器端太多的资源，对服务器造成很大的压力 3、不能做DDL。 4、触发器排错困难，而且数据容易造成不一致，后期维护不方便。 优点： 1、预编译，已优化，效率较高。避免了SQL语句在网络传输然后再解释的低效率。 2、存储过程可以重复使用，减少开发人员的工作量。 3、

程序员，依然要掌握好此知识。

◆存储过程（Procedure）类似于C语言中的函数，用于执行管理任务或应用复杂的业务规则，存储过程可以带参数，也可以返回结果。

◆存储过程可以包含数据操纵语句、变量、逻辑、控制语句等。

◆和C语言的函数一样，参数可选

◆参数分为输入参数(按值传递)、输出参数(按引用传递)。

◆输入参数允许有默认值

◆在java中使用存储过程

◆触发器是在对表进行插入、更新或删除操作时自动执行的存储过程

◆触发器通常用于强制业务规则

◆触发器是一种高级约束，可以定义比用check约束更为复杂的约束

b)可引用其它表中的列

◆触发器定义在特定的表上，与表相关。

◆是一个事务（可回滚）

系统自动在内存中创建两张临时表，deleted表或inserted表。

这两张表为只读，不允许修改，触发器执行完成后，自动删除。

临时保存了插入或更新后的记录行

可以从inserted表中检查插入的数据是否满足业务需求

如果不满足，则向用户报告错误，并回滚插入操作

临时保存了删除或更新前的记录行

可以从表中检查被删除的数据是否满足业务需求

如果不满足，则向用户报告错误，并回滚插入操作

1.13.4 创建触发器的语法

当往交易信息表中插入一条数据时，同时更新帐户表中的金额

当在交易信息表中删除一条数据时，备份这条数据到transInfoBackup表中

当用户交易金额大于20000时，不让用户操作，并提示错误

Update 触发器除了跟踪数据的变化（修改）外，还可以检查是否修改了某列的数据。

使用update（列）函数检测是否修改了某列

问题：交易日期一般由系统自动产生，默认为当前日期，为了安全起见，一般禁止修改，以防舞弊。（注意：时间分DB服务器时间和Web服务器时间）

Update（列名）函数可以检测是否修改了某列

   =============＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　　经过紧张的调查，你发现问题出在数据库上，当应用程序尝试访问/更新数据时，数据库执行得相当慢，再次深入调查数据库后，你发现数据库表增长得很大，有些表甚至有上千万行数据，测试团队开始在生产数据库上测试，发现订单提交过程需要花5分钟时间，但在网站上线前的测试中，提交一次订单只需要2/3秒。

　　类似这种故事在世界各个角落每天都会上演，几乎每个开发人员在其开发生涯中都会遇到这种事情，我也曾多次遇到这种情况，因此我希望将我解决这种问题的经验和大家分享。

　　如果你正身处这种项目，逃避不是办法，只有勇敢地去面对现实。首先，我认为你的应用程序中一定没有写数据访问程序，我将在这个系列的文章中介绍如何编写最佳的数据访问程序，以及如何优化现有的数据访问程序。

　　在正式开始之前，有必要澄清一下本系列文章的写作边界，我想谈的是“事务性(OLTP)SQL Server数据库中的数据访问性能优化”，但文中介绍的这些技巧也可以用于其它数据库平台。

　　同时，我介绍的这些技巧主要是面向程序开发人员的，虽然DBA也是优化数据库的一支主要力量，但DBA使用的优化方法不在我的讨论范围之内。

　　当一个基于数据库的应用程序运行起来很慢时，90%的可能都是由于数据访问程序的问题，要么是没有优化，要么是没有按最佳方法编写代码，因此你需要审查和优化你的数据访问/处理程序。

　　我将会谈到10个步骤来优化数据访问程序，先从最基本的索引说起吧!

　　第一步：应用正确的索引

　　我之所以先从索引谈起是因为采用正确的索引会使生产系统的性能得到质的提升，另一个原因是创建或修改索引是在数据库上进行的，不会涉及到修改程序，并可以立即见到成效。

　　我们还是温习一下索引的基础知识吧，我相信你已经知道什么是索引了，但我见到很多人都还不是很明白，我先给大家将一个故事吧。

　　很久以前，在一个古城的的大图书馆中珍藏有成千上万本书籍，但书架上的书没有按任何顺序摆放，因此每当有人询问某本书时，图书管理员只有挨个寻找，每一次都要花费大量的时间。

　　这就好比数据表没有主键一样，搜索表中的数据时，数据库引擎必须进行全表扫描，效率极其低下。

　　更糟的是图书馆的图书越来越多，图书管理员的工作变得异常痛苦，有一天来了一个聪明的小伙子，他看到图书管理员的痛苦工作后，想出了一个办法，他建议将每本书都编上号，然后按编号放到书架上，如果有人指定了图书编号，那么图书管理员很快就可以找到它的位置了。

　　[给图书编号就象给表创建主键一样，创建主键时，会创建聚集索引树，表中的所有行会在文件系统上根据主键值进行物理排序，当查询表中任一行时，数据库首先使用聚集索引树找到对应的数据页(就象首先找到书架一样)，然后在数据页中根据主键键值找到目标行(就象找到书架上的书一样)。]

　　于是图书管理员开始给图书编号，然后根据编号将书放到书架上，为此他花了整整一天时间，但最后经过测试，他发现找书的效率大大提高了。

　　在一个表上只能创建一个聚集索引，就象书只能按一种规则摆放一样。

　　但问题并未完全解决，因为很多人记不住书的编号，只记得书的名字，图书管理员无赖又只有扫描所有的图书编号挨个寻找，但这次他只花了20分钟，以前未给图书编号时要花2-3小时，但与根据图书编号查找图书相比，时间还是太长了，因此他向那个聪明的小伙子求助。

　　这就好像你给Product表增加了主键ProductID，但除此之外没有建立其它索引，当使用Product Name进行检索时，数据库引擎又只要进行全表扫描，逐个寻找了。

　　聪明的小伙告诉图书管理员，之前已经创建好了图书编号，现在只需要再创建一个索引或目录，将图书名称和对应的编号一起起来，但这一次是按图书名称进行排序，如果有人想找“Database Management System”一书，你只需要跳到“D”开头的目录，然后按照编号就可以找到图书了。

　　于是图书管理员兴奋地花了几个小时创建了一个“图书名称”目录，经过测试，现在找一本书的时间缩短到1分钟了(其中30秒用于从“图书名称”目录中查找编号，另外根据编号查找图书用了30秒)。

　　图书管理员开始了新的思考，读者可能还会根据图书的其它属性来找书，如作者，于是他用同样的办法为作者也创建了目录，现在可以根据图书编号，书名和作者在1分钟内查找任何图书了，图书管理员的工作变得轻松了，故事也到此结束。

　　到此，我相信你已经完全理解了索引的真正含义。假设我们有一个Products表，创建了一个聚集索引(根据表的主键自动创建的)，我们还需要在ProductName列上创建一个非聚集索引，创建非聚集索引时，数据库引擎会为非聚集索引自动创建一个索引树(就象故事中的“图书名称”目录一样)，产品名称会存储在索引页中，每个索引页包括一定范围的产品名称和它们对应的主键键值，当使用产品名称进行检索时，数据库引擎首先会根据产品名称查找非聚集索引树查出主键键值，然后使用主键键值查找聚集索引树找到最终的产品。

　　下图显示了一个索引树的结构

　　图 1 索引树结构

　　它叫做B+树(或平衡树)，中间节点包含值的范围，指引SQL引擎应该在哪里去查找特定的索引值，叶子节点包含真正的索引值，如果这是一个聚集索引树，叶子节点就是物理数据页，如果这是一个非聚集索引树，叶子节点包含索引值和聚集索引键(数据库引擎使用它在聚集索引树中查找对应的行)。

　　通常，在索引树中查找目标值，然后跳到真实的行，这个过程是花不了什么时间的，因此索引一般会提高数据检索速度。下面的步骤将有助于你正确应用索引。

　　确保每个表都有主键

　　这样可以确保每个表都有聚集索引(表在磁盘上的物理存储是按照主键顺序排列的)，使用主键检索表中的数据，或在主键字段上进行排序，或在where子句中指定任意范围的主键键值时，其速度都是非常快的。

　　在下面这些列上创建非聚集索引：

　　1)搜索时经常使用到的;

　　2)用于连接其它表的;

　　3)用于外键字段的;

　　下面是一个创建索引的例子：　

　　也可以使用SQL Server管理工作台在表上创建索引，如图2所示。

　　图 2 使用SQL Server管理工作台创建索引

第二步：创建适当的覆盖索引

　　假设Sales表有10,000行记录，下面的SQL语句选中400行(总行数的4%)：　

　　我们来看看这条SQL语句在SQL执行引擎中是如何执行的：

　　1)Sales表在ProductID列上有一个非聚集索引，因此它查找非聚集索引树找出ProductID=112的记录;

　　2)包含ProductID = 112记录的索引页也包括所有的聚集索引键(所有的主键键值，即SalesID);

　　3)针对每一个主键(这里是400)，SQL Server引擎查找聚集索引树找出真实的行在对应页面中的位置;

　　如果非聚集索引页中包括了聚集索引键和其它两列(SalesDate,，SalesPersonID)的值，SQL Server引擎可能不会执行上面的第3和4步，直接从非聚集索引树查找ProductID列速度还会快一些，直接从索引页读取这三列的数值。

　　幸运的是，有一种方法实现了这个功能，它被称为“覆盖索引”，在表列上创建覆盖索引时，需要指定哪些额外的列值需要和聚集索引键值(主键)一起存储在索引页中。下面是在Sales 表ProductID列上创建覆盖索引的例子：　

　　应该在那些select查询中常使用到的列上创建覆盖索引，但覆盖索引中包括过多的列也不行，因为覆盖索引列的值是存储在中的，这样会消耗过多内存，引发性能下降。

　　创建覆盖索引时使用数据库调整顾问

　　我们知道，当SQL出问题时，SQL Server引擎中的优化器根据下列因素自动生成不同的查询计划：

　　4)TSQL中的参数值

　　这就意味着，对于特定的SQL，即使表和索引结构是一样的，但在生产和在测试服务器上产生的执行计划可能会不一样，这也意味着在测试服务器上创建的索引可以提高应用程序的性能，但在生产服务器上创建同样的索引却未必会提高应用程序的性能。因为测试环境中的执行计划利用了新创建的索引，但在生产环境中执行计划可能不会利用新创建的索引(例如，一个非聚集索引列在生产环境中不是一个高选中性列，但在测试环境中可能就不一样)。

　　因此我们在创建索引时，要知道执行计划是否会真正利用它，但我们怎么才能知道呢?答案就是在测试服务器上模拟生产环境负载，然后创建合适的索引并进行测试，如果这样测试发现索引可以提高性能，那么它在生产环境也就更可能提高应用程序的性能了。

　　虽然要模拟一个真实的负载比较困难，但目前已经有很多工具可以帮助我们。

收货颇丰，非常感谢