首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  zmal  ›  全部回复第 5 页 / 共 8 页
回复总数  147
1  2  3  4  5  6  7  8  
❮ ❯
2022-05-24 12:18:07 +08:00
回复了 tlerbao 创建的主题 › Visual Studio Code › 被 JetBrains 家 IDE 救了一命以后对 VSCode 的产生的问题。
@zeyexe 他是把暂存区的搞没了。
2022-05-23 17:05:22 +08:00
回复了 hanssx 创建的主题 › 程序员 › 琐事一则 探究北漂生存之道
@hanssx 很多时候就是这样，碰到不讲理的人，只能比他更不讲理。
我们搞技术的往往不善沟通，暗暗吃哑巴亏。op 你气不过的地方在于自己明明占理，但和对方的言辞交锋中占据下风。

这没什么解决办法，多交朋友，多和人沟通，时间长了自然学会阴阳怪气回怼了。
2022-05-23 16:48:38 +08:00
回复了 hanssx 创建的主题 › 程序员 › 琐事一则 探究北漂生存之道
其实是沟通问题，别老想用工具解决所有问题喂！
2022-05-20 10:40:34 +08:00
回复了 aguesuka 创建的主题 › Java › 分享 Lombok 一个有意思的 Issue
无解的问题。不过 jdk 已经慢慢吸收了一些 lombok 的东西，lombok 也不是不可替代。
2022-05-20 10:29:01 +08:00
回复了 wym7223645 创建的主题 › 程序员 › 多表联查 group by order by 优化问题请教
问题太多了，填完这个坑还有下个坑。op 你说的重复无意义数据其实是接口没做幂等生成的重复数据，本就不应该存在。
单从解决这个 sql 的角度来说，查询慢主要是因为 in 查询触发了全表扫描。
下策：mysql 有个 in 查询是否走索引的阈值配置，酌情调整该参数。但这个方案不解决根本问题。
中策：越复杂的查询精准分页越困难且无意义，劝说业务方放弃精准分页想法，用“加载更多”的类游标方式,每页数据不定长。去掉无意义的计算函数，去掉 groupby orderby ，子查询拆出来，在内存中分页，每次 in 查询中只查询不多于 10 条 task_id ，结果在内存中去重。
上策：提桶跑路。
2022-05-19 09:29:40 +08:00
回复了 wym7223645 创建的主题 › 程序员 › 多表联查 group by order by 优化问题请教
不要面向 sql 编程。
2022-05-16 17:37:08 +08:00
回复了 godleon 创建的主题 › Java › JAR 包上线内存消耗很大如何精准定位到问题处？
jvm 没这么傻，linux 也没这么傻。
2022-05-16 16:50:12 +08:00
回复了 godleon 创建的主题 › Java › JAR 包上线内存消耗很大如何精准定位到问题处？
运行内存和你的 jar 包大小又没啥关系···和启动参数有关。
2022-05-16 10:35:18 +08:00
回复了 linuxsteam 创建的主题 › git › 请教 cherry-pick 冲突的原因
@linuxsteam 确实不可能 cherry-pick 后忽略...不要信任同事，自己再操作一遍试试。
2022-05-16 10:29:48 +08:00
回复了 skyworker 创建的主题 › Java › 在 Java 业内, 难道多表联合查询都是复杂问题吗?
是啊，用 java 的都是笨比，op 最聪明了呢。
认真回答下：java 主流规范目前不建议多表联查，有数据规模上升后的查询效率问题，分库分表后的重构困难等。复杂的 sql 往往会耦合业务，造成一些排查难、debug 难，是非常不推荐的开发方式。ORM 框架也没往这方向发力。
如果真想联查，用 @select 写个 sql ，mybatis 也不是非要写 xml 的。
2022-05-16 10:14:27 +08:00
回复了 amirobotics 创建的主题 › 问与答 › 能推荐应该有水杨酸的洗面奶吗？
爆痘刷酸合适吗？我一般是用阿达帕林，见效很快。
2022-05-16 09:50:51 +08:00
回复了 Joker123456789 创建的主题 › Java › 关于 Java 很啰嗦的问题
@hepin1989 你知道邓草原是谁嘛说人家圈钱？扣帽子扣挺快啊？家里帽子得堆到房顶了吧？
2022-05-13 00:04:33 +08:00
回复了 lmshl 创建的主题 › 程序员 › Scala 语法糖多吗？
可以这样定义：语法糖反编译以后是另一种比较啰嗦的写法。
2022-05-13 00:02:25 +08:00
回复了 lmshl 创建的主题 › 程序员 › Scala 语法糖多吗？
非常非常非常非常多
2022-05-12 23:51:24 +08:00
回复了 Joker123456789 创建的主题 › Java › 关于 Java 很啰嗦的问题
@roundgis 微博
2022-05-12 15:26:09 +08:00
回复了 Joker123456789 创建的主题 › Java › 关于 Java 很啰嗦的问题
即使新出的语言比发展了几十年的语言更优秀一些也很正常，世界在进步嘛。

不过语法糖这个东西，并不是越多越香。开发一时爽，维护火葬场。要不要加糖是一种取舍。
2022-05-12 15:20:40 +08:00
回复了 Joker123456789 创建的主题 › Java › 关于 Java 很啰嗦的问题
转自邓草原大佬的说法：

我为什么从 Scala 转回 Java 。1 、Java 已经吸收和实现了大部分类 Scala 的语法，而且还在继续； 2 、Java 的语法虽然没有 Scala 精炼但也更严格些 (也就是没那么灵活)，但有成熟 IDE 的帮助，写起来也不慢和少错； 3 、能招到更多的程序员。最后，现在的 Java 已经足够好了，成为各种因素下最均衡的。 ​
2022-05-10 17:21:45 +08:00
回复了 Bingchunmoli 创建的主题 › 程序员 › 关于 Java 很重有感
op 最好从一个具体的场景或问题出发，不然这个问题无法讨论。
2022-05-10 17:17:16 +08:00
回复了 jiobanma 创建的主题 › 程序员 › [求助大佬] mybatis 批量更新产生死锁的问题
你对这个场景的解决方案，问题太多了。
首先，RC 的隔离级别，即使加了索引和事务，也只有行锁没有间隙锁，你在 update...where （ A && B && C ）还是会受到另一个事务的影响，极有可能导致更新错误。
其次，从根源上来说上层代码逻辑本身就有问题，不太合理。

如果你只是想解决死锁问题，加索引即可。索引怎么设计取决于你 where 条件的字段的区分度和使用概率。但这样做不解决 RC 隔离级别下的不可重复读问题。但也有可能你的业务场景和并发度不会遇到这个问题。
最好不要 update...where id 或唯一索引以外的字段，可以先 select id where..，再 update...where id 。
2022-05-10 16:54:32 +08:00
回复了 anxn 创建的主题 › MySQL › SELECT COUNT(*) 查询如何优化？
SQL 层面没什么好优化的。
1. 审视全文检索的需求到底是否必要，业务上是否可以规避，比如只允许查询预先缓存的 keyword 。
2. 用 mysql 的全文索引肯定没问题啊，你说的某个人名 5000 多条慢 90%是 IO 原因。
1  2  3  4  5  6  7  8  
❮ ❯
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   925 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 25ms · UTC 22:27 · PVG 06:27 · LAX 14:27 · JFK 17:27
Developed with CodeLauncher
♥ Do have faith in what you're doing.