前言笔者在前几个月前经历了一次因为执行DDL而导致业务疯狂打印error日志的场景，虽然不是笔者执行但是这一次经历也警惕了笔者需要敬畏生产、明确原理后再操作的习惯。希望这个亲身经历能够帮助初入职场的同学们避免因为这种问题而导转正失败的问题😊背景阐明背景表：大表DDL语句：添加覆盖索引执行时间：晚上低峰期（企业中对一些操作有严格的时间把控，必须要到业务低峰期才能执行）直接影响上层业务疯狂打印error日志（日志在企业是非常重要的）告警电话疯狂diss你表对外展示出来就是不可用，类似宕机（读和写统统被超时拒绝）可能你会说只有大表才会有这种问题吧，我如果只是几十万、几百万数据的表执行这个应该没有问...

我搜了下，春风好像是fjb？这人是脑子有问题吗？上来就恶心人

本人之前在字节iOS客户端实习，后面转后端开发，目前在一个不知名小外企上班  一、工作感受 之前也和依旧在大厂工作的朋友聊过，结合自己在大厂的工作体验，总结下来就是   平时迭代开发非常忙，一个迭代差不多两三周或者一个月，当前迭代的活儿还没干完，下个迭代的活儿就给你分好了，节奏紧，经常需要跨团队合作，工作压力很大。   我那时候是纯业务开发，写代码主要还是用if语句和for循环，用不上什么算法，项目的主要时间花在设计评审、业务理解以及各方沟通协调上，实际研发写代码的时间占比不高。   在做一个较大的需求前，要先做技术评审。类似答辩那种，先自己拟订一个设计方案，然后拉会议室请组内大佬过来，讲出你...