无糖可乐

你这是想投资啊，哈哈哈，那你尽管去做，若是买房自住的我还会讲番道理劝一下。

你不问那就能，你问了，那就不能

手机本地音乐我就用 VLC 播放。现在手机存储空间够大，可以放很多音乐。

@mantouboji 你可以回复不要惊讶，不要慌，但你回复不要发帖是什么鬼

你看那些刷题的，一道题目刷了不知道几万遍了，这轮子造了不知道几万个了。然而你不会因此就不刷了，因为别人再怎么刷收获也不是你的。软件库的轮子其实也差不多，你不造个轮子就得不到它的设计经验。而且不要因为没人用就不愿动手，你之所以有动手的愿望，无非就是因为看到别人的轮子还不够圆。

意义在于早点攒够钱提前退休。

优化思路大概是两个方面：

1. 尽可能减少扫描记录数。索引和分区就是起这个作用的。
2. 尽可能减少选取字段数。首先可以的话只选索引包含的字段，其次避免选取 text 等外部引用的字段。
3. 极端情况下，可以在先带业务条件查出记录的主键列表后，做二次查询来填充其余字段。这个在分页查询中比较有用，因为第二次查询可以并发执行，所以有可能总耗时反而更少。

@yidinghe 计算用户使用时长可以简化，不用 union all ，下面是一个例子：

select
sum(
case
when end_time is null then TIMESTAMPDIFF(SECOND, start_time, now())
else then TIMESTAMPDIFF(SECOND, start_time, end_time)
end
) as duration
from acc_records
where user_id=?

这个设计的核心要素是用户的每次使用时段，所以必须设计一个使用时段表。使用时段表需要详细记录用户每次的使用时段，当用户有疑问时，你要拿这些记录出来进行核对。

使用时段表包含下面的主要属性：用户 ID 、开始时间、计费权重（如果有的话）、结束时间（为空表示正在计费中）、时长（结束时间为空时这个字段也为空）

开始计时：使用时段表新增一条记录，记录用户 ID 和开始时间。

结束计时：在使用时段表中找到未结束的记录，填入当前时间作为结束时间，以及时长。

如何实时计算用户的使用时长：选取所有已结束的记录，用 union all 拼接上那条未结束的记录（其时长为当前时间减去开始时间），然后对时长求和即可。

如果你不想扫描太多记录，那么可以给用户添加冗余字段：每次结束计时后，将所有已结束的记录合计一下，存入用户表。那么实时计算用户的使用时长，就只要从用户表取一条用户记录，再从使用时段表取一条或零条未结束记录即可。

说明你已经成熟了，开始不自觉地以旁观者的角度去审视社会。https://i.imgur.com/L62ZP7V.png

问你本地社区比较好，不同国家汇率以及品牌定价都不同，“海外”这种词恐怕太虚了。

@xuecat 耗时 double 的原因在于 UNION ALL ，所以即便用 WITH 提取出来，恐怕也无济于事。

Hibernate 的初衷就是想偷懒，想回避关系数据库，结果到了最后，发现在 Hibernate 体系里面学那么多、写那么多，依旧耗费大量精力，而且还不如一条手写 SQL 搞定。

https://i.v2ex.co/z07nEGbZ.png

虚拟线程的好处，一是降低操作系统负担，方便虚拟机自行根据硬件资源调整；二是因为减少了异步代码，可以更方便的使用 ThreadLocal 等工具。总之，它在设计编码方面带来的负担降低是非常显著的。

对数据库工具我有个要求，就是界面要紧凑，因为不论是表格还是 SQL 编辑，都希望一个屏幕看到的东西足够多，减少滚动切换。而松散的界面设计一定是会降低工作效率的。所以我更偏好密密麻麻的界面。举两个例子：

https://www.quest.com/images/patterns/ZigZag/6-column/toad-for-oracle-team-coding.jpg

https://fishcodelib.com/images/Snap49.png

那个穿山甲挺可爱的 :)

注销账户这种行为是否意味着你自愿放弃了售后权利？