@freefcw 我目前测试的最多数据差不多1200万的样子 自感亿内没有任何问题 再多分表 可能10亿行单条4K数据都不是问题吧 膨胀度对比MYSQL来看是3－5 纯文本的话应该小于6

这是英文的 中文要再扩大一倍

用起来的确狠不错 做垂直搜索的利器

Love of my life 最喜欢这个 波西米亚狂想曲倒没太大的感觉

为什么我觉得他们象拉拉？

其实可以用google charts做 但是这个API好像有时候是被墙的

午夜俱乐部以后会是最抢手的帖子啊 安全获得铜币

回复耗费5 感谢耗费10 被感谢也是10 收到回复是5 创建主题是20

也就是说 发个贴子至少要4个回复够本 回复最危险 不被感谢就是亏本的

如果不能调动感谢的积极性 那回复岂不是很危险？

经济总量没有增加 广大水军不能得到系统发展的收益 金融系统有待探讨吧

这种静态的平衡很危险 非常容易早就大地主 大资产阶级 最终形成门阀 贵族

@weakfox 别人的回复有钱赚哦 正好是回复者的花费 我懂了 马上有穷人和富翁了 要劣币驱逐良币了 等着看

测试下回复

@paloalto 记得感谢我下 我花了15个铜币来回复 怎么才能增加呢？

@paloalto 关键是一般不用apt-get来管理centos包，rhel系列还是用yum比较好些

交叉使用不是不可以 只是会有很多的不兼容吧

centos不是yum吗？

@clowwindy 只用key查询 速度还是不错的 但加上任何条件就不行了

毕竟mysql部署成本极低 迁移到别的平台难免有这样那样的问题 我最多用到的才1.2亿条 mysql尚可满足需求

@avatasia @leiz

Table:
id primary
abbr unique 96
name string 128
meta string 512

1610000行数据

select count(`column`) as `count` from `table` limit 1234567,18;
select count(1) as `count` from `table` limit 1234567,18;
select count(*) as `count` from `table` limit 1234567,18;

1最慢，2 3 基本一样的速度

slect * from `table` limit 1234567,18;
slect `id`,`abbr` from `table` limit 1234567,18;
slect `id`,`abbr`,`name`,`meta` from `table` limit 1234567,18;

2大约是1 3的0.6时间
1 3 没有明显差异

应该就是stackoverflow的说法，如果超过2/3字段需要用到 那就使用*好了 如果不是考虑指定字段

不指定任何查询条件 where 1与空where没有观察到差别

话说回来 只查ID的情况数据比较多可以考虑ID和别的关系单独做个表 那样更快些 反倒是空条件数据比较多是个麻烦 limit a,b还是不够快

因此我觉得除非需要的字段很少或者数据量大的足以阻塞通信 * 永远是个不错的选择

我用到的都是所有字段差不多用完那样子 select * 查询分析器应该没问题吧

http://stackoverflow.com/questions/3639861/why-is-select-considered-harmful


对select * 这么有信心， 应该是select count(*)以前感觉比较快
http://stackoverflow.com/questions/8221729/mysql-select-count-or-select-1-pdo

所有这些我会在玩些时候测试个150万的样本看下

以便彻底解决掉这个问题

期待分享 我的数据库都很小 正需要大数据库的经验分享

Debian的apt-get很好

收回上述言论 应该是这样子的
1000万表有11G大小 则5万有45M左右 一次处理这么大量的数据导致mysql通讯或者php部分处理过慢导致效果不佳 只取一个列 查询慢一点 数据量小的多 才造成这样的现象

我觉得可以从机器学习的角度考虑

对应着比如垃圾邮件就有比较成熟的方案，傅立叶级数筛选什么的

具体参考ruanyifeng.com的某一篇博客，有不错的入门介绍