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

V2EX = way to explore

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

现在注册

已注册用户请登录

1 2

❮

❯

2024 年 6 月 6 日

回复了 qee 创建的主题 › 问与答 › waf 方案，哪位用过 Shieldon 的

@lupus721 一看国产还付费，我们这就有人跳出来龇牙咧嘴了

2024 年 6 月 6 日

回复了 dtgxx 创建的主题 › 职场话题 › 30 岁之后，应该做技术深度还是广度

考虑广度的可发展机会更多，东边不亮西边亮吧，但如果都是皮毛也就不过尔尔了。考虑深度的话，如果走对了路，可以走得更远更好，但反之可能进死胡同。
这个问题有点像读大学报学校报专业，如果知道自己想干嘛，那就有限选深度，如果不知道自己想干嘛，那就有限广度。至于后面的发展，看个人际遇了。

2023 年 11 月 30 日

回复了 unt 创建的主题 › 程序员 › 请问各位 PM 有没有项目管理软件推荐，适用于项目敏捷开发的

个把人用就弄个 excel 模板方便，我这边三四个人就是 excel 管理，整个公司用 OA ，以前十来个人的时候用的禅道

2023 年 11 月 30 日

回复了 qee 创建的主题 › 数据库 › jdbc 执行批量 update 的效率问题

事实证明，1.rewriteBatchedStatements 参数作为 url 的传参并未生效，pg 的执行方式还是单条导致慢，2.用 2 楼的方式使用单次 update 效率是可以接受的，不过具体的更新条目量得根据实际情况调整； 3. update case when 的写法不推荐，特别是多参数大量更新时可能出现超长的问题。

2023 年 11 月 27 日

回复了 qee 创建的主题 › 数据库 › jdbc 执行批量 update 的效率问题

@ZhanXinjia 上面就是用的原始 jdbc ；如果用这个 update 拼接的写法，单个 SQL 很长，我有点担心 sql 能否执行下去；我先得把单线程的效率干上去，才能去考虑多线程。

2023 年 11 月 27 日

回复了 qee 创建的主题 › 数据库 › jdbc 执行批量 update 的效率问题

@xiwh connection.setAutoCommit(false);然后再 commit ，这是个整体提交的事务，但是我看到最终连接后，执行再数据库的连接慢，至于数据库里面怎么执行慢的不确定了

2023 年 11 月 27 日

回复了 qee 创建的主题 › 数据库 › jdbc 执行批量 update 的效率问题

@akira 加密很快，问题在于数据库的 update 操作

2023 年 11 月 27 日

回复了 qee 创建的主题 › 数据库 › jdbc 执行批量 update 的效率问题

@cubecube 主键 id 我留了，测试表其他的索引我为了排除影响都干掉了

1 2

❮

❯