看第二张图，优化器给你生成了一个临时的缓存在磁盘上的 View ，并行读了 8 百万行原表，把所有符合条件的行都复制过去了，最后从 View 里面选出了前 10 个返回。而第一张图之是分两次查原表，各读满 10 个以后截断，然后 Union 。

原因 1 是你这两个查询的语义本来就不一样，你的第一张图可以输出 20 个结果，且每个 sid 里面的时间排序相互独立。第二张是一共输出 10 个结果，而且是从三个 SID 结果的合集中再按照时间排序。

原因 2 是 Oracle 的 fetch first 功能是后来加的 hack ，没有很好的融合进构架里面去，它不影响默认的全局优化策略(ALL_ROWS ，这导致优化器会先忽略你只要前面几行的要求，它会生成一个找到所有符合要求的结果最快的 plan ，然后在最外层加一个附加条件来输出前面几个结果。你需要在 select 后面加/*+ FIRST_ROWS(10) */这个 hint （ 10 是需要的行数），让它进入前几行行输出速度优先模式。

原因 3 是根据我的经验，Oracle 犯这个傻也跟这个数据库的配置有关，优化器可能觉得 IO 成本很低，所以用每一个 sid 单独查（就是你第一张图想表达的模式）的那个 plan 反而被当作成本过高而弃用了。

@taotaodaddy 可能性大，要不然得训练模型记住每个 token 里面多少个字符，还得训练模型做心算。前者好像不值得花这个时间，后者还是个技术难题。

Win11 默认开启基于虚拟化的安全（ https://learn.microsoft.com/zh-cn/windows-hardware/design/device-experiences/oem-vbs ），其实你整个系统都是运行在 Hyper-V 里面，不管你有没有开启它。这个时候第三方的虚拟机软件都是在使用 Hyper-V 兼容 API ，就是在 Hyper-V 引擎上套壳，而不是他们自己的虚拟化引擎，所以不管 VMware 还是 Virtualbox 的 bug 都挺多。你不需要 Virtualbox 的特定功能的话，就用 Hyper-V 好了。

烫烫烫

就备份用的话不如一个 1T 的 SD 卡？顺序读写的话性能还不错。还可以放在皮夹里，备份随身带。

@cnbatch 我试听的时候也是这么想的，但是电话和视频会议都是实时通信，这个算法的延迟估计是接受不了，同时对算力的要求也挺高的，要有人搞出 ASIC 来才行。

真正好用的可能是老大哥储存监控录音？

这个级别的带宽应该是把网卡 IP 当成回环用形成的。可能是服务器调用本地 API 或者数据库，也可能是攻击。

你用管理员运行 resmon ，然后切换到网络页面就可以看到每个 socket 的情况，类似于 Linux 底下的 netstat.

你就是要 pt 的话为什么不买一个便宜的北欧或者加拿大 seedbox ？他们虽然线路一般，但是你是直连 HTTP/S 下载的话，流量特征就是下载，不容易触发墙的，你弄一个多线程下载软件（不要用迅雷），速度就上去了。

让我突然想到小灵通时代部分地区所有座机号码都是可以收短信的，如果接收号码不是小灵通的话，会有一个自动语音系统给那个号码打个电话，然后把短信读出来。那时候经常给同学家群发骚扰短信。

商店版是微软收购的一个团队写的，我大概 10 年前付费用他们的软件，比微软官方的易用性高很多。

但是毕竟和 mstsc 是不同的实现，缺少很多“高级”功能，比如储存重定向。但是部分功能在安卓版移植了，说明应该是放弃 WP 以后就没再开发。

@newbie111 你去瑞典一个冬天再回多伦多会马上活泼开朗起来

@mxalbert1996 蓝光碟片上的 Atoms 都是在 Dolby TrueHD/MA 音轨上加元信息的形式，显示 Atoms 就是元信息解码成功了。三星回音壁不会显示 TrueHD 的。楼主是抱怨显示 Atoms 以后没有听出区别吧

@epfoxlin 不透传原始比特流是不会显示 Atoms 的，因为元信息是在 TrueHD 比特流里面的，解码成其他音频格式（比如 PCM)再发到 HDMI 的话是不能保留元信息的。

银行入账是很慢的，而且看商户什么时候去结算，最快也要一个工作日，这种跨国的一个月都有可能，不要拿这种缓慢的信息作为判断依据，信用卡只要授权成功就可以。

也许是人家什么内部 API 坏了，在没有 eSIM 之前，实体 SIM 卡制作都是上班时间进行，很多内部流程要是坏了估计不会有人在下班时间修的。

`devices`这个字典一定程度上就是一个手搓的数据库，你这个里面要考虑的情况很多，比如：

1. 字典需要动态增删吗？不需要的话这个`Concurrent`是徒增开销
2. 字典里面的值（就是每个 Device 实例）会被多个线程同时引用吗？字典的`Concurrent`是不会管里面的值是不是 thread-safe
3. Device 实例需要 referential equivalence 吗？不需要的话建议把这个类变成只读的，每次更新的时候直接替换整个实例最安全
4. Device 与 Device 之间有关系吗？有的话你可能需要考虑如何 atomically 更新这个字典

卡拔下来重插一下看有没有改善？有的时候和主板接触因为外力碰撞会不良。

还有这种服务器用的卡在普通机箱用的话一定要加强制散热，芯片过热的话会出现各种不稳定。

三星等可以反向无线供电的手机可以算是，忽略手机功能就可以了。

现实是无线充电效率非常低，发热又是锂电池的天敌，全无线充电宝寿命估计堪忧。