SELECT
model.*,
(SELECT SUM(money) FROM `wx_lianmeng_relation` WHERE order_id = model.order_id) as money
FROM
(
order_id,
ordertime,
earning_time
FROM
`wx_lianmeng_relation` FORCE INDEX ( uid )
WHERE
uid = 726080
AND `ordertime` >= 1590940800
GROUP BY
`order_id`
) as model

@chaodada 你试试这个，聚合函数和 group by 在处理同一结果集时会变慢，具体还需要看文档，总之先用 model 包一层缩小结果集吧

温两碗酒,要一碟茴香豆!

我现在 java，目前正在转 golang

所以说反射里面有获取类注释的🐎

合理个棒槌，怕不是买卖信息

@lihua 为什么要吃呢？🤷‍♀️

idea+1

我不是做游戏的，我以前玩过剑网三，3d 游戏里好像有个视距的概念，剑网三那边拉大最多也是几百同屏渲染，因为太远了好像玩家这边细节上看不清楚。
顺便问下大佬如何应用服务器转游戏服务器有什么学习路线😂

@wysnylc 有的人始终觉得复杂需求只需要反复堆积板块就能完成

先排除 CV （重点批评某平台恰烂钱文章）

优惠券表（选择类型：全部可用、部分可用、部分不可用，分别对应适用商家、适用商品、不适用商品）->优惠券适用商家表、优惠券适用商品表、优惠券不适用商品表->商品表、商家表
查询：根据用户所持优惠券进行过滤->根据下单界面商家 id 进行适用过滤->根据下单界面商品 id 和优惠券类型进行适用、不适用商品进行过滤
更新 1 （商品更新）：添加-不影响适用和不适用表、删除-不影响适用和不适用表（但需要定期处理不必要关系数据）
更新 2 （优惠券更新）：更加优惠券类型去决定影响不同的表
因为我们之前的业务是能对优惠券进行类型切换的，只需要在 SQL 中选择好表范围主体就行，加一些索引都能保持在 0.03s 上下