我对SUM的这个查询有一个问题，左边的连接在哪里，另一个在分组
我有2个表sales，它将unixtimestamp存储在saleon字段中，其他内容如roundoff，hash（二进制字段）
另一个名为sale_products的表格，该表格包含该字段sales salehash表格的产品（每个销售可能包含1个以上产品） p>
我将按照storehash＆amp; amp; theformat可能按日，月，周，年，也按日期范围过滤
这是查询的样子
SELECT Sum(sp.quantity) AS noqtys,
Sum(sp.price) AS price,
Sum(sales.roundoff) AS roundoff,
Count(DISTINCT sales.hash) AS nosales,
From_unixtime(sales.saleon, '%Y-%m-%d') AS theformat
FROM sale_products AS sp FORCE INDEX (salehash, storehash)
LEFT JOIN sales FORCE INDEX FOR JOIN (hash, storehash, saleon, status)
ON sales.hash = sp.salehash
WHERE sales.storehash IN ( Unhex(
'3963336664616338653231643462613934613430326661386339386461343163'
) )
AND sales.status != '2'
AND sales.saleon >= '1352937600'
AND sales.saleon <= '1353024000'
GROUP BY sp.storehash,
theformat
ORDER BY sales.saleon ASC;
正如您在上面的查询中所看到的那样，我可以通过执行COUNT(DISTINCT sales.hash)获得销售数量，但类似于SUM(DISTINCT sales.roundoff)的舍入中的SUM不会起作用，因为舍入值可能相同，如果我做SUM(sales.roundoff)我将获得最终的舍入值（行数*最终舍入值），这是错误的。
我看了类似SUM(DISTINCT) Based on Other Columns之类的问题以及更多但是我真的无法让它工作，我在做子查询之前也会三思而后行，特别是因为这些表会有数百万行
对于这个roundoff子查询或者没有子查询的任何解决方案都是非常合理的，如果你们有任何建议可能让这个查询更好，请告诉我。
修改：在
下添加了示例数据 sales表
+----------------------------------+----------+------------+
| hash | roundoff | theformat |
+----------------------------------+----------+------------+
| c9ec832e119f442b9b1157e643c35a0d | 0.00 | 2012-11-03 |
| 98c1b20149664e7d92b1053326fe0244 | 0.00 | 2012-11-04 |
| c3376632fc924c6fb77cb71ae0f42767 | 0.00 | 2012-11-05 |
| d0b28ea95ebc47cda4301b3b62a1552d | -0.11 | 2012-11-06 |
| eada664c47d448f4b1c31393cae6726d | 0.05 | 2012-11-12 |
| 218a8f3074284f3590343f521bc592a0 | 0.15 | 2012-11-13 |
| 1c44131c91004323b688a75158357422 | 0.00 | 2012-11-14 |
| ab4d6cfb3f1e469b9601d2f97b38ac5f | 0.05 | 2012-11-15 |
| f4958f1eec8c4c07b47a98b576382734 | 0.00 | 2012-11-16 |
| e7442dd4fedd43f59c4870142a11b982 | 0.15 | 2012-11-17 |
| 6afbfc42f69847ebad3187cb8120d888 | 0.05 | 2012-11-18 |
| a33e5715a4dc48a4a1bc4cfc67f79688 | 0.05 | 2012-11-19 |
| 5ae7a65f23204739906bb0c38dad504f | 0.00 | 2012-11-20 |
| 756c9c542e7d4d55b22cfc9280fd19f5 | 0.15 | 2012-11-21 |
| 73993c78ff814252801bbc94402f2ff1 | 0.05 | 2012-11-23 |
| c511e8d0f30149f894b9b108ff783af5 | 0.10 | 2012-11-26 |
| dd24ec0ae9ec41ff817e3c35d576e84d | 0.05 | 2012-11-27 |
| 97df779dd99640dbacaf73e6bad55445 | 0.05 | 2012-11-28 |
+----------------------------------+----------+------------+
sale_products表
+----------------------------------+---------+------------+
| salehash | price | theformat |
+----------------------------------+---------+------------+
| c9ec832e119f442b9b1157e643c35a0d | 52.76 | 2012-11-03 |
| 353045b295384eb690834733ec2ce558 | 19.23 | 2012-11-03 |
| 98c1b20149664e7d92b1053326fe0244 | 2232.01 | 2012-11-04 |
| 0c1e178f33844f26ac19b5e99392e35b | 1098.90 | 2012-11-04 |
| 0be689dca0c74ff5a672e255dc7459b8 | 1711.47 | 2012-11-04 |
| 36a6fe2c2b974cf4ba6f0afcec854962 | 1071.42 | 2012-11-04 |
| c3376632fc924c6fb77cb71ae0f42767 | 1679.09 | 2012-11-05 |
| 98583ae2de65454f84e9275389fb9235 | 371.25 | 2012-11-05 |
| e986362f1f9c4271b286c44ea9f1bdc6 | 788.43 | 2012-11-05 |
| d0b28ea95ebc47cda4301b3b62a1552d | 172.27 | 2012-11-06 |
| 9a4b8f6955924f929fc9a1db3b1ae3e0 | 89.10 | 2012-11-06 |
| 41de8af35c314cb09cf351c5e5019b28 | 134.61 | 2012-11-06 |
| 4a75c598f457419080bbce8f663c02b0 | 5373.00 | 2012-11-06 |
| eada664c47d448f4b1c31393cae6726d | 4.95 | 2012-11-12 |
| eace51feb7d247bd9c17bfe031127f94 | 199.00 | 2012-11-13 |
| 218a8f3074284f3590343f521bc592a0 | 76.92 | 2012-11-13 |
| 218a8f3074284f3590343f521bc592a0 | 19.80 | 2012-11-13 |
| 1c44131c91004323b688a75158357422 | 38.46 | 2012-11-14 |
| ab4d6cfb3f1e469b9601d2f97b38ac5f | 69.00 | 2012-11-15 |
| ab4d6cfb3f1e469b9601d2f97b38ac5f | 19.80 | 2012-11-15 |
+----------------------------------+---------+------------+
正如您在上面的sale_products表中看到的那样，有多个salehash导致多次出现错误行总和，因为sales表在每个行中保持连接状态sale_products