父子表这类的结构，如何做些查询的优化

[skyakira]

我现在有个订单库，附表保存用户的支付信息、订单号、支付时间、订单状态等。
子表保存商品信息。

查询的时候会有针对附表和子表同时查询，例如查询状态等于待发货，并且包含商品A的订单。
这样就要写类似下面的条件。

select * from 订单主表 where 状态=‘待发货’ and exists (select 1 from 订单子表 where 商品名称 Like ‘%商品A%’ and 子表.orderid = 主表.id )

类似的结构还有很多，比如可能还会有个保存支付内容的子表，如果再加上一个必须是支付宝支付的，就要再加一个exists。
感觉这么写一旦数据量大了，会很慢。有没有办法优化这种结构，或者优化查询的方法？

[xdashewan]

为何用exists，订单表和字表不就是inner join下吗，商品名称前匹配不要加，建好索引，几张表没什么问题

[道玄希言]

where 商品名称 Like ‘%商品A%’ 这里, 如果数据量大了, 确实会慢了.

[skyakira]

引用 1 楼 xdashewan 的回复:

为何用exists，订单表和字表不就是inner join下吗，商品名称前匹配不要加，建好索引，几张表没什么问题

inner join 也可以，其实写法不重要，我就是想了解下，这类的父子结构，有没有更好的设计方案。 因为有的时候子表数据量无法控制，可能会很大。 例如主表10W数据，子表可能是就是100W，再加上其他的一些子表，这样查询起来的效率就会很低。有没有什么好的结构可以参考的。

[skyakira]

引用 2 楼 yangb0803 的回复:

where 商品名称 Like ‘%商品A%’ 这里, 如果数据量大了, 确实会慢了.

但是这种结构下，模糊查询是不可避免的。有什么更好的办法吗？

[xdashewan]

引用 3 楼 skyakira 的回复:

inner join 也可以，其实写法不重要，我就是想了解下，这类的父子结构，有没有更好的设计方案。 因为有的时候子表数据量无法控制，可能会很大。 例如主表10W数据，子表可能是就是100W，再加上其他的一些子表，这样查询起来的效率就会很低。有没有什么好的结构可以参考的。

速度慢主要是Like ‘%商品A%’，另外你结果出个几万条数据给谁看，这种数据量最后肯定得分页，要么加条件限制订单主表查询的数量，一般人也就是处理个百八十条数据，你给几千条别人都不愿意看

[kingtiy]

感觉优化的主要目标是子表的查询. 可以考虑分步查询 1.先查主表,获取一个小结果集A 2.再查子表,与A关联. 关联条件需要索引支持.得到结果B,然后对B做各种过滤 其实主要目的是减少查询的数据量.

[skyakira]

引用 5 楼 xdashewan 的回复:

[quote=引用 3 楼 skyakira 的回复:] inner join 也可以，其实写法不重要，我就是想了解下，这类的父子结构，有没有更好的设计方案。 因为有的时候子表数据量无法控制，可能会很大。 例如主表10W数据，子表可能是就是100W，再加上其他的一些子表，这样查询起来的效率就会很低。有没有什么好的结构可以参考的。

速度慢主要是Like ‘%商品A%’，另外你结果出个几万条数据给谁看，这种数据量最后肯定得分页，要么加条件限制订单主表查询的数量，一般人也就是处理个百八十条数据，你给几千条别人都不愿意看[/quote] 最终显示肯定是分页，以及显示个几十页，但是数据库的查询还是要全部查的，不然怎么筛选呀。

[xdashewan]

引用 7 楼 skyakira 的回复:

最终显示肯定是分页，以及显示个几十页，但是数据库的查询还是要全部查的，不然怎么筛选呀。

你都对主表分页了，那还能剩下几条啊，有什么好担心的，又不是整张表去匹配

[human_2000]

1、支付方式考虑在订单表上加上这个字段 2、 select 订单编号 from 订单主表 a inner join 订单子表 b on a.订单编号=b.订单编号 and a. 状态=‘待发货’ and a. 商品名称 Like ‘%商品A% 因为你待发货的数量不会太大，应该速度还可以，10W应该问题不大

[足球不是方的]

可以试试增加表的冗余字段，避免查询带来的表之间的关联。 sql语句本身优化的话就看sql的写法了，除了索引之外，join时，小表做主表，过滤数据量大的条件放右边，尽量少用like。