面试官 核心意思是：我是你领导，不是摆设，你搞不定可以来找我，自己在那里瞎折腾个啥
这是个控制欲很强、对细节很在意的面试官，好坏不便评论，反正不是个吃白饭的就是了

想避免很简单，不发布就可以了

为什么拒绝新鲜血液 + 排外

典型的狗咬吕洞宾，不识好人心……我不做测试很多年了，我真心奉劝那些觉得测试 “轻松简单” 的人不要去做测试，原因有二：

• 这么想的话，过个几年你自己就要面临垫底、被刀，你职场能力再高……你是老板亲戚当我没说
• 不要把测试行业平均水准拉底了，这个职业现在什么样不说，以后真的不需要太多低端执行者

当然，哪天资本家觉得这个世界需要慢节奏、需要 peace 了，还有人劝你不要做这不要做那的，那他肯定是坏

无关责任不责任、到位不到位，就是没有把流程规范固化到平台、工具上，用工具在流程中做好检查和卡点。

自顶向下只追一个顶端数据，后面的所有步骤自然而然的卡死，不给偷懒、犯错的机会，这就是理想的操作。尽可能避开需要人的思维意识去干涉，这样大家按部就班，都不会累……

所以我上面针对代码提交规范就提了一嘴 commitlint，我对原文中只提 “规范” 二字表示不以为然，这些必须东西要有足够的客观约束，而不是靠人自主去遵守或执行……当然，流程规范是源头、是根本，没有这些的话，后面做的一切都可能会被质疑。

代码提交规范：在提交代码的时候，需要描述清楚提交代码的作用。

commitlint 了解一下

我的同事 “就看看” 用 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 感觉都没啥用

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

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

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

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