通过错误的sql来测试推理sql的解析过程(二) （r8笔记第7天)

之前总结过一篇 通过错误的sql来测试推理sql的解析过程 也算是以毒攻毒，当然也分析出来一些有意思的内容来，让原本看起来枯燥的内容有了更多的实践意义。 在后来小组内部做了一个分享总结，本来以为已经总结差不多了，但是发现真是集思广益，大家临时想出不少好的点子来，这也就是brainstroming的好处吧. 比如下面的错误sql，在解析的时候，会首先报错在group by的部分。在10g和11g略微有一些差别。目前以11g的为基线。 目前存在一个表test，字段情况为(id number,name varchar2(30))，里面存在1条数据。 使用如下的语句来测试一下，会发现这样的基本规律 select id1 from test1 where id1='aaa' group by id1 having1 count(*)>0 order by5 id1 * ERROR at line 1: ORA-00933: SQL command not properly ended select id1 from test1 where id1='aaa' group by id1 having count(*)>0 order by5 id1 * ERROR at line 1: ORA-00924: missing BY keyword SQL> select id1 from test1 where where1 id1='aaa' group by id1 having count(*)>0 order by5 id1; select id1 from test1 where where1 id1='aaa' group by id1 having count(*)>0 order by5 id1 * ERROR at line 1: ORA-00920: invalid relational operator SQL> select id1 from test1 t where1 id1='aaa' group by id1 having count(*)>0 order by5 id1; select id1 from test1 t where1 id1='aaa' group by id1 having count(*)>0 order by5 id1 * ERROR at line 1: ORA-00933: SQL command not properly ended 可见对于这些保留字，在解析的是按照从右向左的顺序依次来解析。 如果存在数据类型的兼容性，在隐私转换的时候如果失败，会在解析的时候一并抛出，其实这个时候已经到了执行阶段了，对于数据的细节信息无从考证，使用explain plan还是能够生成执行计划来。 SQL> select id from test t where id='aaa' group by id order by id; select id from test t where id='aaa' group by id order by id * ERROR at line 1: ORA-01722: invalid number 我们清空数据，继续测试 SQL> delete from test; 1 row deleted. SQL> commit; Commit complete. 这个时候再次测试，发现同样的语句在这个时候就没法直接分析出来了。这种情况看起来也是一个灰色地带。 SQL> select id from test t where id='aaa' group by id order by id; no rows selected 那么统计信息对于sql解析有没有影响呢？ 我们收集一下统计信息，让优化器能够认为存在一条数据。 SQL> exec DBMS_STATS.SET_TABLE_STATS (ownname=>'TEST',tabname=>'TEST',numrows=>1); PL/SQL procedure successfully completed. 再次执行同样的sql语句，发现还是没有做出更进一步的校验。 SQL> select id from test t where id='aaa' group by id order by id; no rows selected 如果尝试让优化器识别出数据块的情况来，是不是有改善呢？ SQL> exec DBMS_STATS.SET_TABLE_STATS (ownname=>'TEST',tabname=>'TEST',numrows=>1,numblks=>1); PL/SQL procedure successfully completed. 情况还是类似。 SQL> select id from test t where id='aaa' group by id order by id; no rows selected 通过上面的结果，可以简单推论是不是和数据情况有关系呢，但是看起来关系还是不大，怎么进一步验证呢。 我们继续测试隐式转换的问题。 如果插入一条记录，但是id列为null. SQL> insert into test values(null,'aaaaa'); 1 row created. 那么同样的语句会抛出错误吗？ SQL> select id from test t where id='aaa' group by id order by id; no rows selected 但是继续测试，插入id为2，这个时候再次运行同样的语句就会抛错，这个也是预期这种理想的情况。 SQL> insert into test values(2,'aadbdsaf'); 1 row created. SQL> select id from test t where id='aaa' group by id order by id; select id from test t where id='aaa' group by id order by id * ERROR at line 1: ORA-01722: invalid number 继续测试索引的影响。 先清空数据。 SQL> truncate table test; Table truncated. 然后添加主键。 SQL> alter table test modify(id primary key); Table altered. 这个时候再次测试就会发现同样的语句就开始抛错了，看来主键的情况还是好使，能够做一些看起来的硬验证。 SQL> select id from test t where id='aaa' group by id order by id; select id from test t where id='aaa' group by id order by id * ERROR at line 1: ORA-01722: invalid number 那么我们换个角度在索引列和非索引列上测试隐式转换的情况。 SQL> select id from test t where name=111 and id='aaa' group by id order by id; select id from test t where name=111 and id='aaa' group by id order by id * ERROR at line 1: ORA-01722: invalid number 然后删除主键 SQL> alter table test drop primary key; Table altered. 继续测试同样的sql语句。这个时候就校验不出来数据的细节情况了。 SQL> select id from test t where name=111 and id='aaa' group by id order by id; no rows selected 如果我们插入一条记录。 SQL> insert into test values(1,22222); 1 row created. 然后再次验证，会发现这条语句可以从两种可能性来理解，一种是确实没有数据，没有name列相关的数据，还没有验证到id='aaa'的情况。 SQL> select id from test t where name=111 and id='aaa' group by id order by id; no rows selected 那么我们使用过滤条件，指向新增加的那条记录。 SQL> select id from test t where name=22222 and id='aaa' group by id order by id; select id from test t where name=22222 and id='aaa' group by id order by id * ERROR at line 1: ORA-01722: invalid number 就会发现有意思的问题还是发生了。 后面还有一些测试的细节，后面继续解读。