生产库在线添加字段当心搞出大事故
1. mysql DDL 不支持事务，无法回滚（ v8.0 好像支持了，但 mysql 无处不是坑）
2. mysql 添加字段是先把原表数据全部写入一张了临时表，添加完字段之后再改名回去。如果原表数据量非常大，那么耗时会很长……

如果你家是三恒高科技那么不要打通，否则麻烦事非常多（比如潮气）。
如果你那儿夏天最高温度超过 35 或者低于 0 度，建议不要打通。

@tianyi 帐号 -> 账号
其实古时是用帐来表示交易记录的，左边的襟旁表示长长挂起的记录交易记录的布

@bojackhorseman 拍（惊）悚（片） ～～～

@wangtian2020 统一用分页的类型，不分页就当是 LIMIT 1 OFFSET 0 的特例嘛。

@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 还有个 番茄仔的小窝 ，也不错