(FAQ)在Apusic中间件基础上进行的二次开发‘花名册’功能数据执久查不出来
原因分析： 1.花名册功能数据来源于一个视图v_staff_query,该视图通过左外连接将30来个表连接起来，之中表与表之间通过相应的字段进行关联。各表连接的字段建上了索引。由于目前连接的表数据量并不大，执行计划显示该功能点的sql语句走索引且出现大量的表与表进行嵌套,这种嵌套分析，耗用了大量的cpu的解析时间，从而语句执行未执行完，花名册功能查询时，出现“正在查询，请等待……”。 2.后将正式机上的数据库的数据导出，导入到一台测试服务器上，将花名册功能点用到的sql语句表对应索引全部删除，删除后查看执行计划为走hash join,耗费的成本不高且耗用的cpu资源不高，然后单独运行花名册提取数据的sql语句，数据很快就提取了出来。 解决方法： 1.折中方案目前已解决了问题: 测试环境已通过折中方式解决‘花名册’数据执久查不出来问题---花名册功能点用到的sql语句表对应索引全部删除。该方案现场实施人员崔岩与项目经理张金龙已进行了验证。 2.长远考虑的优化方案: 需要中间件的二次开发人员李工将视图v_staff_query中查询出来的数据先存放在一张中间里，然后对中间表建上索引，最后花名册的数据从中间表中进行提取。 这样做的优势有二: 1).由于关联的表较多，对视图在加上条件查询时，同一时刻耗费的cpu资源较高，另外sql语句的执行计划也会随着视图查询加的条件而变动，走上嵌套关联，采用中间表则不受中间表外加条件的影响，是从结果集中取数据，提取的速度会快很多。从中间表中取数据，跟往中间表插入数据sql语句的执行计划无关。 2).随着日后业务量增大，有可能要用上表的索引。从而在业务量较大时，性能会得到提高。 性能表现： 主要表现在cpu上耗用较多时间，如下图所示: 未对‘花名册’提取数据sql语句对应表索引删除,执行以下语句的执行计划如下图所示: select * from v_staff_query_test where (zuzhilongnumber like '0000000000%') and (zuzhilongnumber like '0000000000!0018000000%') and xulibianma in ('20', '30'); 关键字 ‘花名册’,中间件