这种问题目前也遇到一些，也很困扰，暂时感觉无解。
暂时的做法是在自己可控的范围内，将相对稳定的模块单独维护或做系统，那些日常改动或临时急需求的模块，就写上去放在那吧。
实在是没有做详细设计和技术方案的精力了，因为第一版的需求，可能上线使用一段时间后，就会做大改版。可能和业务有关，目前是做供应链相关的，具体的一些操作模式无法直接复制，都是快速试错加迭代。
等一些大的模块相对固定了，再抽象模型来重构。

@jayzau1973 非优化过的框架里面，php 也是没有超时自动重连的吧。一般 mysql 默认连接 8 小时。以前踩过类似的坑。

简单的可以放到单独的消息里面，一个小系统来处理。这样做的好处是，多系统方便接入（不用每个系统都写一套），日志接入不侵入系统，方便后续接入其他的日志。

普通的内部信息化系统应该还没有到达语言瓶颈吧。就目前的问题，很有可能是程序上问题，可能有一些优化空间。先定位问题，如果已经没有大的优化空间了，就需要考虑换架构的事情，无非变分布式，拆分系统，分库分表等一些常见的方案，主要的方案定了之后，综合考虑语言方面的成本，性能和支持情况。

考核的东西还不能是工作内容？例如做一次分享，整理开发规范，规范 git 提交格式，引入效率工具并团队推广(搭建统一的 docker 开发环境)，梳理某个模块的文档这类？
这类算是和平时工作无关，但是有助于团队或者提升效率的。我们团队平时也会日常安排一些同学来弄。但是一般只是成员提出，leader 最终考虑后定方案和节点等，不会让成员自己定义问题和考核标准，标准也不统一。

平台不可控，政策，运营等。自建站一种满足技术人员的定制需求，可以自己折腾，不受平台限制。
现在常见的小博主们应该都是平台写文章引流进自建站吧。
各类 app 同样的道理。流量控制在自己手中呀。

@monkeydev 小团队搞这些东西投入产出比不合适。拆的过小，增加维护难度，可能多个服务是同一个人开发，小团队拆分的边界划分也是需要业务组织上分工清楚。小团队几乎没有人来弄这个东西。 不拆分，做好模块接口隔离也是可以的呀，做到底层业务模块是独立的。

主表用于新数据插入，和最近 3 个月数据的查询。
历史表可以按月等分表，每天脚本处理，从主表中筛选出超过 3 个月的订单数据，插入历史归中。
如果每天都操作，每天的处理量也就一天的数据，按每天 10W 的数据来看，插入历史表和从主表删除，即使根据单个 id 来处理也完全够用。如果要加快速度，简单的方法，分页批量操作，或者按 ID 取模多脚本操作。

内部所有机器都用的 ubuntu server 16.04 。个人 docker，线上 docker 或者线上实体机，都统一，免得各种折腾。话说接触下来 ubuntu 应该是更新这一块最快的，对新软件的支持也比较好。

可以按照前面老哥说的方法看看系统临时表的配置，查询的数据要进行 group by 操作，内存中放不下就会使用临时表。至于 file sort 可能是和你强制使用 uid 索引，order by 的又是 order_id 相关。
这部分可以参考： https://www.cnblogs.com/kramer/p/6703750.html

电信吧。 日常游戏娱乐没啥问题，特殊情况下会有一些幺蛾子，不影响日常使用。
其余的以前用过长城，一言难尽。。 移动和联通的没用过，不做评价，不过好像线路比较少，有些小区没有。

Q1NVLU1heA==
谢谢。

@chaodada 可能是查询缓存。可以发下表结构，如果 uid 有索引的话，理论上不会太多啊，单用户的订单量会有多少呢。

看表结构，如果有 uk，看情况可以使用 ON DUPLICATE KEY UPDATE 插入更新。
另外。。。推荐尽可能保持 SQL 的简单可读，赋值操作放在上层代码中解决。

如果第一门语言就是 php，转会需要有一段适应期。我大学时做的 java 和 andorid，后来工作用的多的是 php，平时偶尔会还看一些 java 周边。
如果仅是切换到 springboot 这套来开发 web 项目，基本还是比较快的。公司愿意花成本在这个上面转，还是有点羡慕的。
不过调试运维等成本会增加不少。

已收藏，不过好像有好多恶搞的数据提交。😄

能做开发还是做开发吧，测试进阶太难了，或者说环境应该更糟。

感觉可以从管理上来缓解这个问题呀。
A B C 是否是要在一次发布上发布，是的话，可以切一个公共 feature 分支 X，ABC 都合上去，使用 X 分支测试；不是话，就按功能发布顺序测试，假如是 A 先发布，就 A 分支先测试和主分支发布，B 发布前肯定是要合并主分支的代码整个测试的，有冲突也是 B 来解决。

如果功能涉及到可能冲突的，肯定要么是合并一起测试，要么是发布一个再合并测试下一个呀。

如果仅是日常开发，前后端都搞只要能熟练开发就可以了。
如果要深入了解，个人认为优先后端。前后端都做的同学，一般基础就是后端经验较多，被拉过来做前端。这种半路出家的，感觉还是在后端上深入了解。一般情况可能前端仅是在熟手的水平，还没达到细节了解，专攻前端学习成本较高。后端相比较而言，路会宽一些，go swoole java 都可以了解，运维架构方面也可以。