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种处理方案,因为后续也不会用登录系统触发器。

 

你可能感兴趣的:(SQL血的教训)