Nirvana Studio

小谈Chrome

ShiningRay — Thu, 04 Sep 2008 22:02:00 +0800

最近关于Google浏览器Chrome的报道铺天盖地，我也第一时间尝试了Chrome，我觉得其简洁的风格我非常喜欢。不过这只是第一个版本，稳定性和功能各方面还有待增强。但我发现了一个Google在这里的一点技术创新，那便是不同的标签页使用了不同的进程。

不搞编程的人可能不知道这里面的好处：

多进程提高了整个应用的稳定性：倘若有一个标签页崩溃、假死了，并不会影响到其他的标签页。我在Firefox下经历过某个页面的假死导致必须强制关闭整个浏览器。
多进程可以提高应用整体性能：现在计算机已经进入多核时代，只有能利用多个核心的优势才能进一步提高程序性能。一般而言，单进程的程序要通过线程来利用多核，但是线程之间由于共享同一片内存地址，编写代码容易出现问题，不如传统的进程方式方便稳定。
多进程可以节省内存资源：进程结束之后内存可以立刻释放，就更不容易出现内存泄露的问题

过去IE也有多进程模式，但必须是重新执行IE的进程才行，对于从任何一个IE窗口中弹出的新窗口，实际上和原窗口还是同一个进程，而进入到了IE7之后，标签方式浏览必须使用同一个进程。而FF和Opera则一直都是单进程模式。Chrome完美结合了多进程方式和标签浏览，这一招确实非常高明。

2008-8-30 Google AppEngine Camp小记

ShiningRay — Sat, 30 Aug 2008 23:40:21 +0800

有幸参加了谷歌上海组织的Google AppEngine Camp的技术交流会。很惭愧的是我还没有好好地去研究Google AppEngine（以下简称GAE），就来滥竽充数了，而且还因为某些原因，迟到了半个小时。

Google愧为开发者心目中的圣地，谷歌上海也充分反应了Google的企业文化。当我这个乡下人刚进入来福仕广场的办公楼的时候，顿时有一种非常豪华的感觉。进入了谷歌上海的办公室，第一印象就是专业，（非公司成员进入办公室都需要贴个条子，条子是用标签机打印出来的）。房间的配色给人感觉非常明亮，办公室的每一样设备都非常专业／高档：会议室的投影设备、视频、音频点播系统（恕我老土吧，我不知道那个机柜里面放的都是什么）。会议室旁边应该是一个很大的休息区域，估计也是活动区域，还放了电子琴、电吉他等。有一排书柜上放了不少杂志和书籍（有金庸全集），还有两个冰柜，放了各种饮料可以各取所需。甚至还有一个吧台，有微波炉、咖啡机等等。甚至（男）厕所都非常有个性。办公区域的显示屏也倍儿有面子，每个人桌上的东西也很有个性（各种谷歌的小玩意儿）。墙上随处可见Google的Doodle。

此次参加活动，除了以上的印象外，还有一个印象就是帅哥多，MacBook多。最大的遗憾就是没有带相机，否则可以将照片贴出来。

不过还是有一些我觉得不好的地方：

一部分人在演讲人讲话的同时在下面开小会讨论自己的问题。我认为这个是对演讲人和想听演讲的人的不尊重。其实完全可以走出去到活动厅讨论么。
演讲的同时，我还曾听见有人直接在底下接电话。
虽然演讲人说可以随时打断他的讲话并提问，但我认为既然有人主讲而不是以完全的沙龙形式，就应该控制时间，总是打断不利于提高效率，很多东西可以私下交流。
主讲人也应该注意控制时间，5分钟演讲大部分都大大超过这个时间。

此次活动最大的收获估计就是能参观一下传说中的谷歌办公室。希望下次还有机会去吧。

2008-8-30 Google AppEngine Camp小记

ShiningRay — Sat, 30 Aug 2008 23:40:21 +0800

此次参加活动，除了以上的印象外，还有一个印象就是帅哥多，MacBook多。最大的遗憾就是没有带相机，否则可以将照片贴出来。

不过还是有一些我觉得不好的地方：

一部分人在演讲人讲话的同时在下面开小会讨论自己的问题。我认为这个是对演讲人和想听演讲的人的不尊重。其实完全可以走出去到活动厅讨论么。
演讲的同时，我还曾听见有人直接在底下接电话。
虽然演讲人说可以随时打断他的讲话并提问，但我认为既然有人主讲而不是以完全的沙龙形式，就应该控制时间，总是打断不利于提高效率，很多东西可以私下交流。
主讲人也应该注意控制时间，5分钟演讲大部分都大大超过这个时间。

此次活动最大的收获估计就是能参观一下传说中的谷歌办公室。希望下次还有机会去吧。

ORDER BY RAND()

ShiningRay — Sat, 30 Aug 2008 23:14:48 +0800

原文地址：http://jan.kneschke.de/projects/mysql/order-by-rand

翻译：ShiningRay

