SQL血的教训

 
1.    每次查询的数据要有限制
     2013年1月  产品独立数据库，因为多条SQL每次查询数据超过几千条，有些超过10万条数据未分页，形成应用服务器CPU有时持续100%。

2.    禁止循环调用SQL

    2011年5月  程序调用Sys_User查询，每分钟执行超过3千次，形成服务器CPU持续100%

3.    禁止使用递归方法调用SQL；

    方法内如出现数据异常，极易形成查询死循环

4.    禁止每次写入大量数据
    2011年7月  深圳库导入订单的存储过程当中加入一条insert语句，每次insert超过100万条，几个小时将深圳数据库服务器磁盘写满，业务没法运行

5.    禁止在事务中使用循环加入缓存；
    2011年4月  批量更新Sys_user用户后，又在事务里循环加入缓存，形成事务运行太长，严重影响系统性能。

6.    必须在语句的具体字段要明确列出

  2011年3月  查询Product表数据，每次查询出所有字段，包括不须要的产品详细描述信息，形成系统网卡流量暴高。

7.    禁止使用业务逻辑大的事务
    2011年4月开始，前台客户最长等待须要超过30S完成下单，查询发现下单整个操做包在一个巨大的事务中，严重影响客户下单。

8.    禁止使用SQL游标Cursor；
    游标使用不当，会严重影响系统性能
9.    Select查询放到事务外

    2011年6月  某条insert语句很慢，检查发现取表的Sequence语句放在insert的事务里，在高并发下，失败率很高。

10  禁止一次删除大量数据
     2012年11月  Customer_LoginLog表因为前台写入暴增，形成当天数据超过1500万条，SQL归档执行了6个小时未删除完，影响业务操做超过6个小时。

 11，禁止主键删除再新建

    2016年，Coupon表数据，有1亿多条数据，查看其主键有大量碎片，当时不想用online的方式重建，仍是想先删除，后建立。由于当时是早上4点多，开发人员说基本没人使用，

 就没有影响，就先删除主键，结果删除后，没想到系统有大量查询coupon的请求，而主键没有，数据库运行很慢，kill后一直有，后来没办法，禁用这个连coupon表的帐户，等主键建立

成功后，再启用帐户

12，禁止用系统登陆触发器

   2017年9月，由于黑客攻击，想在数据库作个监控，对凌晨1-7点间登陆数据库的作个监控，用了SQL Server的系统登陆触发器，记录登陆信息，结果触发器先建好，记录信息的表没有建，致使

 登陆触发器审计失败，这个失败致使，其余用户登陆时也会触发这个系统登陆触发器，也报登陆失败，登陆不了，本身试了其余4台备机，也都登陆不了，前台，后台和wms程序所有报错，查了

网上资料也没找到合适的方法，程序一直在报错，这时忽然发现，已经登陆同步实时从库（8.10），虽然不能登陆，可是他已经登陆了，这时我看，可使用，我这时马上删除刚建的触发器，执行

AlwaysON切换，把数据库从主库切到实时备库。

   经历了20多分钟的重大事故终于解决。过后发现有2个解决办法，1，备份master库，出现异常时还原master库   2，CMD最小化登陆数据库删除触发器

   我这边发现就是还有一个登陆好的实时备库，进去删除。

   由于这20多分钟经历太痛苦，一直不想去模拟2种处理方案，由于后续也不会用登陆系统触发器。