🤖liuwaiting@liuwaiting

“不是数据量级的问题好么...是索引规模的问题，每张表都不一样的. 【 在 binux 的大作中提到: 】 : 1000w和2000w是一个量级的好吧。。 : 而且分表都是在设计的时候就想好了，都是按照最大可能数据量参考量级的，如果最大1000w还真不一定需要分表”

“唉，我都猜到你会这么回复了。 反正我的意思就是以2000W条作为什么mysql使用经验之谈、DBA军规什么的，都是没有依据的。 在一个大公司，这么分表不会出错，因为那里设备通常很好。 到了一个创业公司，设备可能降了几个档次，1000w可能内存都放不下了，还按照2000w分，就是瞎整。 【 在 binux 的大作中提到:…”

“无论数据库服务器现在用普遍48G、64G内存的机器。 还是4G、8G的机器。 采用2000w条为分表依据都是不对的。 而是应该根据实际表索引的测试结果，得到多少数量级的数据的索引是内存的极限。 并以此作为分表的依据。 【 在 binux 的大作中提到: 】 : 鉴于现在的机器限制，2000w依旧有意义”

“没看到这个前提？ “但是鉴于当时机器的限制，2000w的传说是有时代意义的错误结论。” 【 在 binux 的大作中提到: 】 : 如果只把mysql当做key-value来用，确实上亿没有问题 : 但是就正常的sql用途来说，2000w量级确实应该分表。文章在评论传说的时候去掉了传说的前提和背景，只评论它的结论，以此…”

“【 在 weidong 的大作中提到: 】 : 好像是付费的，我还是收藏了吧 不是付费的吧 我昨晚都下了..”

“【 在 weidong 的大作中提到: 】 : 这个怎么下载？ 第二个专辑的第一行 右边第二个按钮。”

“每个省份的绝大多数人都认为北邮的学生出来是去邮局的。”

“PM的要求是产品初始功能简单，有创意，可以快速迭代。 当时我们团队的作品是一个功能丰富，一个设想中比较完备产品。 PM总是要求我们精简，我跟她说这不是一个产品初始形态，如果要做的话，功能可以逐步实现。 PM就是无法理解为什么在设计中要出现一个相对成熟形态的产品。 RD的想法是：我要实现这个产品，具备了那些功能，怎样一步…”