译者序
之前有位朋友提到从MySQL随机取1条记录其实只要SELECT * FROM table ORDER BY RAND() LIMIT 1即可。其实这个语句有很大的性能问题，对于大表的效率是非常低下的。我们可以看一下MySQL对其的解释：

EXPLAIN SELECT *
FROM `money_logs`
ORDER BY RAND( )
LIMIT 1

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	table	ALL	NULL	NULL	NULL	NULL	173784	Using temporary; Using filesort

这个SQL语句无法使用任何索引，还必须使用临时表和文件排序，在一个15万条记录的MyISAM表需要花大约0.3秒。已经是相当慢的了。如何优化，请往下看：

第一个例子我们先假设ID是从1开始并且1和ID的最大值之间没有任何空档。

将工作移入应用程序

第一个想法：如果我们可以事先在应用程序中计算出ID，那么就可以简化整个工作。

SELECT MAX(id) FROM random;
## 在应用程序中生成随机id
SELECT name FROM random WHERE id = <random-id>

由于MAX(id) == COUNT(id) 我们只要生成从1到MAX(id)之间一个随机数，并将其传给数据库并取回随机行。

上面第一个SELECT基本上是一个可以被优化掉的空操作。第二个是一个针对常量的eq_ref查询，同样也很快。

将任务放入数据库

不过有必要将其放入应用程序吗？难道我们不能在数据库里完成？

# 生成一个随机 ID
> SELECT RAND() * MAX(id) FROM random;
+------------------+
| RAND() * MAX(id) |
+------------------+
|  689.37582507297 |
+------------------+
# 喔，这是一个浮点数，不过我们需要整数

> SELECT CEIL(RAND() * MAX(id)) FROM random;
+-------------------------+
| CEIL(RAND() * MAX(id)) |
+-------------------------+
|                    1000000  |
+-------------------------+
# 好多了。不过性能如何？

> EXPLAIN
   SELECT CEIL(RAND() * MAX(id)) FROM random;
+----+-------------+-------+-------+------+-------------+
| id | select_type | table | type  | rows | Extra       |
+----+-------------+-------+-------+------+-------------+
|  1 | SIMPLE      | random  | index | 1000000  | Using index |
+----+-------------+-------+-------+------+-------------+
## 一个索引扫描？我们没有对MAX()进行优化

> EXPLAIN
   SELECT CEIL(RAND() * (SELECT MAX(id) FROM random));
+----+-------------+-------+------+------+------------------------------+
| id | select_type | table | type | rows | Extra                        |
+----+-------------+-------+------+------+------------------------------+
|  1 | PRIMARY     | NULL  | NULL | NULL | No tables used               |
|  2 | SUBQUERY    | NULL  | NULL | NULL | Select tables optimized away |
+----+-------------+-------+------+------+------------------------------+
## 一个简单的子查询给我们将性能找了回来。

OK，现在我们知道如何生成随机ID了，不过如何获取记录行？

