祖仙教小凡仙 海鲨数据库架构师
小仙从事多年的DBA，也会数据库PL/SQL开发。遇到很多性能问题，各种隐患和雷坑。
一 禁止使用long字段
因为该LONG字段类型BUG多，甲骨文对它彻底放弃了。二 禁止使用varchar2存储时间
很简单时间是用来加，减，排序，和范围查找。字符不提供这些，或者精度，准确不够。三 禁止使用varchar2存数字
数字用数字字段，这里是说需要进行加工的数字，不是手机的号码。
字符字段里存数字，并且取出来加工，涉及类型转换性能损失。可能导致全表扫描。比如 where money=12000 MONEY字段是字符类型，可存的是数字，开发人员一不小心传入纯数字，就触发隐式转化。四 禁止使用select *
* 虽然写得方便，可谁知道后续对该表的字段添加，减少带来的坑呢？如果添加个CLOB字段呢？你的前端页面并没有显示它，它也还是从数据库传到TOMCAT上，然后JAR做筛选，再丢给JSP。
举例说 一个表 有4个字段，分别是 user（id,name,money,time )
页面 就显示了这4个字段。开发人员赶工期 就来个
SELECT * FROM USER WHERE ID=:1;
上线后N个月,业务需要添加人头像, 就要新增个字段IMAGE CLOB类型.
只有点击该行后,弹显出来的页面才显示人头像. 当然后期开发人员就负责该弹出来的页面语句
SELECT name,money,time,IMAGE FROM USER WHERE ID=:1;
五 禁止使用delete
不管任何数据是不能被删除的, 只能更新下状态来标注可删除.数据端DBA维护数据就根据时间和标志来迁移走数据.然后回头把迁移的数据给删了.
六 禁止使用外建约束
外键是个麻烦的事情,在JAVA界有8年的历史,把外键约束放到应用层来处理.七 禁止使用触发器
触发器虽然方便,按照JAVA思想所有业务放在应用层,触发器原来本身就是带有业务特性.另外它会延伸很多SQL出来.在高并发下造成性能下降八 禁止使用存储过程
业务放在JAVA中,存储过程基本不写业务.存储过程交给DBA去维护数据吧!九 禁止使用同义词
同义词,好像我拥有你的表,使用时不写你的名字. 这点便利没啥好处.反而因为基表不在,同义词失效情况贼多,而且与表名相同造成对象以存在.同义词本身可以用只读账号外加付权限就行了. 在如今微服时代基本上OK
十 禁止使用dblink
DBLINK 会导致查询性能飘忽不定.而且造成被DBLINK的SCN号极大消耗.十一 禁止使用order by 除了分页sql
ORDER BY 排序是消耗内存和CPU的资源操作,数据量大的话,就要到硬盘上排序. 你说你的数量小可以在数据库内存完成排序,可是你知道系统上线以后,要在数据库端排序的SQL有多少吗? 每秒几千总有吧! 这样极大消耗数据库CPU或者IO资源.以及不断膨胀的TEMP空间.大家想一下 ORDER BY 不就是让人看的舒服点啊! 这操作可以放在前端JSP,用IE去排序,消耗客户的CPU. 也可以放在应用端TOMCAT 内存里排序.你说 TOMCAT和数据库排序不是一样的吗?
在如今时代,应用端可以集群,可以被NGINX负载均衡,可以堆服务器.而数据库就一台,或者5-6台. 这些服务器只是为了高可用存在的,大部分不是为了性能存在的. 因为应用服务器都是无状态的,被负载均衡后,每个应用服务器负担很轻.而数据库则不能,全部SQL有一个数据库服务来提供排序.当然一些备库也可以承担部分SQL排序,那是对时间实时性要求低的SQL.其实ORDER BY 开发人员玩起来顺手,有利于加速开发速度而已.
十二 禁止在OLTP系统里使用物化视图
物化视图是方便报表系统的,在交易系统OLTP 物化视图日志会积累很多,时间长了查询对比日志,会消耗OLTP系统资源.
建议使用OGG 从日志挖出数据 同步到报表系统的对应表,然后在报表系统上玩物化视图.