这些是获得所需结果的最重要表:
记录:tbl_order
id_order | id_enterprise id_branch_office | code_unique | title_product | 模型 | 尺寸 | 颜色 | 数量 | |
---|---|---|---|---|---|---|---|---|
空 | 1 | HOLA | 空 空 | X | 空 | 10 | ||
2 | 空 | 1 | HOLA | 空 空XL | 空 | 3 | ||
1 | 霍拉 | 空 | 空 | 红3 | ||||
4 | 1 | 空 | HOLA | 空 空 | 空 | 空 红 | 3 |
首先,一些批评。
- 摆脱
id_enterprise
. 而是id_branch=0
意思是"企业"。 GROUP BY
不包括所有非聚合列;我很惊讶你没有受到"只有完整的团体"的打击。- 求和最大值没有意义。
- 一个地方,"产品"是
code_unique
和位置的组合。 另一个地方,你暗示颜色等有助于区分。 OR
使得大多数索引使用变得不可能。 函数调用也是如此。
那么一个可能的缺陷:
LEFT JOIN x ON ...
WHERE ...
ON
应该说明它们之间的关系。WHERE
应该进行过滤。 但是,WHERE
可以测试 NULL 以决定是否需要"右侧"表的行,即使ON
不匹配也是如此。
对答案的猜测。
不要在不需要时使用
LEFT
。由于您似乎正在过滤
sp
和odr
. 看看这样写是否有意义:FROM sp JOIN odr ON ... [LEFT] JOIN ((other tables)) WHERE ((the filtering and any IS NULLs for the other tables))
更多
- 我很确定你不应该在内
GROUP BY
中包含sp.item_total
. 也许你应该摆脱那个GROUP BY
,相反,有SELECT DISTINCT
. SUM(IFNULL(x, 0))
可以简化为SUM(x)
。- 因为
WHERE ac.user=2
,LEFT JOIN ac
真的INNER JOIN
。 - 如果
tbl_access
具有带有id_user
的索引_starting,则查询的性能可能会更好。