可以理解为是根据 user_id 做了分库（A, B, C）吗？ 如果是这样，目前想到的有下面两种做法（各有优缺点）

1. 添加一个 master 表，保存用户的分库信息 ，并在读取时加层缓存的话处理速度上不会有太大影响
2. 根据 user_id 做 hash 运算，根据结果选择数据库（最简单的 user_id % 3 )

@ibugs Nice~ 忘记 Secondary Index 的 Case 了，看来没有指定 order by 时顺序缺失是无法做保证的 也看到你这篇里的总结了 https://ruby-china.org/topics/27105

个人整理下（MySQL InnoDB (5.6?）:

• 检索时没有使用 Secondary Index 时：

  1. 按 Clustered index（主键）里的存储顺序去检索，
  2. 得到并返回检索到的数据集： <主键, 实际数据>的数据集（按照Clustered Index里的 主键 顺序返回）

• 检索时有使用 Secondary Index 时

  1. 按 Secondary Index （副键）的存储顺序去检索
  2. 得到 <副键, 主键>结果集（按 Secondary Index里的 副键（不是字段） 顺序返回）
  3. 按 主键 到 Clustered Index 里检索到 实际数据：<副键，实际数据>的数据集
  4. 返回结果（按 Secondary Index 里的 副键 顺序返回）

@ibugs :plus1:
自己也试了下，MyISAM (5.6) 确实是不按主键排序的 5.6 InnoDB 貌似是按主键排序的，但是不知道以后随版本的变化这块会不会有变化，因为到目前为止没有看到官方文档中有提到会保证结果一定按主键排序返回。代码上如果信任这种排序而省略 order by，感觉以后（MySQL）版本升级时会出现麻烦

@ibugs 这个反证还真不好找，我本地用的 MySQL innodb (5.6.21) 看起来也是主键升序

去除错误的 order by 查询，记录集默认就是按照 id 升序排列的。

没记错的话，虽然大多数情况下看起来是这样的，但实际上 MySQL 是不保证这点的（按主键升序列排序） http://dba.stackexchange.com/questions/6051/what-is-the-default-order-of-records-for-a-select-statement-in-mysql

是用 WHERE IN 查询的吗

mysql> SELECT * FROM animals WHERE id IN (9,3,6);
+----+------+
| id | name |
+----+------+
|  3 | laes |
|  6 | laxa |
|  9 | laxb |
+----+------+
3 rows in set (0.00 sec)

mysql> SELECT * FROM animals WHERE id IN (9,3,6) ORDER BY FIELD(id, 9,3,6);
+----+------+
| id | name |
+----+------+
|  9 | laxb |
|  3 | laes |
|  6 | laxa |
+----+------+
3 rows in set (0.00 sec)

很不错，项目的测试都是这么写的，这才是 Rspec 差不多同样的内容，日本的 Rubyist 杂志 (web) 里上一年也登了一篇： http://jp.rubyist.net/magazine/?0035-RSpecInPractice

@ery 其实我觉得国内在互联网这方面的技术（人才）不比日本差，甚至日本要落后一点，所以最近日本这边的互联网公司最近很流行到国内来招聘。但是国内比起国外的话，个人感觉还是整体环境的“浮躁”，大牛很多很多，但是能够静下心来把知识和经验整理一下写成书分享出去，静下心来写个东西开源出去的人还不多。

@AlphaLiu 《大规模 web 服务开发技术》这本我也在啃，来日本 3 年了感觉日本人写的书，都很通俗易懂，而且很有深度

没有人关注这个？ https://github.com/diaspora/diaspora 开源的分布式 SNS

Bundle ‘http://github.com/Shougo/neocomplcache.git’ 配置有点复杂，有兴趣的同学可以看下

等待更新期间，实在很烦的话，权宜之计是可以通过在配置文件里加行 ActiveSupport::Deprecation.silenced = true 来解决