查询第二页、第三页 估计是数据缓存。因为第一次执行完看上去只取前10，其实是要把所有数据排序完取的。

性能影响大的是 产生物化临时表。

看把OR条件变HEAP TABLE关闭，能快点不

SELECT /*+ optimizer_or_nbexp(2) */a.id 
FROM 表 a, 表 b 
where 1=1 AND a.id = b.id 
and (instr(a.register_address, '230001')>0 or instr(a.actual_address, '230001')>0 
                or instr(b.hjdxzqhdm, '230001')>0 or instr(b.jzdxzqhdm, '230001')>0)
order by a.create_date desc
limit 0,10

按刚说的，看执行计划是否有改变，是否更快一些

看看et，应该是排序耗时，把排序消掉就行了

为什么会有这种逻辑？
instr(a.register_address, '230001')>0
这种处理可能还不如like 效率高。
这种字符串层面的遍历，最好从存储结构开始优化，否者怎么调优也不会太快。