保持空杯，无惧未来-------sql raiserror() 强制返回 ;sql 调优 ---top 超时

     就在今天，或许是之前就发现的问题，只是没有特别的重视：做系统，写逻辑切忌欺骗自己，因为代码不会欺骗人，也没有侥幸，跟没有不用测试，万一对了呢，之前在做系统的时候就出现了这个状况，因为代码是在太繁杂了，测试是在太麻烦了，于是楼主就偷懒了，无可避免的就是漏洞，领导虽然没有说什么，但是我知道个人印象肯定是不太好，不过，也算是教训，主要是自己的心态问题，在数学逻辑里没有可能这一说，只有是或者不是，毕业两年居然就忘了，最可怕的是在那之后，因为项目加急，我根本就没有深刻认识到这个，然后就没有在去管它了，以至于今天又出现了这个错误，没有测试就更新了，一则，工作几年逐渐变得比较自负，自信没有错误，可是现实就给了我当头一棒，于是才觉定记录下来这一事件，以作教训。

    场景：系统调用存储过程，执行存储过程，然后，我在存储过程中间写了个控制，控制当一定条件时，跳出存储过程，raiserror()提示控制信息。但是，没想到的是：控制跳出了，但是存储过程却没有终止，继续执行下去了，以至于不仅没有起到控制数据的作用，还在接下来执行的语句中更新了诸多表数据，总之来说就是失败透顶。最后查资料才发现sql语句raiserror() 模拟异常，是可以抛出异常，但是并不会停止运行过程。一下为存储过程的控制部分。

IF (SELECT COUNT(*) FROM (SELECT A2.FENO,A2.ShipmentQty,A4.PQty FROM (SELECT  FENO,SUM(ShipmentQty) AS ShipmentQty FROM (SELECT FENO,SUM(ShipmentQty) AS ShipmentQty FROM dbo.SHSY001D1WHERE SHSY001_FK=@SHSY001_FK GROUP BY FENOUNION ALLSELECT FENO,SUM(ShipmentQty) AS ShipmentQty FROM dbo.SHSY001D2WHERE FENO IN (SELECT FENO FROM SHSY001D1 WHERE SHSY001_FK=@SHSY001_FK) GROUP BY FENO)AS A1 GROUP BY A1.FENO)AS A2LEFT JOIN (SELECT SHSY001_FK,FENO,PQty FROM (SELECT A1.*,SS2.PQty FROM (SELECT SHSY001_FK,FENO,TotalQtyFROM dbo.SHSY001D2 AS D2)AS A1LEFT JOIN (SELECT FSNO,SUM(PQty) AS PQty FROM dbo.ORDA001WHERE BusiType='5' AND FSNO IN (SELECT FENO FROM SHSY001D2)GROUP BY FSNO)AS SS2 ON A1.FENO = SS2.FSNO)AS A3 WHERE A3.FENO IN (SELECT FENO FROM dbo.SHSY001D1 WHERE SHSY001_FK =@SHSY001_FK)--WHERE (ISNULL(A3.TotalQty,0)-ISNULL(A3.PQty,0))<>0GROUP BY A3.SHSY001_FK,FENO,PQty)A4 ON A2.FENO = A4.FENO)A5  WHERE  (A5.ShipmentQty-A5.PQty)>0)>0BEGINRAISERROR('该单项目累计出库数量已经大于项目总数量。 !',11,1) WITH nowaitRETURN END

以上是我修改后的代码，之前是没有强制返回的，raiserror()虽然是模拟try  catch() 抛出异常，但是由于sql的特性，当没有致命错误的时候过程是会继续执行下去的。这就是错误的根本。而在之后加上强制返回后，就没有问题了。

以上为教训一：测试是必要的，哪怕是最简单的一个功能，心里百分百确定的过程，也要实际的去测试一下。

教训二： 就在今天早上，或许是从事技术几年之后感觉技术有了定的基础之后，便有了一些自傲的情绪，以至于对于新手的简单问题不愿意慢慢去回答，而在之后我又立刻意识到了这个问题，我们都是从新手过来的，都是从最开始的一个手指头打字到后来的十个指头，不过幸好发现的早，对于技术我们应该随时保持空杯的姿态，感受技术的魅力，时刻谦虚谨慎。逐渐深入，然后才衍生自己的想法。

下面写写场景二：一个比较复杂的视图，在一个列表中显示时发现超时【我每页显示十条数据top 10】，然后发现居然超时了，最可怕的是，我不写top的时候居然没有超时，显示出了数据。后面我在数据库中测试也是如此。这个就让人有点懵逼了，新接触数据库的人肯定都会以为查询10条数据肯定会比查询100条数据块啊 ，写top，肯定比没有top快啊 。

       一般情况下，数据查询的多少确实直接决定了搜索的快慢，但是，我们想一下，要top 10 就肯定需要先排个序吧，没有一个顺序怎么top呢，数据有一个顺序之后才可以选择查询前多少条数据，于是我就开始检查了；发现果然没有排序，数据库会给一个默认排序（根据主键），这样就会出现全表扫面的情况，于是自然就拉低了速度，而我们所做就是需要在是视图查询之前给视图排一下序（但是注意：排序不能写在视图里面，因为视图里面的排序是没有效果的，不信的可以试试，哈哈。）

     要排序就需要选择排序的字段，这个就是影响你搜索速度的关键的，一般数据库表都会在主键和一些特殊字段上建立索引，而这些字段就会成为我们提升速度的关键【我的理解是建立了索引的字段就相当于我们可以快速找到它，然后给他们排序】这样会极大的提升搜索速度。

     然后我就找了一个带索引的字段，根据它排序，搜索前十条，so fast !问题解决。【代码就不贴了，太多】