> EXPLAIN
SELECT name
  FROM random
 WHERE id = (SELECT CEIL(RAND() *
                         (SELECT MAX(id)
                            FROM random));
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows    | Extra                        |
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
|  1 | PRIMARY     | random | ALL  | NULL          | NULL | NULL    | NULL | 1000000 | Using where                  |
|  3 | SUBQUERY    | NULL   | NULL | NULL          | NULL | NULL    | NULL |    NULL | Select tables optimized away |
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
> show warnings;
+-------+------+------------------------------------------+
| Level | Code | Message                                  |
+-------+------+------------------------------------------+
| Note  | 1249 | Select 2 was reduced during optimization |
+-------+------+------------------------------------------+

哦，不！不要走这条路。虽然它很直观，但是也是最容易犯的错。理由是：在WHERE子句中的SELECT会针对外部SELECT取出的每一行执行一次。这可能会是0到4091行，看你的运气了。

我们必须用一种方法确保随机ID只被生成一次：

SELECT name
  FROM random JOIN
       (SELECT CEIL(RAND() *
                    (SELECT MAX(id)
                       FROM random)) AS id
        ) AS r2
       USING (id);
+----+-------------+------------+--------+------+------------------------------+
| id | select_type | table      | type   | rows | Extra                        |
+----+-------------+------------+--------+------+------------------------------+
|  1 | PRIMARY     | <derived2> | system |    1 |                              |
|  1 | PRIMARY     | random     | const  |    1 |                              |
|  2 | DERIVED     | NULL       | NULL   | NULL | No tables used               |
|  3 | SUBQUERY    | NULL       | NULL   | NULL | Select tables optimized away |
+----+-------------+------------+--------+------+------------------------------+

内部的 SELECT 生成了一个常数临时（TEMPORARY）表并且联接（JOIN）只选择了一行。完美。

没有排序、没有应用程序介入，查询的大部分都被优化了。

在数字中加入空档

为了使最终的解决方案通用化，我们必须考虑空档的可能性，如当你删除(DELETE)了记录行。

SELECT name
  FROM random AS r1 JOIN
       (SELECT (RAND() *
                     (SELECT MAX(id)
                        FROM random)) AS id)
        AS r2
 WHERE r1.id >= r2.id
 ORDER BY r1.id ASC
 LIMIT 1;
+----+-------------+------------+--------+------+------------------------------+
| id | select_type | table      | type   | rows | Extra                        |
+----+-------------+------------+--------+------+------------------------------+
|  1 | PRIMARY     | <derived2> | system |    1 |                              |
|  1 | PRIMARY     | r1         | range  |  689 | Using where                  |
|  2 | DERIVED     | NULL       | NULL   | NULL | No tables used               |
|  3 | SUBQUERY    | NULL       | NULL   | NULL | Select tables optimized away |
+----+-------------+------------+--------+------+------------------------------+

JOIN现在加入了所有大于等于我们随机数的ID，并且当直接匹配不存在的时候，只选择最临近的记录。不过一旦找到了某一行，我们就立刻停止（LIMIT 1）。同时我们根据索引（ORDER BY id ASC）读取记录。由于我们使用了>=而非=，所以我们可以削去CEIL同时还能获取同样的结果，节省了一点点开销。

平均分布

一旦ID的分布不再是平均的了，那么我们对行的选择也不是完全随机的了。

> select * from holes;
+----+----------------------------------+----------+
| id | name                             | accesses |
+----+----------------------------------+----------+
|  1 | d12b2551c6cb7d7a64e40221569a8571 |      107 |
|  2 | f82ad6f29c9a680d7873d1bef822e3e9 |       50 |
|  4 | 9da1ed7dbbdcc6ec90d6cb139521f14a |      132 |
|  8 | 677a196206d93cdf18c3744905b94f73 |      230 |
| 16 | b7556d8ed40587a33dc5c449ae0345aa |      481 |
+----+----------------------------------+----------+

RAND函数生成诸如9到15之间的ID都会让id 16被选择。

目前还没有针对这个问题的真正的解决方案，不过你的数据是大部分不变的话可以添加一个将行号映射到ID的映射表：

> create table holes_map ( row_id int not NULL primary key, random_id int not null);
> SET @id = 0;
> INSERT INTO holes_map SELECT @id := @id + 1, id FROM holes;
> select * from holes_map;
+--------+-----------+
| row_id | random_id |
+--------+-----------+
|      1 |         1 |
|      2 |         2 |
|      3 |         4 |
|      4 |         8 |
|      5 |        16 |
+--------+-----------+

row_id现在则是没有空档的，我们就可以再次运行我们的随机查询了：

SELECT name FROM holes
  JOIN (SELECT r1.random_id
         FROM holes_map AS r1
         JOIN (SELECT (RAND() *
                      (SELECT MAX(row_id)
                         FROM holes_map)) AS row_id)
               AS r2
        WHERE r1.row_id >= r2.row_id
        ORDER BY r1.row_id ASC
        LIMIT 1) as rows ON (id = random_id);

1000次查找之后，我们可以看到一个平均分布：

> select * from holes;
+----+----------------------------------+----------+
| id | name                             | accesses |
+----+----------------------------------+----------+
|  1 | d12b2551c6cb7d7a64e40221569a8571 |      222 |
|  2 | f82ad6f29c9a680d7873d1bef822e3e9 |      187 |
|  4 | 9da1ed7dbbdcc6ec90d6cb139521f14a |      195 |
|  8 | 677a196206d93cdf18c3744905b94f73 |      207 |
| 16 | b7556d8ed40587a33dc5c449ae0345aa |      189 |
+----+----------------------------------+----------+

使用触发器维护有空档的表

让我们就用前面的几个表:

DROP TABLE IF EXISTS r2;
CREATE TABLE r2 (
  id SERIAL,
  name VARCHAR(32) NOT NULL UNIQUE
);

DROP TABLE IF EXISTS r2_equi_dist;
CREATE TABLE r2_equi_dist (
  id SERIAL,
  r2_id bigint unsigned NOT NULL UNIQUE
);

一旦我们在r2中改动了某些东西，我们希望r2_equi_dist也被更新。

DELIMITER $$
DROP TRIGGER IF EXISTS tai_r2$$
CREATE TRIGGER tai_r2
 AFTER INSERT ON r2 FOR EACH ROW
BEGIN
  DECLARE m BIGINT UNSIGNED DEFAULT 1;

  SELECT MAX(id) + 1 FROM r2_equi_dist INTO m;
  SELECT IFNULL(m, 1) INTO m;
  INSERT INTO r2_equi_dist (id, r2_id) VALUES (m, NEW.id);
END$$
DELIMITER ;

DELETE FROM r2;

INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  2 | a09a3959d68187ce48f4fe7e388926a9 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
|  4 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     2 |
|  3 |     3 |
|  4 |     4 |
+----+-------+

INSERT很简单，但在DELETE时我们需要更新equi-dist-id来维持id的连续。

DELIMITER $$
DROP TRIGGER IF EXISTS tad_r2$$
CREATE TRIGGER tad_r2
 AFTER DELETE ON r2 FOR EACH ROW
BEGIN
  DELETE FROM r2_equi_dist WHERE r2_id = OLD.id;
  UPDATE r2_equi_dist SET id = id - 1 WHERE r2_id > OLD.id;
END$$
DELIMITER ;

DELETE FROM r2 WHERE id = 2;

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
|  4 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     3 |
|  3 |     4 |
+----+-------+

UPDATE就非常直观了。我们只要维护一下外键约束：

DELIMITER $$
DROP TRIGGER IF EXISTS tau_r2$$
CREATE TRIGGER tau_r2
 AFTER UPDATE ON r2 FOR EACH ROW
BEGIN
  UPDATE r2_equi_dist SET r2_id = NEW.id WHERE r2_id = OLD.id;
END$$
DELIMITER ;

UPDATE r2 SET id = 25 WHERE id = 4;

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
| 25 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     3 |
|  3 |    25 |
+----+-------+

一次多行

如果你想一次取回多行，你可以：

执行多次查询
写一个存储过程执行查询并将结果存入一个临时表
进行一个UNION

存储过程

存储过程为你提供了通用语言中很有用的一些结构：

循环
控制结构
过程
…

这个任务中我们只需要一个LOOP:

DELIMITER $$
DROP PROCEDURE IF EXISTS get_rands$$
CREATE PROCEDURE get_rands(IN cnt INT)
BEGIN
  DROP TEMPORARY TABLE IF EXISTS rands;
  CREATE TEMPORARY TABLE rands ( rand_id INT );

loop_me: LOOP
    IF cnt < 1 THEN
      LEAVE loop_me;
    END IF;

    INSERT INTO rands
       SELECT r1.id
         FROM random AS r1 JOIN
              (SELECT (RAND() *
                            (SELECT MAX(id)
                               FROM random)) AS id)
               AS r2
        WHERE r1.id >= r2.id
        ORDER BY r1.id ASC
        LIMIT 1;

    SET cnt = cnt - 1;
  END LOOP loop_me;
END$$
DELIMITER ;

CALL get_rands(4);
SELECT * FROM rands;
+---------+
| rand_id |
+---------+
|  133716 |
|  702643 |
|  112066 |
|  452400 |
+---------+

下面的问题留给读者解决：

使用动态SQL并传入临时表的名字
在表上使用一个UNIQUE索引并捕获UNIQUE键冲突来消除结果集中可能的重复记录。

性能

现在让我们看看性能方面发生了什么变化。我们有三个不同的查询来解决这个问题。

Q1. ORDER BY RAND()
Q2. RAND() * MAX(ID)
Q3. RAND() * MAX(ID) + ORDER BY ID

Q1预期消耗N * log2(N)，Q2和Q3接近常数。

下标是评测的结果，针对N行的表（从一千行到一百万行），每个查询执行1000次。

   100        1.000      10.000     100.000    1.000.000
Q1  0:00.718s  0:02.092s  0:18.684s  2:59.081s  58:20.000s
Q2  0:00.519s  0:00.607s  0:00.614s  0:00.628s   0:00.637s
Q3  0:00.570s  0:00.607s  0:00.614s  0:00.628s   0:00.637s

如你所见，普通的ORDER BY RAND()从仅100行的表开始便落后于优化过的查询了。

关于这些查询更详细的分析可以在analyzing-complex-queries查阅.

ORDER BY RAND()

ShiningRay — Sat, 30 Aug 2008 23:14:48 +0800

原文地址：http://jan.kneschke.de/projects/mysql/order-by-rand

翻译：ShiningRay

EXPLAIN SELECT *
FROM `money_logs`
ORDER BY RAND( )
LIMIT 1

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	table	ALL	NULL	NULL	NULL	NULL	173784	Using temporary; Using filesort

这个SQL语句无法使用任何索引，还必须使用临时表和文件排序，在一个15万条记录的MyISAM表需要花大约0.3秒。已经是相当慢的了。如何优化，请往下看：

第一个例子我们先假设ID是从1开始并且1和ID的最大值之间没有任何空档。

将工作移入应用程序

第一个想法：如果我们可以事先在应用程序中计算出ID，那么就可以简化整个工作。

SELECT MAX(id) FROM random;
## generate random id in application
SELECT name FROM random WHERE id = <random-id>

由于As MAX(id) == COUNT(id) 我们只要生成从1到MAX(id)之间一个随机数，并将其传给数据库并取回随机行。

上面第一个SELECT基本上是一个可以被优化掉的空操作。第二个是一个针对常量的eq_ref查询，同样也很快。

将任务放入数据库

不过有必要将其放入应用程序吗？难道我们不能在数据库里完成？

# 生成一个随机 ID
> SELECT RAND() * MAX(id) FROM random;
+------------------+
| RAND() * MAX(id) |
+------------------+
|  689.37582507297 |
+------------------+
# 喔，这是一个浮点数，不过我们需要整数

> SELECT CEIL(RAND() * MAX(id)) FROM random;
+-------------------------+
| CEIL(RAND() * MAX(id)) |
+-------------------------+
|                    1000000  |
+-------------------------+
# 好多了。不过性能如何？

> EXPLAIN
   SELECT CEIL(RAND() * MAX(id)) FROM random;
+----+-------------+-------+-------+------+-------------+
| id | select_type | table | type  | rows | Extra       |
+----+-------------+-------+-------+------+-------------+
|  1 | SIMPLE      | random  | index | 1000000  | Using index |
+----+-------------+-------+-------+------+-------------+
## 一个索引扫描？我们没有对MAX()进行优化

> EXPLAIN
   SELECT CEIL(RAND() * (SELECT MAX(id) FROM random));
+----+-------------+-------+------+------+------------------------------+
| id | select_type | table | type | rows | Extra                        |
+----+-------------+-------+------+------+------------------------------+
|  1 | PRIMARY     | NULL  | NULL | NULL | No tables used               |
|  2 | SUBQUERY    | NULL  | NULL | NULL | Select tables optimized away |
+----+-------------+-------+------+------+------------------------------+
## 一个简单的子查询给我们将性能找了回来。

OK，现在我们知道如何生成随机ID了，不过如何获取记录行？

> EXPLAIN
SELECT name
  FROM random
 WHERE id = (SELECT CEIL(RAND() *
                         (SELECT MAX(id)
                            FROM random));
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows    | Extra                        |
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
|  1 | PRIMARY     | random | ALL  | NULL          | NULL | NULL    | NULL | 1000000 | Using where                  |
|  3 | SUBQUERY    | NULL   | NULL | NULL          | NULL | NULL    | NULL |    NULL | Select tables optimized away |
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
> show warnings;
+-------+------+------------------------------------------+
| Level | Code | Message                                  |
+-------+------+------------------------------------------+
| Note  | 1249 | Select 2 was reduced during optimization |
+-------+------+------------------------------------------+

我们必须用一种方法确保随机ID只被生成一次：

SELECT name
  FROM random JOIN
       (SELECT CEIL(RAND() *
                    (SELECT MAX(id)
                       FROM random)) AS id
        ) AS r2
       USING (id);
+----+-------------+------------+--------+------+------------------------------+
| id | select_type | table      | type   | rows | Extra                        |
+----+-------------+------------+--------+------+------------------------------+
|  1 | PRIMARY     | <derived2> | system |    1 |                              |
|  1 | PRIMARY     | random     | const  |    1 |                              |
|  2 | DERIVED     | NULL       | NULL   | NULL | No tables used               |
|  3 | SUBQUERY    | NULL       | NULL   | NULL | Select tables optimized away |
+----+-------------+------------+--------+------+------------------------------+

内部的 SELECT 生成了一个常数临时（TEMPORARY）表并且联接（JOIN）只选择了一行。完美。

没有排序、没有应用程序介入，查询的大部分都被优化了。

在数字中加入空档

为了使最终的解决方案通用化，我们必须考虑空档的可能性，如当你删除(DELETE)了记录行。

SELECT name
  FROM random AS r1 JOIN
       (SELECT (RAND() *
                     (SELECT MAX(id)
                        FROM random)) AS id)
        AS r2
 WHERE r1.id >= r2.id
 ORDER BY r1.id ASC
 LIMIT 1;
+----+-------------+------------+--------+------+------------------------------+
| id | select_type | table      | type   | rows | Extra                        |
+----+-------------+------------+--------+------+------------------------------+
|  1 | PRIMARY     | <derived2> | system |    1 |                              |
|  1 | PRIMARY     | r1         | range  |  689 | Using where                  |
|  2 | DERIVED     | NULL       | NULL   | NULL | No tables used               |
|  3 | SUBQUERY    | NULL       | NULL   | NULL | Select tables optimized away |
+----+-------------+------------+--------+------+------------------------------+

平均分布

一旦ID的分布不再是平均的了，那么我们对行的选择也不是完全随机的了。

> select * from holes;
+----+----------------------------------+----------+
| id | name                             | accesses |
+----+----------------------------------+----------+
|  1 | d12b2551c6cb7d7a64e40221569a8571 |      107 |
|  2 | f82ad6f29c9a680d7873d1bef822e3e9 |       50 |
|  4 | 9da1ed7dbbdcc6ec90d6cb139521f14a |      132 |
|  8 | 677a196206d93cdf18c3744905b94f73 |      230 |
| 16 | b7556d8ed40587a33dc5c449ae0345aa |      481 |
+----+----------------------------------+----------+

The RAND函数生成诸如9到15之间的ID都会让id 16被选择。

目前还没有针对这个问题的真正的解决方案，不过你的数据是大部分不变的话可以添加一个将行号映射到ID的映射表：

> create table holes_map ( row_id int not NULL primary key, random_id int not null);
> SET @id = 0;
> INSERT INTO holes_map SELECT @id := @id + 1, id FROM holes;
> select * from holes_map;
+--------+-----------+
| row_id | random_id |
+--------+-----------+
|      1 |         1 |
|      2 |         2 |
|      3 |         4 |
|      4 |         8 |
|      5 |        16 |
+--------+-----------+

row_id现在则是没有空档的，我们就可以再次运行我们的随机查询了：

SELECT name FROM holes
  JOIN (SELECT r1.random_id
         FROM holes_map AS r1
         JOIN (SELECT (RAND() *
                      (SELECT MAX(row_id)
                         FROM holes_map)) AS row_id)
               AS r2
        WHERE r1.row_id >= r2.row_id
        ORDER BY r1.row_id ASC
        LIMIT 1) as rows ON (id = random_id);

1000次查找之后，我们可以看到一个平均分布：

> select * from holes;
+----+----------------------------------+----------+
| id | name                             | accesses |
+----+----------------------------------+----------+
|  1 | d12b2551c6cb7d7a64e40221569a8571 |      222 |
|  2 | f82ad6f29c9a680d7873d1bef822e3e9 |      187 |
|  4 | 9da1ed7dbbdcc6ec90d6cb139521f14a |      195 |
|  8 | 677a196206d93cdf18c3744905b94f73 |      207 |
| 16 | b7556d8ed40587a33dc5c449ae0345aa |      189 |
+----+----------------------------------+----------+

使用触发器维护有空档的表

让我们就用前面的几个表:

DROP TABLE IF EXISTS r2;
CREATE TABLE r2 (
  id SERIAL,
  name VARCHAR(32) NOT NULL UNIQUE
);

DROP TABLE IF EXISTS r2_equi_dist;
CREATE TABLE r2_equi_dist (
  id SERIAL,
  r2_id bigint unsigned NOT NULL UNIQUE
);

一旦我们在r2中改动了某些东西，我们希望r2_equi_dist也被更新。

DELIMITER $$
DROP TRIGGER IF EXISTS tai_r2$$
CREATE TRIGGER tai_r2
 AFTER INSERT ON r2 FOR EACH ROW
BEGIN
  DECLARE m BIGINT UNSIGNED DEFAULT 1;

  SELECT MAX(id) + 1 FROM r2_equi_dist INTO m;
  SELECT IFNULL(m, 1) INTO m;
  INSERT INTO r2_equi_dist (id, r2_id) VALUES (m, NEW.id);
END$$
DELIMITER ;

DELETE FROM r2;

INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  2 | a09a3959d68187ce48f4fe7e388926a9 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
|  4 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     2 |
|  3 |     3 |
|  4 |     4 |
+----+-------+

INSERT很简单，但在DELETE时我们需要更新equi-dist-id来维持id的连续。

DELIMITER $$
DROP TRIGGER IF EXISTS tad_r2$$
CREATE TRIGGER tad_r2
 AFTER DELETE ON r2 FOR EACH ROW
BEGIN
  DELETE FROM r2_equi_dist WHERE r2_id = OLD.id;
  UPDATE r2_equi_dist SET id = id - 1 WHERE r2_id > OLD.id;
END$$
DELIMITER ;

DELETE FROM r2 WHERE id = 2;

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
|  4 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     3 |
|  3 |     4 |
+----+-------+

UPDATE就非常直观了。我们只要维护一下外键约束：

DELIMITER $$
DROP TRIGGER IF EXISTS tau_r2$$
CREATE TRIGGER tau_r2
 AFTER UPDATE ON r2 FOR EACH ROW
BEGIN
  UPDATE r2_equi_dist SET r2_id = NEW.id WHERE r2_id = OLD.id;
END$$
DELIMITER ;

UPDATE r2 SET id = 25 WHERE id = 4;

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
| 25 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     3 |
|  3 |    25 |
+----+-------+

一次多行

如果你想一次取回多行，你可以：

执行多次查询
写一个存储过程执行查询并将结果存入一个临时表
进行一个UNION

存储过程

存储过程为你提供了通用语言中很有用的一些结构：

循环
控制结构
过程
…

这个任务中我们只需要一个LOOP:

DELIMITER $$
DROP PROCEDURE IF EXISTS get_rands$$
CREATE PROCEDURE get_rands(IN cnt INT)
BEGIN
  DROP TEMPORARY TABLE IF EXISTS rands;
  CREATE TEMPORARY TABLE rands ( rand_id INT );

loop_me: LOOP
    IF cnt < 1 THEN
      LEAVE loop_me;
    END IF;

    INSERT INTO rands
       SELECT r1.id
         FROM random AS r1 JOIN
              (SELECT (RAND() *
                            (SELECT MAX(id)
                               FROM random)) AS id)
               AS r2
        WHERE r1.id >= r2.id
        ORDER BY r1.id ASC
        LIMIT 1;

    SET cnt = cnt - 1;
  END LOOP loop_me;
END$$
DELIMITER ;

CALL get_rands(4);
SELECT * FROM rands;
+---------+
| rand_id |
+---------+
|  133716 |
|  702643 |
|  112066 |
|  452400 |
+---------+

下面的问题留给读者解决：

使用动态SQL并传入临时表的名字
在表上使用一个UNIQUE索引并捕获UNIQUE键冲突来消除结果集中可能的重复记录。

性能

现在让我们看看性能方面发生了什么变化。我们有三个不同的查询来解决这个问题。

Q1. ORDER BY RAND()
Q2. RAND() * MAX(ID)
Q3. RAND() * MAX(ID) + ORDER BY ID

Q1预期消耗N * log2(N)，Q2和Q3接近常数。

下标是评测的结果，针对N行的表（从一千行到一百万行），每个查询执行1000次。

   100        1.000      10.000     100.000    1.000.000
Q1  0:00.718s  0:02.092s  0:18.684s  2:59.081s  58:20.000s
Q2  0:00.519s  0:00.607s  0:00.614s  0:00.628s   0:00.637s
Q3  0:00.570s  0:00.607s  0:00.614s  0:00.628s   0:00.637s

如你所见，普通的ORDER BY RAND()从仅100行的表开始便落后于优化过的查询了。

关于这些查询更详细的分析可以在analyzing-complex-queries查阅.

上海的洪水

ShiningRay — Mon, 25 Aug 2008 22:11:45 +0800

今天是到渡维上班的第一天，结果遇上了百年一遇的暴雨，造成上海多个地方积水严重。我9点出门，等69路等了1个小时，找出租车用了半个小时，上了出租车之后绕绕绕，绕到虹井路延安西路，结果到了快一点，还没走多远，打车就85元了。然后路边随便找了一个饭店草草解决了午饭，长途跋涉，沿延安西路一直走到古北路兴义路。途中历经艰难险阻，过中环的时候都是趟着没过膝盖的污水经过的。到这个69路公交车站的时候已经是下午3点了，然后等69路最后坐到长宁路，到达公司的时候已经是4点多。

所幸，我还是到了。

晚上回来时乘坐69路则一路畅通，但我仍然看到中环靠近吴中路那边非常堵。

上海的洪水

ShiningRay — Mon, 25 Aug 2008 22:11:45 +0800

所幸，我还是到了。

晚上回来时乘坐69路则一路畅通，但我仍然看到中环靠近吴中路那边非常堵。

上海的洪水

ShiningRay — Mon, 25 Aug 2008 22:11:45 +0800

所幸，我还是到了。

晚上回来时乘坐69路则一路畅通，但我仍然看到中环靠近吴中路那边非常堵。

东西一流行就容易变味

ShiningRay — Fri, 08 Aug 2008 16:43:00 +0800

以前朋友带我去上海的一些店里吃东西，经常说“店大了，东西没有以前好吃了”。然而，我也和朋友去过另外一些小店，味道和店面都一如既往十几年（除了物价上涨）。

这时候我发现身边很多东西一旦开始流行，就立刻变味——也许这就叫量变到质变。身边的例子很多，记得05年的时候，我还和同学们一起吃一种叫做“掉渣大饼“的东西，那时候这玩意儿突然很流行，但没过多久，突然又消失匿迹了。有人分析原因是这样：“流行风，不适合在一个固定地点开店，适合流动售卖。口味比较重，油也挺大，不是健康食品。所以刚出来时，大家出于好奇，买的人较多，但不适合常吃。”^[1]然而也有人分析是因为“无序加盟”造成的^[2]。

掉渣大饼的例子算是一类典型，但它的“潮流”，也许还不是那么地引人注目。只能说，它的“流行”只是相对于其他接近的东西，在短时间内聚集了大量关注。也许标题改成“公司在快速扩张过程中容易出现问题”更能符合我所想说的。因为公司产品突然地流行起来，意味着公司更加有利可图，那么公司会想办法扩张，而在扩张过程中，由于某些方面做得不到位，或另些方面做得太过分等，而导致产品不能如公司或者受众的期望继续发展，甚至最终导致公司扩张失败、甚至市场萎缩。

我很想探究其中的道理。不过我认为应该首先定义“流行”是什么。百度百科上这样解释[3]：

比如一些事物，刚开始没有太多人去注意，慢慢的引起了很多的注视，后来越来越多的人开始关注它，这就是所谓的“流行＂

不过这似乎与我要阐述的流行有所不同，在这里我所谓的流行是指受众比原有变的多，且增长速度也在提升。当然还有受众的问题，当受众之间个体之间相同点少，那么可以说是大众流行，反之，就是小众流行；如果小众是属于有钱人，似乎就是高档的奢侈品；如果在受众中的接受程度高，那么就是该群体中的“主流”；如果在大众中接受程度高，那就可以算“主流”了。

我把在潮流中的三个类角色划分出来：A. 通过这个事物引领、制造（有意或无意的）潮流的公司或个体，B. 在潮流中模仿A，想分一杯羹的跟风者，C. 潮流的受众们。

C是原动力，A是导火索，B是推波助澜的。没有广泛的C，就不能成就A所需要的市场，没有市场带来的利益，也就不会有B的跟风。当A不能注重品质，东西就变味了。

往往当潮流来临的时候，没有人会意识到它有多大，它能持续多长，普通的公司往往都只想在潮流中能捞多少捞多少，而不管自己是不是真的有实力。我归结这些个公司在潮流中失败的原因往往有：

只注重扩张，而不注重品质：只知道要多捞点，不知道要全面均衡发展。
有各方面条件更好的后来者居上：没想到被巨头盯上了。
市场需求被透支：过分炒作流行的概念，等受众回头醒悟发现被骗了。

所以我想问问，那些准备制造、或刚刚制造了潮流的商家们，你们真的准备好了吗？

关于Apple

其实突然想写本文其实也是因为Apple。随着Apple的一系列优秀产品iPod、iPhone等一下子流行起来。最近Apple的日子不好过：

种种负面消息传出，我就会说，Apple，你的iPhone还没准备好吧？不可否认，Apple的iPhone的外观设计是出色的、操作系统是优秀的，软件服务也是很棒的，可惜，Apple你本来不是做手机的。iPhone的流行导致这个苹果变味儿了。

过去的定位与未来目标的冲突

Apple的产品定位一直是高端用户群体。以前，我对Apple的Mac是有一些好感的，当然我也不讨厌Windows。我一直认为Apple的东西很酷，很有形，用Apple的是设计师，非常有个性的人，他们很有创造力。然而在国外，iPod已然变成了是一个日用品。而在国内，则是一个时尚的代名词，用iPod，就可以显得很前卫，很潮流。其实当用的人多了，也就没有什么前卫不前卫的。因为直到有一天，我发现送外卖的小弟也揣着一个iPod。同时，模仿iPod的MP3、MP4公司越来越多，功能也会超越iPod，iPod虽然能因为Apple的种种魅力保持他的地位，但它在这个领域的份额也会逐渐减少——就好比现在手机与山寨机；如果iPod的份额不减少，甚至越来越高，那么说明市场正在衰退，因为用的人实在太多了，没有人会觉得这很前卫、很时尚。

其实Apple过去做的东西是有点“奢侈品”的意思在里面，然而，将来它要面对的是自己的产品变得大众化。

盲目扩张，忽视了品质

也许并非Apple不注重品质，而是对于手机的设计制造还缺乏经验，所以才出现了种种“瑕疵”。正因为对iPhone前景过于充满信心而到处签约，却忽视了iPhone的产能问题。这些问题非常容易导致iPhone的品牌被做烂掉。

Apple没有做过手机，难免会出现一些问题，但是因为Apple之前太成功了，所以iPhone理应成功，人们的期望总是很高。这种突然的潮流，搞不好就会淹没Apple自己。

其实iPod，在2001年出现第一代iPod，也是出现了很多问题，我的印象中，到05年，国内才开始流行iPod。这种稳步的渐进式的，也许更加符合发展规律。

这点Google就非常聪明，Google也希望进军手机领域，但它清楚，一方面自己没有做过手机，另一方面蛋糕要一起吃，只有拉拢手机巨头们，才能抢占这个市场，所以它推出了Open Handset Alliance，自己主导做系统，然后推自己服务。当时Gmail的推出，引发了无限/超大容量邮箱的革命时，Google也是用了类似策略，因为 Google清楚自己无法应付过多的用户，所以他在Gmail推出初期，只有被邀请才能加入，并且刺激别的邮件供应商跟进。这样在占据了合理的市场份额的同时，保证了Gmail的品质和发展。

摊子铺太广、独来独往

有人经常拿Apple和Microsoft比，其实我觉得两者除了在操作系统上可以进行比较外，其他方面没有很多交集。

历史上任何一个大浪潮，都不是单单某一个公司能够凭借一己之力完成的，PC机和Windows的流行，并不是一朝一夕的事情，而是顺应历史的必然。在Windows95流行之前，微软就已经做了十几年操作系统，而微软的联盟者，已经做了十几年的PC机。微软从来没有想着自己做硬件去统治整个市场。这就是为何微软抄了苹果的界面，却比苹果更流行的原因。

因为苹果什么都做，同时又几乎完全封闭自己的架构，一个公司的能力是有限的，所以它一直只能走小众路线。苹果从硬件方面的芯片、机箱、显示器，到软件上的操作系统、各种“i”系列的应用软件，从台式机到服务器，到现在的电子产品、手机，Apple可谓无所不包（虽然不是每个零件都自己做）。这也就是为何苹果机没有最终广泛流行的原因，因为微软不是一个人在战斗，微软的背后有Intel，有IBM，有各大中小PC制造商，有无数共享软件开发者，有无数的游戏厂商。苹果的封闭而又追求完美的面面俱到的开发，使他开发出来的只能是曲高和寡的艺术品。

当然，苹果也走了几招妙棋。MacOSX是基于BSD系统开发的操作系统，BSD是开源Unix系统家族中的一员，而且苹果也开放了一些东西让广大开发者一起维护。这就使得MacOSX可以兼容相当多的*nix软件，一下子吸引了很多*nix的开发人员。然后苹果又与Intel结盟，采用Intel芯片。

总结上述一些问题，我认为苹果目前其实处境还是很危险的。希望苹果不要再变味了。