通过外部表改进一个繁琐的大查询

简介: 今天处理了一个比较有意思的案例,说是有意思,因为涉及多个部门,但是哪个部门似乎都不愿意接。最后还是用了一些巧力,化干戈为玉帛。 问题的背景是这样的,业务部门需要做一个大查询,他们目前只拿到了部分账号的一个id字段的值,需要匹配得到一个类似手机号的字段值,开发部门提供了对应的sql语句,会关联两张表来匹配得到对的数据,然后反馈到DBA这里的时候就是最终的sql语句了,DBA查询得到数据,然后反馈给业务部门。
今天处理了一个比较有意思的案例,说是有意思,因为涉及多个部门,但是哪个部门似乎都不愿意接。最后还是用了一些巧力,化干戈为玉帛。
问题的背景是这样的,业务部门需要做一个大查询,他们目前只拿到了部分账号的一个id字段的值,需要匹配得到一个类似手机号的字段值,开发部门提供了对应的sql语句,会关联两张表来匹配得到对的数据,然后反馈到DBA这里的时候就是最终的sql语句了,DBA查询得到数据,然后反馈给业务部门。大体的流程是这样的。
   但是现在的问题是,业务部门需要提供的id有60多万个,开发部门看到这个情况就不太愿意提供这样的语句了,你说一条一条提供吧,可能对于他们来说还需要不少的工作量,而且文件可能几十M,工作量也非常大。对于业务部门来说,他们又不懂技术细节,对于DBA来说,巧妇难为无米之炊。所以这个时候就有些踢皮球了的感觉了。
   我看了下,觉得这活毕竟也不是经常有这种问题,那就接了吧。虽然中途碰到了不少的小问题,不过也着实值得一试。
    开发部门提供的语句类似下面的形式。
select CID from test_user_info  where login_name='?'
select SECURITY_PHONE from test_user_certification_info  where cid='?'
    业务部门就提供了一个excel文件,里面是60多万的id值,想直接转到linux环境里还不行。
    从我的角度来看,大体有这些考虑,也算是问题的一些难点吧。
     (1)这些id值怎么通过excel传输到内网环境,对于内网而言,大文件的传输目前有x M的限制
     (2)因为涉及的id还是有些多,那么这类操作只能备库操作了。
     (3)in 的限制,如果根据提供的id来匹配,那么语句select CID from test_user_info  where login_name='?' 是不可避免要使用in的方式了。但是in的方式会有1000个以内枚举值的限制,对于60万的id值来说,如果这么切分,工作量和难度又会加大。所以in的方式还是不太好。
     (4)等我连接到环境,发现问题比我想的还要难一些,这两个表 test_user_info,test_user_certification_info目前做了拆分,把数据拆成了12份。意味值目前存在12个用户平均存储了这些数据。
对于这个问题的处理,这个时候就不单单是友情支持了,还是需要好好考虑一下,怎么巧妙解决,而不是光靠苦力了。
我们来逐个分析这个问题。
第一个怎么把excel里面的60万id拷贝到内网环境,这个花了我一些时间去琢磨,首先这个excel有近15M,直接拷贝不了,而且还有网络的流量限制。而且就算把excel文件拷贝过去,在linux下也直接解析不了。所以我是通过excel把id列的值拷贝到文本文件中,然后通过云服务器来中转这个文件,避开了流量的限制。间接实现了首要条件。
第二个是目前涉及的id有些多,只能在备库执行,这个倒没有异议,但是结合第三条来看,需要避免使用in list的方式,我们可以采用临时表的方式,或者使用外部表。
所以对此我打算在主库中创建外部表,然后外部表的ddl会同步到备库,然后把实际的文本文件拷贝到备库去,查询操作都在备库执行。这样就和主库没有了关系。备库怎么查询主库都不会收到影响。
所以我在主库做了如下的操作。
首先创建目录。
SQL> create directory ext_dp_dir as '/home/oracle/backup_stage';
Directory created.
然后创建外部表
CREATE TABLE  test_cn
      (cn    varchar2(50)
       )
    ORGANIZATION EXTERNAL
      (TYPE ORACLE_LOADER
      DEFAULT DIRECTORY ext_dp_dir
      ACCESS PARAMETERS
        (
        RECORDS DELIMITED BY NEWLINE      
        )
      LOCATION ('test_cn.txt')
     );
其中test_cn.txt就是最开始所说的文本文件,在主库中执行,在备库中验证。
SQL> @a.sql
Table created.
备库中验证,发现已经能够正常识别了。
SQL> select count(*)from test_cn;
  COUNT(*)
----------
    608816
然后说说第4个问题,对这个表了拆分,怎么查询好一些。
开发提供的语句如下。
select CID from test_user_info  where login_name='?'
select SECURITY_PHONE from test_user_certification_info  where cid='?'
我们在这个基础上改进,把表的关联糅合起来,输出完整的字段匹配来,到时候提供一个完整的列表,不需要再删除也不怕。
语句如下:
select t2.SECURITY_PHONE,t2.CID from
(
select login_name,cid from acc1.test_USER_INFO
 ) t1,
