没有这样用过，不过从 innodb 存储特性看，这种做法非常不可取，如果数据量很大，可能导致严重的性能问题，主要原因有：

1. innodb 的非主键索引都将存一个主键，uuid 相比整数 id，索引大小增加很多；
2. uuid 主键比较肯定比 整数慢，另外非主键索引查找最终还要引用一次主键查找；
3. innodb 主键索引和数据存储位置相关（簇类索引），uuid 主键可能会引起数据位置频繁变动，严重影响性能。

#106 楼 @gerald 在招啊，马上联系你。

#104 楼 @hegwin 薄荷的老用户了，非常欢迎！话说薄荷的很多业务部门员工都是薄荷的用户哦

#96 楼 @felix #97 楼 @ery #98 楼 @hlxwell #100 楼 @yaoyi011 招聘还在继续，年后正是换工作的好时机啊，欢迎自荐或推荐

新年快乐！

今天晚上的 RubyTuesday 我来给大家分享“薄荷 Ruby on Rails 缓存实践”，正在做 slide，内容大概如下，欢迎捧场。

刚刚订阅了，很棒！

#91 楼 @shangrenzhidao 哈，欢迎来坐一坐。

#90 楼 @nomospace 非常感谢！欢迎再来我们新办公室坐一坐，现在一点气味也没有了，还多了不少装饰，哈

看 ruby 源代码啊

#5 楼 @Peter 对整个文本做 base64 encode，读取的时候再 decode，就在 model 里做修改就好了。如果要兼容原有数据，可以增加一个 text_format 字段，里面存放文本格式，只有 base64 格式的文本才需要转换。我们就是这么处理的。

还有一种方法可以是用 blob 类型来存文本。

如果不好升级调整数据库，可以 base64 后再存，读的时候再转换一遍

#7 楼 @layerssss 速度还挺快的

#76 楼 @chunlea 哈哈，那天我实在太忙，招待不周，请多包涵。

#74 楼 @shangrenzhidao 这么巧！网站已经很久没有更新了，现在重心在 app，随时欢迎来薄荷。

#72 楼 @shangrenzhidao 别光顾看妹子啊，说来我们其它方面也还不错的，哈

好文！程序逻辑错误一定要及早暴露出来，而且是在发生问题的地方直接暴露出来，这样能避免日后花费数倍精力查找问题和弥补错误的麻烦，这一点在开发中深有体会。

可以考虑这样操作：先把数据导出成数据文件，建立好目标分区表，然后把数据导入，重命名表。

这个方法是 mysql 下的经验，重命名表在 mysql 下很快，我对 pg 不太了解，不知道在 pg 下怎样。

好文，👍

做统计数据，数据表实在太大了，通常要组合下面的方法

1. 正确的索引设计是根本，而且简单有效，立竿见影，无论后续方法是否采用，索引先弄好再说；
2. 使用单独的统计表，使用统计表大幅加大数据粒度，利用业务低谷时间预先计算，再做数据查询就简单高效多了，而且减少对明细数据表的影响；
   1. 分表，按时间或者地区或者用户等分成多张表，这样有利有弊，好处是提升某些查询效率，坏处是使用方式要复杂不少，需要自己权衡。

#61 楼 @gothic 其实我们最急缺的是 web 前端啊

user_id 和 timestamp 已经加了索引 是单独建索引还是联合索引，联合索引和单独索引差异很大。

如果建立 [user_id, timestamp] 的联合索引，应该不至于这么慢。

另外，为啥要 distinct 的，这个操作对数据库通常是要命的。

这是薄荷设计师妹子在公司墙壁上写的代码 -- 你爱或不爱，我都爱你，至死方休！

今晚我也去凑热闹，@robbin 出马，必定很有货，哈

#47 楼 @outman 哈，上海的确有不少吸引人的地方，可否考虑来上海发展啊？

没有删干净，偶之前也遇到过，需要手动配合一下 1 手动把 /usr/local/rvm 给删掉 2 检查启动初始化脚本中加载 rvm 内容，清理掉 3 删除 .rvmrc

#45 楼 @terencege 非常欢迎！：）

如果还想更快的话，一般还要建立一个按日的统计表，然后每天凌晨跑一次数据，查询直接查统计表，引入的新问题是当天统计数据在统计表没有体现，如果需要要额外想办法。

为 captrueTime 加上索引，保准立竿见影

#13 楼 @cassiuschen 的确和数据分离解决问题思路有点儿类似，但还是很大不同，这里相当于异构数据库（NoSQL 和 SQL）的数据聚合，历史数据分离通常还是在同一种数据库中进行。