#10 楼 @ibugs

你举的这个例子：

mysql> explain select SQL_NO_CACHE id, publish_status from cd_happy_for_ni_deals where update_time = '2014-05-17 23:00:48' \G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: cd_happy_for_ni_deals
         type: index
possible_keys: NULL
          key: idx_of_publish_status_update_time
      key_len: 17
          ref: NULL
         rows: 1928113 <- 只查询update_time 的情况
        Extra: Using where; Using index
1 row in set (0.01 sec)

我猜，你这个表的总行数就是 1928113。

这是一个全表查询，并没有用到索引。可别看它的 type 列 为 index ，其实和 ALL 差不多。参考：https://dev.mysql.com/doc/refman/5.1/en/explain-output.html#jointype_index

possible_keys: NULL 表示 确无索引可以使用。参考：https://dev.mysql.com/doc/refman/5.1/en/explain-output.html#explain_possible_keys

#6 楼 @msg7086 对对。性能评判的标准很重要哦，我们需要找一个科学点的评判标准。用 count(1) 的做法，我找不到可以认为它是平均时间的依据。 @ibugs 。

我以前除了看 explain 之外，还会用 profile 。虽说只是单次的查询，没办法得出平均时间。但是起码是针对指定的语句做的 profile。用法在这里： https://dev.mysql.com/doc/refman/5.5/en/show-profile.html

#6 楼 @nightire 4-5 s，可能是虚拟机的问题。谢谢你。

我是跑在虚拟机的，的确会慢一些。大概 4-5 s。 这么多人说秒开，我深刻反省一下。我没说清楚，不好意思。谢谢大家。spring 我也是在用的，大部分时候不用重启，一旦重启还是慢。

不小心提了一个原来不算问题的问题。不好意思。

此外，并非拿 Python、PHP 来挤兑 Ruby。我不作这一些无谓的争论。

我很想探讨这个问题。我想先来搞清楚 两点：

1. 为什么用 select count(1) 来代表平均查询时间？
2. " ……查询 b 的时候，理论上用不到索引的。为啥这里？？？ ……" 这里是有三个疑问号，想问啥？

uuid 的问题是：

1. 纯字符串类型，算上连字符'-'的话，36 个字符。而整数类型最大 bigint 也就 8 个字节。
2. 对 innodb 存储引擎来说，主键作为聚集索引，有序地插入（递增）比无序插入性能要好。而 uuid 并不是有序的。

所以解决办法是，自己生成绝对不会冲突的纯数字递增主键。Instagram 的做法同样适用于 mysql，见 http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram