@freesun165 俺这规范就是上线前 featB 需要合并 master 推到远端，远端 master 再合并 featB ，然后就出现了这么不符合知觉的事
======
这个是你们架构师、技术总监等等没设计好流程规范的问题。

@freesun165
话虽如此，但我这个业务场景经常一个分支测一个月以上，一百多个提交，每次 master 更新，我挨个 rebase 下，成本太高了
=======
可以不用频繁 rebase ，而是功能分支要合并、发布之前集中一次 rebase 。

@GeruzoniAnsasu 这是我所有 git 项目钩子自动执行的：

git config --global i18n.commitencoding utf-8
git config --local core.autocrlf input
git config --local core.eol lf

if [ -z "$CI" ]; then
git config --local core.filemode false
git config --local core.hooksPath ./.githooks
git config --local core.ignorecase false
git config --local core.precomposeUnicode true
git config --local fetch.prune true
git config --local pull.rebase true
git config --local push.autoSetupRemote true
git config --local push.followTags true
git config --local rebase.autoStash true
git config --local remote.origin.prune true
git config --local remote.origin.tagopt --tags
git config --local remote.pushdefault origin
git config --local rerere.enabled true
fi;

@mark2025 并且线性合并的另外一个好处是 revert 时工作量低不容易出错。

@GeruzoniAnsasu 三路合并就是人多嘴杂，你不仔细查看变动就无法确定最终合并结果是否符合预期。所以基于 rebase 的线性合并在团队开发中是最高效的（ gitlab 可以设定强制线性合并）

为什么要在 featB 上面执行 featB 分支上 git merge master ？ 这就是混乱的根源
1. 要么是在 featB 分支上 `git merge featA`
2. 要么是在 featB 分支上 `git rebase master`

a -> b -> c
a -> c
两种调用链路可以设计为两个队列 topic ，以上面 4 步为基础对 步骤 3 进行扩展就行了

@mawen0726 你这个场景使用任务队列来做应该还算简单了：
1. 发布任务消息到消息队列（带执行）
2. 收到任务消息，上锁，发布任务状态消息（已上锁）
3. 收到已上锁的行任务消息，开始执行任务。根据任务执行结果（成功、失败），发布任务状态消息（执行状态，可以包含任务结果数据）
4. 收到包含执行状态的任务消息，解锁

抽象为 4 个步骤，使用任务状态值在消息队列中来流转，可以忽略 a 、b 、c 具体服务。

@mawen0726 感觉 主题 2 、3 、4 都可以合并，用执行状态键值表示 完成、终端、取消等状态

git config --global i18n.commitencoding utf-8
git config --global core.autocrlf input
git config --global core.eol lf

@zhu327 不走现有的索引而选择扫全表？

@wxw752 我公司是进销存场景，提升大概 30% 左右吧

ES 还得单独学习它的一套查询语法，没意义。
有钱：加配置；用独立主机（包括下云部署到 IDC ）
有时间：数据库分表、分库；应用拆分适当微服务化；数据库迁移为 PG
https://pigsty.io/zh/blog/db/7-week-7-db/

@aogu555 还有个 番茄仔的小窝 ，也不错

你爸的朋友介绍的人，熟个 p ，八成坑你没商量

@wxw752 以我公司的场景，分析类查询从 RDS-mysql 迁移到 ADB 的提升也没多少……

@seedhk 不建议 ES：
1. ES 需要同步。如果数据源修改增加了字段，ES 还得折腾一番
2. ES 运维成本相当高

@rockyliang 这是挖坑的方案

@mark2025 是 尤其是带条件多字段”查询“根本没法用