憋折腾了，数据一致性是一个非常复杂的问题，不可能存在简单的、轻量级的解决方案。所以我不会去试图解决这个问题，而是针对临时性的系统故障，利用延时队列做一个简单的重试。重试成功自然万事大吉，失败了呢？失败了就人工干预好了。。。系统跑了 3 年多了，还没干预过呢

没有……

正常 select 能出来结果集就行。INSERT INTO `PMnotyet`(`LName`, `type`, `pmid`) select `LName`, `type`, `pmid` from NickNametbl where ……

@ShuoHui 不要什么都官老爷不喜欢。版权才是大头啊，官老爷不喜欢的才多少。。。

第三种增加据的维护难度和让代码变得异常复杂？？？我怎么一点感觉都无？哦哦，我是手写 SQL，无非就是查询条件增加一个 tenantId = #{tenantId}的条件而已。没事了没事了。

楼主肯定没制定技术规范，老板懂技术看不下去才插手。你要是所有字段命名都遵循一定的规范，我不信你老板会计较。

很多程序员真的是乱来的。曾经我的团队中就有那么几个，你把规范给到他们都不行，总是自行其是乱搞一通。最后没办法只好请他们走路。。。

GraphQL 的够了啊！ 9 楼才是正解。后端全给，前端要不要用随意。一般后端设计数据结构的时候是根据原型来的，给过去的字段前端不用很少见。

@richard881027 杭州用银行卡……现在不用看健康码了，ApplePay 刷卡还是很方便的

11.3，没有这种情况

我英语也很渣，在使用翻译工具的前提下，完全不影响我阅读技术文章。

阅读技术文章的难点在于专业名词的理解。也就是分开来每个词都认识，但合在一起就不认识了。这种情况下就需要进行相关知识的学习了。

@liprais 我已经说得很明白了吧？特殊情况下是需要控制的，但也不是要完全控制不能超，可以有限地超。对于前者，系统设计的代价很大，但对于后者，就几乎没有什么代价。

一般情况下，超卖只是个技术问题而已。对于销售来说，不过是把进货-销售-发货的顺序变成销售-进货-发货罢了，销售就是销售，哪来的超卖？卖的越多越好！
特殊情况下，少量的超卖也是可以接受的。譬如限量 100 件的 5 折优惠特价商品，卖出去 101 件也不是什么大事，卖了就卖了，至于要这么斤斤计较的嘛。

至于技术那种斤斤计较绝对不肯超卖的做派，销售表示完全不能理解。

比较结果和排序有关。简单滴说，数字 2 比 1 大，字符 32 比 123 大

1 天 2T 数据，最省钱省力的解决方案绝对是花钱请人搞而不是在这里发帖问。

AirPods Pro 首发用户。地铁上正常音量听歌的时候，是基本听不到什么噪音的。什么都不听，就开降噪的话，还是有点儿噪音的。

7 层的事情就应该在 7 层处理，无论它有多少问题。你妄图在 4 层处理 7 层的事情，只会导致更多的问题。

Camunda 的流程设计器用来画流程图很赞！！！必须好评

年轻就是最大的本钱，勇敢的去做自己想做的事就好。