早已换了那个不能说的佳佳，不仅免费，各种插件也比这个好使

@xulolololololo 一方面是习惯问题。打个不恰当的比方，玩相机的人都有一堆镜头，大部分人只习惯自动头，但有些人也习惯用手动头。其实无论手动头还是自动头，其核心原理（透镜成像）都是一样的，不一样的是外围辅助功能。

但手动头有手动头的好处，比如便宜，买一个自动头的钱能买好几个手动头，或者同价位的手动头成像质量比自动头好。

所以你如果能习惯手动头，你眼前的世界就会比别人更大一些。但如果你只想用自动头，也可以，但最好能先彻底理解一下自动头的工作原理，否则有问题你也不知道为什么。更有可能你压根发现不了问题……

@xulolololololo 传统数据库很多你以为的筛选，其实也是扫了全表。

看上去你对数据库的工作原理不是很了解，这种情况就更应该学学 DynamoDB 这种把所有本质都暴露出来的数据库了，对你使用别的数据库也有好处

@xulolololololo 这还是个习惯问题。

DynamoDB 的目标很单一，就是快，为了快，它舍弃了很多传统数据库系统提供的功能。

就拿你说的那个排序问题为例，你觉得传统数据库是怎么实现排序的呢？无非也是两种——要么全读出来再在内存中排序，要么用那两个字段建个索引。你现在采取的是“索引法”，如果数据量不大的话，也可以全读出来，然后在内存中对结果执行排序算法。

看，DynamoDB 是不是跟传统数据库一模一样？只是把原先水面以下的东西拿到了水面以上而已。或者说，为了快，舍弃了传统数据库提供的包装。

其实这还算好理解的，个人觉得 DynamoDB 与传统数据库最大的区别在于数据的组合。传统上我们会用多表 join，但 DynamoDB 不好 join，只能多次查询。这让习惯传统的程序员很难受，如果你们公司有 code review 的话，一定被骂过查询太多，要求优化。

但 DynamoDB 不一样，因为它快，而且是 serverless 。这意味着我们可以同时发起成百上千个查询请求，让成百上千台服务器同时给我们干活。比如你要想把订单和用户信息组合在一起，那就先查订单，然后用异步 /协程 /多线程去同时查询这些订单里的用户 id 。不用怕，这比传统 join 还快，关键是不会形成瓶颈，就算某个查询慢了，也不会占着资源影响其它人。

AWS 深度用户路过，没用过阿里云的对应服务，但 AWS 的 Serverless （ Lambda+DynamoDB+APIGateway ）很对我胃口。

一开始确实如楼主所说，不符合传统开发习惯，但习惯以后再做传统项目，就觉得这也不爽那也不爽。所以这只是个习惯问题，没什么好坏之分。

不过没什么好坏之分是指的开发，若需要开发兼运维，那还是 Serverless 爽。尤其是云服务器，访问量稍微一大，就开始各种各样奇怪的毛病，很多是云服务器低下的 IO 性能，甚至是低配服务器被母鸡故意闲置资源所致。而 Serverless 就没有这些，还省个运维的人工成本（程序员免费加班兼任运维工作的那种公司不适用）

新建一个 userid 表，第一列是原始 id，第二列是目标 id，默认情况下两列一样，合并后的就不一样了。

查询时 join 这张表。

试试英文短信，我知道有些中文短信 gv 是收不到的，不知 fi 是否也这样

严格来说，你在哪里换汇，就用哪里的汇率，爬也好买也好，必须用你真正可用的那个汇率。

为啥呢？因为各金融机构之间的汇率差太大了。尤其是跨国，你在中国换美元与在美国换美元价格差了不是一点半点。

根本不洗稿，人家都注明出处的，只是没有授权，不让爬硬爬而已。
实习生确实有很多，但不是洗稿用的，而是给文章打 tag 的，否则怎么按兴趣推荐？

怕是连公司的局域网都要负责维护吧

几个月就能练出来的话，说明你底子已经很好了。可以注册个 toptal 面试一下试试

用了好几年云数据库，已经不知道该怎么选配置硬件了。

嗯……其实软件也不用配置，都是 managed service，拿来即用

实际上传指针才是主流，PHP 那种默认传值，加了&才传指针的，属于少数派

@whisky221 同意，吃亏吃多了就老实了，我现在一些特简单的功能也要调包，有时花的时间比直接写还要多一点，但可靠更重要

问：有人溺水了，请问如何抢救？
答：请看《如何才能不溺水》

26 楼 @xiangyuecn 和 30 楼 @craig 打一架吧，我看热闹不嫌事大