V2EX › LiaoMatt 的所有回复 › 第 2 页 / 共 4 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4

❮

❯

194 天前

回复了 FlyingBackscratc 创建的主题 › 程序员 › 数据库执行=搜索时速度很快，执行 IN 搜索时速度很慢是什么原因？

@huangcjmail 底层只要是 B+树就可以这么分析, 思想是趋同的

194 天前

回复了 FlyingBackscratc 创建的主题 › 程序员 › 数据库执行=搜索时速度很快，执行 IN 搜索时速度很慢是什么原因？

@FlyingBackscratc 应该就是 sid_date_time 联合索引 sid 基数太少导致, 你使用 >=是无法利用组合索引的, sid 的基数太少, 需要扫描的页过多, 而且你是取所有数据, 还需要回表, 数据库引擎觉得全表扫描的成本比通过 sid + 索引下推 + 回表的成本低, 所以选择全表扫描

194 天前

回复了 FlyingBackscratc 创建的主题 › 程序员 › 数据库执行=搜索时速度很快，执行 IN 搜索时速度很慢是什么原因？

可能是 sid 作为索引基数太小了, 数据不够分散导致? 可以看下 optimize trace 分析

194 天前

回复了 857681664 创建的主题 › 程序员 › 抱着想写好质量代码的心，然后遇到一个完全不管代码质量的人合作，真是糟心

你们公司还招人不, 让我来吧, 这老哥的操作听起来就很迷, 很有必要做一下 codereview

198 天前

回复了 studyrun 创建的主题 › 程序员 › 一些正向作用的后门接口有没有其它的名称，直接叫后门不太好听

数据补偿
recover

207 天前

回复了 waterlaw 创建的主题 › 程序员 › idea 跑项目 build 一下修改的 Java 代码是如何生效的？

应该是用 java.lang.instrument.Instrumentation 或者 Java TI, 前者的可能性更大一点, Idea 热更新好像不能修改类成员信息, 不然会更新失败

209 天前

回复了 grayfox 创建的主题 › 程序员 › jetbrains 全家桶升级 2024 后，在滚动代码时候感觉有点掉帧

稍微有点卡, 但是总的还是变顺畅了一些

209 天前

回复了 drymonfidelia 创建的主题 › 数据库 › 求助一个排查了半年没解决的 MySQL order by 子句导致索引失效的问题， 500 多万条记录的小表要查快两分钟

@drymonfidelia 8 * 500W 就是 4000 万了- -, 你可以试着把 join 的表去掉, 看看单表查询效率

209 天前

回复了 lsk569937453 创建的主题 › Java › [ Java ]中的线程池工作原理，为什么不是先创建线程而是先往阻塞队列里塞任务？

@salmon5 Tomcat 很多其实是 IO 密集型请求, 为了降低响应时间, 这么做可以理解, 因为客户端还等着呢, 每个场景有自己测重点; JUC 牺牲一点实时性, 减少系统资源消耗, 在异步执行实时性要求不高的任务, 这个设计挺好的

209 天前

回复了 lsk569937453 创建的主题 › Java › [ Java ]中的线程池工作原理，为什么不是先创建线程而是先往阻塞队列里塞任务？

假设的有十个并发任务需要处理, 每个任务需要 10ms, 当前核心线程池是 5, 用队列的理想时间是 20ms, 不需要创建销毁线程, 如果立马增加 5 个线程, 处理的理想时间大概是 10ms, 空闲后需要销毁, 如果类似的场景很多, 就需要频繁的创建销毁, 用队列可以做到削峰平谷, 避免以上场景造成的线程创建销毁的开销

209 天前

回复了 lsk569937453 创建的主题 › Java › [ Java ]中的线程池工作原理，为什么不是先创建线程而是先往阻塞队列里塞任务？

我觉得是因为任务应该很快就可以被处理, 在队列里留存的时间很短, 所以可以先不创建新的线程, 直到队列满了表现出线程池的计算能力真的不够用了, 再启动线程去消费队列, Doug Lea 觉得这样处理适用于大部分场景吧

209 天前

回复了 drymonfidelia 创建的主题 › 数据库 › 求助一个排查了半年没解决的 MySQL order by 子句导致索引失效的问题， 500 多万条记录的小表要查快两分钟

你说的索引失效是指 C 表全表扫描了吗

209 天前

回复了 drymonfidelia 创建的主题 › 数据库 › 求助一个排查了半年没解决的 MySQL order by 子句导致索引失效的问题， 500 多万条记录的小表要查快两分钟

问题 1: 你的表有些索引的基数太低了, 效率不高, 比如 CodeStatusId, packageId, 看 cardinality 这个字段, 数字越大数据越分散越好, 如果基数太小, MySQL 可能会觉得不用索引效率更高, 建议合并或者删除一些索引; 问题 2: 都是 inner join 会产生, ,每次都要创建临时表, 做文件排序, 可以尝试通过子查询或者其他方式写. MySQL 本身提供 optimizer_trace 功能, 但是需要开启, 可以看到 MySQL 分析结果,不过 RDS 怎么搞还没弄过

212 天前

回复了 cnhongwei 创建的主题 › 互联网 › 下载了一下假的 bandizip，这种网站和软件就没有办法了吗。

这也能上钩

212 天前

回复了 dumbbell5kg 创建的主题 › 数据库 › 昨天面试的几个 MySQL 和 Redis 的题目，来请教一下

3.你认为解决高并发问题的本质是什么？
我认为是解决客户端体验一致性问题, 因为客户端不能理解为什么并发高低会影响服务, 对于客户端来说, 它希望服务端的表现不要偏离这个预期, 偏离这个预期就算破坏了客户端体验的一致性;

213 天前

回复了 unt 创建的主题 › 程序员 › 请问有没有好用的 Go MQTT Broker

@qloog 差点颠覆我 RabbitMQ 三观

218 天前

回复了 hahaFck 创建的主题 › 程序员 › WebStorm2024.1 提示错误信息这么慢呢，延迟要 1-2 秒，总感觉慢半拍

可能因为引入了行内自动补全导致资源消耗变大了