一次统计查询优化,并且残留疑问
2020-08-26 本文已影响0人
甘子的桃大哥
一个报表查询中,关联查询异常的慢,并且都建有外键索引。
先展示下sql条件与耗时以及触发的索引。
优化前:
耗时久,A表是收费表,条件是收费表结算时间

触发的索引内容和性能等级

优化后:
结算时间改为社保结算表的结算时间(和门诊收费表有对应关系,结算时间一致)


由于底层基础不够扎实,目前的优化思路与理解来自:

个人思路:由于收费分社保和非社保,自然社保结算表数据相对较少,并且主业务是查询社保结算。因此社保表优先,而关键条件确是收费表来关联,所以改为社保表的结算时间。减少了收费表与社保表的扫描行数速度得到提升。
疑问:个人理解是否正确?sql中u表是用户信息表关联条件并未改变,却在这次改动中索引类型得到提升:eq_ref