我的同事 “就看看” 用 vi、vim 我肯定白他两眼，哪怕他是资深运维……也有可能手残犯错，更别说不熟的人了，不小心改动个地方，一慌就给保存了，后面查问题要查老半天，关键他还可能啥也没意识到~就算不慌，也可能留下个 swap 文件在那里，别人编辑的时候一脸懵逼，为啥不从一开始就用稳妥的方式呢~

待办有点单薄，还可以把会议安排啥的都搞进来

照着 coding 做的吧

我是认真的，最近半年多在找工作，发现无论业务开发用 rust、c、c++，还是用 go、java，招效能、测试相关的都必须会 python，结合 AIGC、大模型的兴起，估计以后要么就是用 python、ts 之类的语言处理简单的本地问题，要么就是钻底层、搞计算机尖端研究，学 java 终究是错付了

转 python 吧，python 菜是主流

insert select 跟你的 py 程序一个道理，如果你使用分批次提交，速度肯定会有所不同，毕竟 100w 数据结构化之后交给 mysql，一次性写入还是对 db server 配置有点要求和压力的，如果缓冲区/内存不足可能就会走 swap……balabala，function、procedure 同理，都可以分批，参考：https://www.yzktw.com.cn/post/932913.html

其实你这个比对本身给人的感觉就是，只给了结论，没有深入揭示背后的原因，像 dba 配置、插入方案差异、程序写法差异、不同数据量的差异……甚至最后可以扯皮扯到像 19# 陈大猫提到的不同语言、不同 jdbc 驱动的性能差异，不过没啥意义了，语言鄙视链毫无意义，毕竟业务场景决定一切

那应该是 mysqlimport 的参数了

很显然文件导入的方式，mysql 自动用了并行处理，默认线程数我猜应该是用 innodb_write_io_threads 这个参数的值，你 load data 的时候可以试试--user-threads=1 和 16 分别试试效率咋样
procedure 和外部程序，不管 python 还是 go，你自己用单线程循环，怎么快得起来，你拆 100 线程试试

趣玩？TT 语音？

4、先认人才是重中之重~能帮你高效解决 1、2、3 的问题

UI 自动化测试平台，感觉在当下的技术发展水平里，做多好都是乐色，专心做性能、接口、皮下测试的平台还有丢丢价值

推荐 coding、teambition、tapd，其他的不够看

考研，别做 IT

深有同感~

这么严密的条件都能被你扯来扯去，也是服了

线上 bug 作为考核 KPI 最合适不过，难道你们就喜欢用例数、测试环境发现 bug 数量、加班时长这些指标？
喷天喷地喷空气不如你给个更好的办法？
或者说，各位喷来喷去……都没看到 “线上” 二字？

只是因为他学会了用 GPT 帮他写代码而已~

每秒钟只能处理 3500 个请求，那么 TPS 就是 3500，管他响应时间是多少呢，废条件~
如果并发是 3500，响应时间 200ms，那么 TPS = 3500 * (1000 / 200) = 17500

很难想象，还有 vue 页面写下去不是复制修改，而是从头来过的，所以除了 svg previewer 感觉都没啥用

本来不想杠你的，但是我看还有人点赞，觉得有必要举个例子给你们琢磨一下：
不说银行，银行太复杂，就说保险吧，至少会包含这些最基本的模块：

• 新契约签单，承保并且生效之后，保单、责任条款之类的数据持久化落库
• 保全变更，比如受益人变更、联系方式变更、退保等等，操作的还是这批数据
• 理赔，这个不用我解释大家都懂，操作的还是这批数据
• 渠道佣金计提，字面意思，操作的还是这批数据
• 财务，字面意思，操作的还是这批数据

……以上所有数据没操作一次都要可追溯，供稽核和监管审计，而且很多很多操作都会影响后续的操作，比如健康险理赔一次之后，第二次理赔，费率不一样了；车险理赔之后次年的保费也会不一样；分红险分红过后保单价值也会随之发生变化……

如果你来设计，是准备把这些服务独立，操作数据向其他服务去冗余呢？还是说放到一个服务里面，一旦服务不可用，所有的业务都不要开展了呢？
依据你给出的设计，你再思考楼主的问题，可能就更容易得出解决方案了，至少我没有勇气去考虑改变系统纠缠的问题

单测 mock，集成 mock，系统级测试参考 4 楼……不过 4 楼只说了应用层，金融系统 DB 有可能都是多应用共享的，这个更麻烦，对造数的能力要求比较高
具体怎么搞，其实还是要看你们的系统群的架构设计，包含系统间交互方式、数据管理方式、安全管控等等因素，给不了什么有价值的建议……

金融类系统，十几甚至几十个都正常，7 个小场面

当然要解决问题……除非你说的问题是 BUG 本身……

刚毕业那会，我在神州数码西安，领导安排我负责国开行的项目，帝都过来一个架构师，每次开会就是对我们的测试指指点点，项目经理也不好意思出声……我离职大约 1、2 年之后听说那哥们在帝都总部门口被同事揍了，当时听起来可痛快了，再过段时间回忆那个架构师说过的话……好像也没啥不对的，好像也只是说有更好、更快的方法而已……

题外话：最好不要相信 GPT 给你出的测试方案，如果大家都愿意相信，那么灾难就开始了~

标准做法：
1、创建 proxy-server
2、录制操作，记录操作的 node（功能点）和数据
3、根据记录结果，使用 canvas 生成有向图，提供一套 GUI 的操作途径，前端也可以手动断开某些 node 之间的关系，或者添加逆向操作关系等等
4、根据 BFS 遍历图，生成流程 case 列表
5、手动再次裁剪明显无效的 case——至此，自动化创建 web api 流程测试已经完成
6、造数工具或平台给录制的每个操作 node 在不同的 case 里分别生成测试数据
7、运行测试，拿到结果
8、附加题一：对于 springboot 这样的应用可以配合 swagger 之类的工具，静态扫描 web api 的 url 和代码文件的映射关系，然后每次测试只需要拿变更集文件清单就可以逆向推导出哪些 node 需要测试，然后在前面说的有向图里面 pick 出这些 node，临时自动化创建 api 流程测试的 case，拿到数据……跑起来，新增 web api 如何处理？每次运行之前都扫一次 api 列表就行了，发现新增的，自己手动去图里添加 node 和连线……
9、附加题二：自动化性能测试的应用、测试环境监控的应用、移动端的测试应用、测试结果（发现 bug 比重）评估……等等等等~