东方姐姐说，有人的地方就会有恩怨。
我眼里，大到社会、GJ，小到群体、圈子，只要人多了就会有管理和被管理关系。这个圈子也会随之管理人控制的方向发展，有人对管理不服就会分裂，竞争。时间长了，不咋地的圈子就会沉寂消失，另一些则壮大，然后重复这个过程。

这是个自然的循环，看开了就好。

@peterwang 抱歉啊，我想肉身去欧美。

@kn007 比如在 filesort 的情况下，你 limit 10 offset 5000，必然需要找到前 5000 个才能找到这 10 个，handler_read_rnd_next 就成了一个无法跨越的硬伤。
那问题应该是如何避免 filesort。至于索引，该不该用还要看具体情况，尤其海量数据要谨慎使用索引。
按你的说法，1G 数据，lastupdate 还不到 30 个，活生生触发 filesort。那这个排序在需求上是有必要的么？很有可能是可以规避的，要看具体需求。（如果30个数量比较均散，可以考虑弄个 update_id，先 where 一下，就算触发 filesort，handler_read_rnd_next 也会很小；另一种情况比如这 30 个是最近修改 30 个，那可以考虑弄个 modified 字段）
总之，就是各种手段规避 filesort，如果无法规避，那么应该尽量减少候选结果集。具体方案没有什么套路，有的地方会用timestamp做主键id，有的地方（尤其是地理数据）会把数据拆表存放。

count 的问题，没必要因为这个换 myiasm，精度要求不高可以缓存，要求实时准确，则考虑触发器。
先 sql 再 php 的话，除非数据很小，否则不建议。

我不是 mysql 专家，但是 条件+排序+offset，这种情况，就算有争对性 index，filesort 应该是无法避免的。offset 引发的大量 handler_read_rnd_next 更是一个问题，大并发下会拖垮整个数据库性能，你会感觉到随着并发量上升后，并发量和数据库查询耗时几乎是线性关系。
针对建议数据库逻辑，可考虑的方法如：使用缓存表、使用簇集（主键）索引代替 order by 和 offset。具体就看业务逻辑了，没有通用办法。
并发量足够大的话，使用缓存是必须的，但是不能因此回避数据库的优化。

@kkxxxxxxx 我圈子里都知道我是个游戏毁灭者。。。哈

听。。。。。力？

@lll9p spf 主要是用于验证，对垃圾过滤作用很有限 。

貌似HR他们没人在意这些，但是我干过，发现容易进垃圾箱。

@bleakwood 感谢提醒，mitbbs 的确是个好地方。另外我不是强调去三流学校读博浪费时间，是觉得相对不值，毕竟老大不小了，读博不敢耗着玩。

@hahaluluwa 想去定居

@lbj96347 坑爹了，不能改帖子内容。。。

@hardware 另外也不是要创业公司，大公司我是怕高攀不起。

@hardware 明白，打算在博客里整理出单独的 portfolio。

这是我的情况， http://v2ex.com/t/172107 还没有来得及进一步准备 resume。