Ruby China
  • 社区
  • 招聘
  • Wiki
  • 酷站
  • Gems
  • 注册
  • 登录
吕小荣
@xiaoronglv
管理员
第 1638 位会员 / 2012-03-29

workstream.us
上海
198 篇帖子 / 1617 条回帖
236 关注者
0 正在关注
17 收藏
社区清洁工
GitHub Public Repos
  • xiaoronglv.github.io 4

    Ryan's Blog

  • golang-ent-playground-... 0

    https://entgo.io/docs/getting-started

  • surge-rules 0

  • docs.nestjs.com 0

    The official documentation https://docs.nestjs.com 📕

  • clash-rules 0

  • chinese-independent-blogs 0

    中文独立博客列表

  • express_projects_with_... 0

    Good open source projects powered by express.js

  • xiaoronglv 0

  • CKA-Exercises 0

    Practice for the Certified Kubernetes Administrator (CKA) Exam

  • CKAD-exercises 0

    A set of exercises to prepare for Certified Kubernetes Application Developer exam by Cloud Native...

More on GitHub
  • 概况
  • 话题
  • 回帖
  • 收藏
  • 正在关注
  • 关注者
  • [已解决] select count (*) from table_name 为什么没有使用主键索引? at 2015年07月08日

    感谢 @zgm @serco 以及炮哥的解答。 :plus1:

    我以前彻底的混淆了这两种查询的处理流程,他们两个查询时的策略完全不一样的。

    1. query 1

      --  ms 级别
      -- token 已经加了索引
      select count(*) from devices where token="xxx"
      
    2. query 2

      select count(*) from devices
      

    Query1

    在 Query1 中,mysql 会考虑 devices_token, devices_token_prefix_index 两个索引,最终选择了 selectivity 最高的索引 devices_token。

    这个查询是 ms 级别的。

    Query2

    在 query 2 中,MySQL optimizer 会考虑使用以下三个索引:

    • primary key 是 clustered index,是所有索引中最大的一个。在这个查询中,无论如何也不会用它。(largest)
    • device_token 是次大(larger)
    • device_token_prefix_index 是(large)

    device_token_prefix_index 体积最小,所以会优先用它。

    结论

    在 InnoDB 存储引擎中,primary key 是 clustered index(最大的索引),使用它来处理 select count(*) from table_name 最慢。

    新的疑问

    但这样牵扯出一个新的疑问:

    除了 constant table,所有的 select count(*) from table_name 都是一种低效的查询,是这个样子吗?

    @zgm @serco @hooopo

  • [上海][2015年7月14日] Ruby 聚会召集 at 2015年07月07日

    #8 楼 @ericguo 👏

  • RubyConf China 2015 将于 10月10日-11日 于深圳举办 (内附讲师征集链接) at 2015年07月07日

    :plus1:

    去深圳看望多年的老基友 @_samqiu

  • [上海][2015年7月14日] Ruby 聚会召集 at 2015年07月07日

    :plus1:

  • 单表继承问题 at 2015年07月06日

    楼主,慎用 sti,后期维护特别头大

    有时候多态是个更好的替代方案。

    http://railscasts.com/episodes/394-sti-and-polymorphic-associations

  • [上海] SAP 招聘 Ruby 高级工程师 at 2015年07月05日

    #8 楼 @_samqiu

    我不是高级工程师,只是发个帖而已,兄台无需震惊。😃

  • 参与开发的 ruby gems 的下载量破五百万了... at 2015年07月04日

    :plus1:

  • [上海] SAP 招聘 Ruby 高级工程师 at 2015年07月04日

    占个楼,备用。

  • 采用视图减少 Rails 底层的复杂的表连接操作是否可取? at 2015年07月02日

    视图无法创建索引。

  • 求问,成都的 Ruby 工作行情如何? at 2015年07月02日

    #22 楼 @hanluner

    当初我投过 tower.im 简历,和他们技术负责人聊过。团队像个大家庭,人人都很友善。大家的技术也都不错,彼此互相学习。薪水给的也很高,远程办公。

    我觉得是个挺吸引人的团队。

  • 求问,成都的 Ruby 工作行情如何? at 2015年07月02日

    推荐 彩程,很不错的公司。

    https://tower.im

  • [上海] Xinmin Labs 招 Ruby 程序员 at 2015年06月30日

    👍

  • Rails 用了三个星期,但是感觉好不爽啊 at 2015年06月27日

    这是个生态系统,需要掌握的东西很多,楼主慢慢来,不要着急

  • [上海][问] 在 Strikingly 工作是一个怎样的体验? [答] 再也回不去的感觉! at 2015年06月21日

    离职人员说的才是实话。

  • Homebrew 作者被 Google 鄙视了… at 2015年06月13日

    我又在知乎上看到一个关于 Google 面试流程很详细的解答

    跟别的大公司一样,狗家是不会在拒绝了面试者之后给出具体理由的。连是不是面试本身的原因都不会说,更不会说是哪一轮。狗家的流程里,面试官是很难一己之力毙掉一个候选人的,除非你那一轮真的很烂。全部 5-6 轮的面试官的评价都要送到 Hiring committee 那里,然后 HC 会看每一轮的详细记录来做决定。当然,如果某一轮真的很屎,那单独因为一轮挂掉也是很正常的。

    总之 Max Howell 本人其实并不知道他是怎么被拒的,除非他某一轮真的面的特别屎。

    其次,invert binary tree 是个什么鬼?简单的左右翻转?那这还真是面试官放水了,或者就是偶尔会出现的热身题。我见过的热身题都比这个难多了。二三十行的 CS101 水平的题目任何哪怕没有专门准备过面试题的人随手写也是基本素质。所以如果真的是这么一个左右翻转的题没搞定,那确实被拒合理。拿这个案例批评白板面试和算法面试都是不合适的,更合适的例子多了去了。但是 Max Howell 做不出左右翻转是一件很奇怪的事。所以,或许题目并不是左右翻转?而是以某一个 node 为轴,轴对称旋转从树变成图?那作为面试题确实太难了。这种时候可以落井下石骂狗家魂淡。

    所以我在想,Max 真会扯犊子啊。

    http://www.zhihu.com/question/31187043

  • Homebrew 作者被 Google 鄙视了… at 2015年06月13日

    人家 Google 本来就看中算法,被拒只是说明彼此不合适,也不至于如此生气吧。

    我倒觉得 Max 自尊心好强啊。

  • 元编程中的环绕别名 (around Alias) 使用场景是什么? at 2015年06月10日

    #5 楼 @hooopo :plus1:

  • 元编程中的环绕别名 (around Alias) 使用场景是什么? at 2015年06月10日

    #1 楼 @hooooopo

    炮哥,能说的清楚点吗,不太懂。

    :)

  • [上海][2015年6月9日] Ruby 聚会召集 at 2015年06月09日

    #27 楼 @hemslo

    👍,辛苦了

  • [上海][2015年6月9日] Ruby 聚会召集 at 2015年06月08日

    谁能带个投影仪啊?

  • [上海][2015年6月9日] Ruby 聚会召集 at 2015年06月07日

    #11 楼 @lithium4010

    只要能投影就行啊,你可以带来吗? 👏

  • Redis 实战之薄荷 timeline 的优化 at 2015年06月06日

    大牛

  • [上海][2015年6月9日] Ruby 聚会召集 at 2015年06月05日

    请管理员置顶,多谢。 😏 @lgn21st

  • [上海][2015年6月9日] Ruby 聚会召集 at 2015年06月05日

    @luoping0425 罗平,你来吗?求带投影仪,哈哈。

  • 高手对决 -- 博客服务器被黑的故事 at 2015年06月03日

    我的 VPS 今天也被黑了,郁闷。。。

  • 缓存使用的 N+1 问题 - 缓存使用陷阱 1 at 2015年05月27日

    :plus1:

  • Rails 5 - 将会有更快的 render collection 以及优化小细节 at 2015年05月26日

    其原理是不是把 n+1 的 cache 查询减少到 1 次查询?

  • 吐槽一下 railscasts-china at 2015年05月21日

    terry 也结婚了吗

  • 上一页
  • 1
  • 2
  • …
  • 16
  • 17
  • 18
  • 19
  • 20
  • …
  • 47
  • 48
  • 下一页
关于 / RubyConf / Ruby 镜像 / RubyGems 镜像 / 活跃会员 / 组织 / API / 贡献者
由众多爱好者共同维护的 Ruby 中文社区,本站使用 Homeland 构建,并采用 Docker 部署。
服务器由 赞助 CDN 由 赞助
iOS 客户端 / Android 客户端 简体中文 / English