1,订单是可以重复支付的，用户第一次用微信发现不够，再用支付宝，那么一个订单就是有两个支付订单了！！！

2,避免订单订单重复支付是前台要提供的，前台要阻塞。

所以：

1, 订单支付状态只有 0 和 1,没必要有支付中。

2, 订单和支付最好分开来，这样每个都是可溯源了

3, 后台只需要在 callback 时根据状态决定是否继续处理即可。

update payment set paid=1 where paid=0 and id=x;

根据结果再

update order set paid=1 where paid=0 and id=x;

根据结果再发送订单支付消息之类

@857681664
@icepie

你们是如何看待电视机每周几个 G 更新的？

@lmshl

全自动多次增量，mysql 同步到 pgsql 做分析，打算用 fdw_mysql 了。
找了一堆工具，都好久没维护了。也不够智能。

今年算好的拉，
我记得我刚回来有阵子一个季度也就晴几天。

@lmshl

我正在写 mysql 迁移到 pg 的，正在考虑怎么动态字段，有什么参考吗？

codeup 还不错，目前免费量足（基本功能都差不多免费且没人数空间限制）

你都 like 了，还要什么性能。

1 ，关键是索引太长，没必要，只对前面 16 或者 32 位建立索引可能性能更好。
2 ，这个级别，至少要分区了。

@outdoorlife

阿里云 RDS 上放了一个 1 核 2G 的 Mysql ，没在怎么优化，1.9 亿数据，每天几百个人用及万次查询，一个页面几个查询，打开速度几十到几百毫秒吧。

字段:
用户书籍编号（ bigint ）,章节编号(bigint),段落编号（ bigint ）,段落内容(text)，状态（是否删除 tinyint ）,创建时间(datetime)，修改时间(datetime)，用户编号(bigint)，段落序号（ smalint ）。

平时查询都是查某一章未删除段落按序号从小到大排列，而且都是 select *。。。

主要影响时间的是某个章节段落超过 1000 以上以上的会返回比较慢，或者段落排序修改时会比较慢。

平时慢查询日志，超过 200ms 都会记录，一般只有上面两种情况会出现需要几百毫秒的满查询，其他都不会。

Postgresql 选择没错的，Mysql 只能做 OLTP ，PG 可以 OLTP+OLAP ，我最近就在为 MySQL 转 OLAP 头痛。

SCRM 你搜索试试

1 ，找到一份能生存的工作，待遇少点没关系，有成长能自主就行，将本职工作做好，靠与同事关系和老板关系晋升，这是最快的途径----》借势；

2 ，在做好工作同时，打好基础，以后想当老板对自己有信心就不用再报考各类学历，但是学历对应的知识，商业知识必须学，商业实践必须有；否则就按部就班靠学历；

3 ，穷人的骨气不值钱，放下你的自尊，好好学先做人再学做事，水润万物而不争，则事可成。

去年千万大学生毕业，450 万研究生入学，你想什么？
问题是前年这个数字是 800 万，300 万。

@KuroNekoFan

血性 ---- 我理解是敢拼，愿意拼，不一定就要蛮干。

不存在不被压榨和剥削的情况，只要拿工资上班，一定会被压榨和剥削，最可怕的是没有剥削的价值。得像让自己具备被利用的价值，比关注是否被剥削更重要。

我这里的血性，可以理解拼搏精神。

@coer

搜一下，C++招聘还是很多的，我试了下 Rust 搜索结果为 0 。。。

公积金离开的时候是可以取出来的。

两者其实待遇差不太多。。。

那家卷不卷不知道呢，绩效应该都有吧，看部门和领导吧。

30 岁，
还可以卷，
我马上快 40 了，
还在卷呢，
别信他们，
一大早不卷了。

不过 PHP 这样的的岗位不多，Go 可以继续备胎，我都养了 N 个备胎了。。。

好不好找不知道，
长沙其他程序员平均工资是 10K-20K ，
C++是 15K-25K ，
当然岗位不一定多。

我也不做 C++，偶尔项目需要看下 chromium 源码而已，写个小 demo 。