4G 不大不小
1、考虑压缩。
2、用最简单的工具，比如 QQ，云盘，SFPT
3、考虑带宽，如果 PC 端的网络带宽不够，可以考虑通过手机 4G 网络传。一般 4G 网络的上传是不限速的，快的可以达到好几 MB。

看下 order_detail 的 oid 有没有索引。没有就建一个。

终极做法是：
当用户发帖时，将最新的 ID 记录到用户表或者单独的一张表。更极端一点把标题时间都冗余了。
查询时 Join 帖子。

有效注册用户就是注册成功且身份信息真实有效，就是有效注册用户。这打官司也说的过去啊。

玩文字游戏欺负人，鄙视。
UCloud 人品不好早有体会，之前公司试用他家的云服务后最终没用他们家的，被他们的销售骚扰了至少 3 个月之久！

检查一下
cat /etc/sysconfig/clock
ll /etc/localtime
是否一致。
参考： http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/set-time.html

先建个 (name, age) 的索引吧，如果 Id 不是主键，把 id 也一块建了。

SELECT * FROM information_schema.tables AS t
LEFT JOIN (SELECT DISTINCT table_schema, table_name FROM information_schema.`KEY_COLUMN_USAGE` ) AS kt ON kt.table_schema=t.table_schema AND kt.table_name = t.table_name
WHERE t.table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'test') AND kt.table_name IS NULL

[email protected]
祝楼主出门有桃花。

我觉得这位程序员做法没问题啊，以最小的代价换得性能提升，对客户端透明，这样最好了。

而且项目既然比较赶，现在突然提出这么个需求来，客户端也会有意见，你又怎么去摆平呢？

还可以：
1. 禁ping, https://help.ubuntu.com/community/UFW#Allow_Access
2. 改ssh端口

这可以避免很多探测器的骚扰

公司有4台在上海，还好是测试用的……险啊

@yifeng
理解有点偏差，我以为表的总记录就100w哦，原来是一个月就有100w，那总记录数应该超千万了吧。
如果这样，就像上面L大说的，分表或者分区吧。

1. select语句会输出多少条记录？一次输出记录太多的话，做个分页
2. select真的有必要输出全部字段吗？
3. 给数据库分配更多内存
4. 如果有条件，上更好的硬盘。

另外，100w真不算多大的数据量
在一个150w的表上测了一下，也是datatime类型做范围查询，字段没有加索引，查询结果有7000条记录，耗时143ms

呵呵，也遇到过，比如配置的好好的桌面任务栏，忽然哪天重启之后就变形了，图标顺序乱了
我这样的强迫症怎么能忍受

还是换回Windows安逸啊。

LZ，那个小白是个女的吧，这样小白就能天天找你修电脑了……

最不能接受客服问你要密码！
遇到过一次监控误报，不停发短信邮件，提交工单也是要帐号密码，直接就放弃了……

方案B吧
需要join的地方可能就是一些列表而已，
如果真的很在意join的性能，可以建一个索引视图，毕竟更新不会很频繁吧。

满5000 - 750
满4000 - 600
如果有请各给一张，谢谢。 lenmore###gmail.com

SQL Server可以这样写的，减少一半IO：
SELECT *
FROM tbl_a
CROSS APPLY (SELECT TOP (1) name, detail FROM tbl_b WHERE id1=tbl_a.id1 AND id2=tbl_a.id2 ORDER BY date DESC) AS T
WHERE id1='1'