(
select security_phone,cid  from acc1.test_USER_CERTIFICATION_INFO
)
 t2,TESTDBA.xianjian_cn t3
 where t1.login_name=t3.cn
       and t1.cid=t2.cid;  
但这个语句的缺点是只是其中的一个用户,目前有12个拆分用户,那么我们就包装一下,写个很简单的脚本来。
脚本1 check_data.sh
sqlplus -s / as sysdba <<EOF
spool b.log append
select t2.SECURITY_PHONE,t2.CID from
(
select login_name,cid from $1.CYUC_USER_INFO
 ) t1,
(
select security_phone,cid  from $1.CYUC_USER_CERTIFICATION_INFO
)
 t2,CYDBA.xianjian_cn t3
 where t1.login_name=t3.cn
       and t1.cid=t2.cid;
spool off
EOF

第二个脚本 check_all.sh的内容
sh check_data.sh ACC00
sh check_data.sh ACC02
sh check_data.sh ACC04
sh check_data.sh ACC11
sh check_data.sh ACC13
sh check_data.sh ACC15
sh check_data.sh ACC20
sh check_data.sh ACC22
sh check_data.sh ACC24
sh check_data.sh ACC31
sh check_data.sh ACC33
sh check_data.sh ACC35
逐个击破,对比一个大sql的效率要高了很多。
不到一分钟就查完了。当然开始还是碰到了一个小问题,那就是乱码问题,因为我们的文件是从windows传过来的。开始匹配的时候发现没有任何数据。
SQL> select '>'||cn||'<' from testdba.test_cn where rownum<20;
'>'||CN||'<'
--------------------------------------------------------------------------------
<FA7E3EF3A73E61F4F61561464C79FA7D
<586383418
<609848108
进一步分析,发现是格式的问题。
cat -v xianjian_cn.txt |less
FA7E3EF3A73E61F4F61561464C79FA7D^M
586383418^M
609848108^M
使用dos2unix格式化即可。
$dos2unix xianjian_cn.txt
dos2unix: converting file test_cn.txt to UNIX format ...
再次匹配就可以顺利得到结果了。
这种处理也可以作为一种处理大批量数据查询的一种思路,其实就是比较轻便,如果是一个常规需求,经常会有这类的查询,我们只需要替换这个文本文件即可,其它的部分可以设置成视图之类的,这些功能点就固化起来了。
目录
相关文章
|
14天前
|
存储 关系型数据库 MySQL
轻松入门MySQL:优化复杂查询,使用临时表简化数据库查询流程(13)
轻松入门MySQL:优化复杂查询,使用临时表简化数据库查询流程(13)
|
6月前
|
SQL 分布式计算 MaxCompute
PyODPS实现MaxComputer表数据把控
该脚本的最初设计目标是根据ODPS表中的不同二级分区,统计每个字段的详细量级,以便为下游用户提供数据支持。这有助于对中台数据资产进行有效管理,并能够及时关注上游数据质量问题。
905 0
|
14天前
|
存储 SQL 关系型数据库
mysql查询数据库表大小怎么操作
mysql查询数据库表大小怎么操作
|
7月前
|
SQL 分布式计算 Java
如何在 hive udf 中访问配置数据-踩坑记录,方案汇总与对比-udf中可以写sql吗?
如何在 hive udf 中访问配置数据-踩坑记录,方案汇总与对比-udf中可以写sql吗?
|
8月前
|
SQL 关系型数据库 MySQL
深入解析MySQL视图、索引、数据导入导出:优化查询和提高效率
索引是一种特殊的数据库结构,由数据表中的一列或多列组合而成,可以用来快速查询数据表中有某一特定值的记录。通过索引,查询数据时不用读完记录的所有信息,而只是查询索引列。否则,数据库系统将读取每条记录的所有信息进行匹配。索引可以根据一个或多个列的值进行排序和搜索,提高查询时的效率。MySQL索引(Index)是一种特殊的数据结构,建立在表的列上,旨在加快数据库查询的速度通过在索引列上创建索引,数据库可以更快地定位和访问特定值,而无需扫描整个数据表。索引可以应用于单个列或多个列的组合,可以按升序或。
|
10月前
|
SQL 数据库
数据库表连接方式
数据库表连接方式
|
11月前
|
SQL 关系型数据库 MySQL
【MySQL数据库基础 三】数据查询语句
【MySQL数据库基础 三】数据查询语句
83 0
|
12月前
|
数据采集 运维 Ubuntu
使用kettle进行数据的多表关联
使用kettle进行数据的多表关联
|
关系型数据库 MySQL
|
关系型数据库 MySQL 数据库
数据库学习-连接查询&子查询作业示例【带源码】
MySQL数据库 “连接查询&子查询” 习题示例,包含源码,能建立起对于连接查询&子查询的基本概念
131 0
数据库学习-连接查询&子查询作业示例【带源码】

热门文章

最新文章