#51 +1

此心安处，便是吾乡。

没🐟硬🎣
这种梗早就烂大街了
贴聊天记录也不信，伪造聊天记录很难么

用时序数据库

你看上涨周期的时候，在涨到你不能承受的价格后，又继续涨了多少多长时间才开始回调

专线

1 、分道限速这个，小车你所有车道都能按最高限速跑，不是没人查，是不出事就没人查，出了事，你超速了该你的责任你跑不掉。
2 、 龙门架上补光灯这个确实很危险。
3 、 安全措施没有多余的，说不定在哪就会救你一命。
4 、 驾驶员个人素质参差不齐，你不能指望驾驶员跟你一样都是社会精英吧
5 、 慢车靠边是要看怎么定义慢车。是没达到车道最低车速？贴着车道最低限速？还是比你慢？。第一种分道限速不就是要求慢车靠边么？你完全可以闪灯提示其加速或者让行。 第二种：别人也是正常行驶，你着急就找机会超车。 第三种就不说了
6 、 高速上没有明显标注限速就是 120 ，而且有 20%宽限。导航的限速播报是即时速度和限速标志的简单对比，开车的是人又不是机器，具体情况具体分析。

这种字段肯定不会单独作为条件拿来查吧，建议和其他常用查询字段做联合索引。
#5 说的 是：1 否：rand （-30000 ，0 ）的这种做法，离散度是高了，但并不能提升查询效率，即是走了索引，该扫描的行数也不会少，如果要回表，最坏的情况还可能导致一次全索引扫描+一次回表。这和使用 hint 强制走索引一样。

实时查询就行了，没必要将汇总结果缓存吧，主要在 trans_date 字段上设计索引。如果 select 没有其它字段的话就加上 member_id 做个联合索引，直接使用覆盖索引查询。

B-tree 高度的问题，无非就是会增加读磁盘的 io 次数。在十年前磁盘还普遍是机械盘的时候是个大问题，现在都上 SSD 了，B-Tree 高度已经不是什么问题了。十年前一般建议 MySQL 单表不要超过 2 千万行，就是因为想要把 B-Tree 高度控制在 3 以下，为此有了很多 sharding 方案；现在索引设计的好，MySQL 处理大几千万到亿级都很快。

写错了？ 统计数量怎么会用 sum 应该用 count 吧
没理解根据日期做汇总结果的统计表什么意思

中

@Vesc #15 的测试有结果了吗？

#15 似乎可行，值得尝试，欢迎 op 测试后回复一下

@Aixtuz 666

@sagaxu 也不尽然，上司、行政、管理层中也有和公司签了租赁协议拿补贴的，现在他们也领不了，某种程度是同一阵线的