讨厌夏天的胖墩子
讨厌夏天的胖墩子

MySQL ORDER BY优化的那些事儿

为了测试方便和直观，我们需要先创建一张测试表并插入一些数据：

CREATE TABLE `shop` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '记录ID',

`shop_id` int(11) NOT NULL COMMENT '商店ID',

`goods_id` int(11) NOT NULL COMMENT '物品ID',

`pay_type` tinyint(1) NOT NULL COMMENT '支付方式',

`price` decimal(10,2) NOT NULL COMMENT '物品价格',

`comment` varchar(200) NOT NULL COMMENT '备注',

PRIMARY KEY (`id`),

UNIQUE KEY `shop_id` (`shop_id`,`goods_id`),

KEY `price` (`price`),

KEY `pay_type` (`pay_type`)

)

ENGINE=InnoDB

AUTO_INCREMENT=8

DEFAULTCHARSET=utf8

COMMENT='商店物品表'

插入几行数据：

INSERT INTO `shop` (`id`, `shop_id`, `goods_id`, `pay_type`, `price`, `comment`) VALUES

(1, 1, 1, 0, '1.00', ''),

(2, 2, 1, 0, '24.00', ''),

(3, 2, 3, 1, '5.99', ''),

(4, 3, 1, 0, '1.99', ''),

(5, 3, 2, 1, '81.00', ''),

(6, 4, 2, 0, '15.00', ''),

(7, 4, 3, 0, '22.00', '');

好了。现在我们可以开始我们的学习了。

对照一下官方手册：http://dev.mysql.com/doc/refman/5.5/en/order-by-optimization.html

手册上说，如下的四种情况mysql是会作优化的：

SELECT * FROM t1 ORDER BY key_part1,key_part2,... ;

SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2;

SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC;

SELECT * FROM t1 WHEREkey_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;

真的是这样么？按手册上的说法，如果EXPLAIN的extra中出现了Using filesort则是没有用到排序优化。来吧，让我们挨个测试一下：

可优化的第一种情况

SELECT * FROM t1 ORDER BY key_part1,key_part2,...;

指的是使用联合索引中的各个字段进行排序：

mysql>EXPLAIN SELECT * FROM shop ORDER BY shop_id,goods_id;

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | shop  | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using filesort |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

1 row in set (0.00 sec)

当我们检索所有记录时可以看到，索引优化是无效的。如果改成如下的查询就可以应用上索引优化：

mysql>EXPLAIN SELECT id,shop_id,goods_id FROM shop ORDER BY shop_id,goods_id;

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 | Using index |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

1 row in set (0.00 sec)

这里的三个字段是在索引树中存放的，因此可以直接从索引树检索出来，不用去检索行，所以extra显示的是Using index不会出现Using filesort。而一旦我们加上了除主键之外的非排序字段，索引优化就失效了。

另外，还可以强制指定索引，这样也可以应用上索引优化：

mysql>EXPLAIN SELECT * FROM shop FORCE INDEX(shop_id) ORDER BY shop_id,goods_id;

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 |       |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

1 row in set (0.03 sec)

可优化的第二种情况

SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2;

这种情况指的是联合索引中的一部分指定了常量去检索，排序则使用了索引的另一部分。

mysql>EXPLAIN SELECT * FROM shop WHERE shop_id=2 ORDER BY goods_id;

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

| id | select_type | table | type | possible_keys | key     | key_len | ref   | rows | Extra       |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

|  1 | SIMPLE      | shop  | ref  | shop_id       | shop_id | 4       | const |    2 | Using where |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

1 row in set (0.00 sec)

的确，该情况索引优化是有效的。

可优化的第三种情况

SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC;

这种情况与第一种情况类似，仅仅是排序方向变更了，不出意外的话仍然不会有优化：

mysql>EXPLAIN SELECT * FROM shop ORDER BY shop_id DESC,goods_id DESC;

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | shop  | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using filesort |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

1 row in set (0.00 sec)

果然，没有排序优化。同样，如果只检索主键和排序字段，排序优化有效：

mysql>EXPLAIN SELECT id,shop_id,goods_id FROM shop ORDER BY shop_id DESC,goods_id DESC;

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 | Using index |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

1 row in set (0.00 sec)

如果强制指定索引呢？

mysql>EXPLAIN SELECT * FROM shop FORCE INDEX(shop_id) ORDER BY shop_id DESC, goods_id DESC;

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 |       |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

1 row in set (0.00 sec)

可见也是有效的。

可优化的第四种情况

SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;

以索引的一部分为条件并且是常量，排序按索引的各字段倒排时，这种情况排序优化有效：

mysql>EXPLAIN SELECT * FROM shop WHERE shop_id=2 ORDER BY shop_id DESC, goods_id DESC;

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

| id | select_type | table | type | possible_keys | key     | key_len | ref   | rows | Extra       |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

|  1 | SIMPLE      | shop  | ref  | shop_id       | shop_id | 4       | const |    2 | Using where |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

1 row in set (0.00 sec)

对于何时排序优化有效，官方手册上是这样说的：

The index can also be used even if the ORDER BY does not match the index exactly, as long as all of the unused portions of the index and all the extra ORDER BY columns are constants in the WHERE clause.

翻译：

即使ORDER BY不精确匹配索引也能使用索引，只要WHERE子句中的所有未使用的索引部分和所有额外的ORDER BY列为常数就行。

这句话中有两个细节，如上面标蓝的部分，下面举个例子来说明一下：

比如情况二，

SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2;

ORDER BY子句是key_part2，并未精确的匹配索引(精确匹配就应当是key_part1,key_part2)，但是WHERE子句中使用了索引的一部分(key_part1)并且为常数，而对于ORDER BY来说，key_part1就是额外的，它不出现在ORDER BY子句中便却是索引的一部分，这样，排序就可以用到索引来优化了。

------------------------------- 这里需要一根分隔线 -------------------------------

手册上还介绍了几种无法应用排序优化的情况，我们来看一下：

无法优化的情况1

SELECT * FROM t1 ORDER BY key1, key2;

这种情况是当排序时指定了两个索引时：

mysql>EXPLAIN SELECT * FROM shop ORDER BY id,price;

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | shop  | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using filesort |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

1 row in set (0.00 sec)

本例中用到了两个索引，其中id还是主键，但这也无助于排序优化。这种情况下，即使指定了检索结果集，也无法避免Using filesort。

无法优化的情况2

SELECT * FROM t1 WHERE key2=constant ORDER BY key_part2;

当查询条件使用了别的索引，且值为常量，但排序字段是另一个联合索引的非连续部分时：

mysql>EXPLAIN SELECT * FROM shop WHERE price=15 ORDER BY goods_id;

+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------+

| id | select_type | table | type | possible_keys | key   | key_len | ref   | rows | Extra                       |

+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------+

|  1 | SIMPLE      | shop  | ref  | price         | price | 5       | const |    1 | Using where; Using filesort |

+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------+

1 row in set (0.00 sec)

无法优化的情况3

SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC;

混用两种排序方向时，这种情况如果指定了结果集为主键或联合索引字段，也无法避免Using filesort:

mysql>EXPLAIN SELECT * FROM shop ORDER BY shop_id ASC, goods_id DESC;

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | shop  | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using filesort |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

1 row in set (0.00 sec)

无法优化的情况4

SELECT * FROM t1 WHERE key2=constant ORDER BY key1;

这种情况指的是查询时按索引2，而排序时按索引1，真的是不能优化么？

mysql>EXPLAIN SELECT * FROM shop WHERE pay_type=1 ORDER BY price;

+----+-------------+-------+------+---------------+----------+---------+-------+------+-----------------------------+

| id | select_type | table | type | possible_keys | key      | key_len | ref   | rows | Extra                       |

+----+-------------+-------+------+---------------+----------+---------+-------+------+-----------------------------+

|  1 | SIMPLE      | shop  | ref  | pay_type      | pay_type | 1       | const |    2 | Using where; Using filesort |

+----+-------------+-------+------+---------------+----------+---------+-------+------+-----------------------------+

1 row in set (0.00 sec)

当我们指定了pay_type为1来检索行，并按price来排序时，发现的确不能优化排序。如果按id来排序呢？

mysql>EXPLAIN SELECT * FROM shop WHERE pay_type=1 ORDER BY id;

+----+-------------+-------+------+---------------+----------+---------+-------+------+-------------+

| id | select_type | table | type | possible_keys | key      | key_len | ref   | rows | Extra       |

+----+-------------+-------+------+---------------+----------+---------+-------+------+-------------+

|  1 | SIMPLE      | shop  | ref  | pay_type      | pay_type | 1       | const |    2 | Using where |

+----+-------------+-------+------+---------------+----------+---------+-------+------+-------------+

1 row in set (0.00 sec)

很惊奇的发现，排序被优化了。

无法优化的情况5

SELECT * FROM t1 ORDER BY ABS(key);

SELECT * FROM t1 ORDER BY -key;

这种情况指的是按表达式来排序，为了更直观的看出区别，我们作了三种情况：

1）用主键排序

mysql>EXPLAIN SELECT * FROM shop ORDER BY id;

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

|  1 | SIMPLE      | shop  | index | NULL          | PRIMARY | 4       | NULL |    7 |       |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

1 row in set (0.00 sec)

2）ABS表达式

mysql>EXPLAIN SELECT * FROM shop ORDER BY ABS(id);

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | shop  | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using filesort |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

1 row in set (0.00 sec)

3）负号

mysql>EXPLAIN SELECT * FROM shop ORDER BY -id;

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | shop  | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using filesort |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

1 row in set (0.28 sec)

可见，用表达式的情况的确不会排序优化。

无法优化的情况6

官方的翻译：当联接了多张表，并且ORDER BY中的列并不是全部来自第1个用于搜索行的非常量表.(这是EXPLAIN输出中的没有使用const联接类型的第1个表）。

分析一下标蓝的部分：

列来自表 ->

列不是来自表 ->

列不是全部来自表 ->

列不是全部来自非常量表 ->

列不是全部来自第一个用于搜索行的非常量表。

要测试这种情况，我们需要新增一张表：

CREATE TABLE `pay_type` (

`type_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'ID',

`rate` decimal(6,2) NOT NULL COMMENT '费率',

`name` varchar(20) NOT NULL COMMENT '名称',

PRIMARY KEY (`type_id`)

)

ENGINE=InnoDB

AUTO_INCREMENT=4

DEFAULTCHARSET=utf8

COMMENT='支付方式表'

插入几条记录：

INSERT INTO `pay_type` (`type_id`, `rate`, `name`) VALUES

(1, '0.01', '手机'),

(2, '0.02', '网银'),

(3, '0.00', '货到付款');

我们测试一下：

mysql>EXPLAIN SELECT * FROM shop a LEFT JOIN pay_type b ON a.pay_type=b.type_id WHERE a.id>2 ORDER BY a.goods_id, b.type_id;

+----+-------------+-------+--------+---------------+---------+---------+-----------------+------+----------------------------------------------+

| id | select_type | table | type   | possible_keys | key     | key_len | ref             | rows | Extra                                        |

+----+-------------+-------+--------+---------------+---------+---------+-----------------+------+----------------------------------------------+

|  1 | SIMPLE      | a     | range  | PRIMARY       | PRIMARY | 4       | NULL            |    5 | Using where; Using temporary; Using filesort |

|  1 | SIMPLE      | b     | eq_ref | PRIMARY       | PRIMARY | 4       | test.a.pay_type |    1 |                                              |

+----+-------------+-------+--------+---------------+---------+---------+-----------------+------+----------------------------------------------+

2 rows in set (0.28 sec)

a表是一个非常量表，并且是执行计划中的第一个，这满足上面所说的表类型。

ORDER BY中的列来自于两张表，所以不是全部来自于a表。

对于这样的情况，的确不能做排序优化。

无法优化的情况7

有不同的ORDER BY和GROUP BY表达式。

mysql>EXPLAIN SELECT shop_id, MAX(price) max_price FROM shop GROUP BY shop_id ORDER BY max_price DESC;

+----+-------------+-------+-------+---------------+---------+---------+------+------+---------------------------------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                           |

+----+-------------+-------+-------+---------------+---------+---------+------+------+---------------------------------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 | Using temporary; Using filesort |

+----+-------------+-------+-------+---------------+---------+---------+------+------+---------------------------------+

1 row in set (0.04 sec)

当我们按shop_id进行分组后，想按最高价的商品倒排时，可以看到没有排序优化。如果排序的字段与分组的字段一致，都是shop_id，排序优化就生效了。

mysql>EXPLAIN SELECT shop_id, MAX(price) max_price FROM shop GROUP BY shop_id ORDER BY shop_id desc;

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 |       |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------+

1 row in set (0.01 sec)

无法优化的情况8

如果指定了索引长度，且索引长度小于字段长度时，不能进行排序优化。

我们需要修改一下上面创建的pay_type表，加一个索引，索引长度是1：

ALTER TABLE `test`.`pay_type` ADD INDEX `name` ( `name` ( 1 ) )

然后测试：

mysql>EXPLAIN SELECT * FROM pay_type FORCE INDEX(name) ORDER BY name;

+----+-------------+----------+------+---------------+------+---------+------+------+----------------+

| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra          |

+----+-------------+----------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | pay_type | ALL  | NULL          | NULL | NULL    | NULL |    3 | Using filesort |

+----+-------------+----------+------+---------------+------+---------+------+------+----------------+

1 row in set (0.00 sec)

的确，没有排序优化。如果不指定name的长度呢，先修改一下索引：

ALTER TABLE `test`.`pay_type` DROP INDEX `name` ,

ADD INDEX `name` ( `name` )

然后执行：

mysql>EXPLAIN SELECT * FROM pay_type FORCE INDEX(name) ORDER BY name;

+----+-------------+----------+-------+---------------+------+---------+------+------+-------+

| id | select_type | table    | type  | possible_keys | key  | key_len | ref  | rows | Extra |

+----+-------------+----------+-------+---------------+------+---------+------+------+-------+

|  1 | SIMPLE      | pay_type | index | NULL          | name | 62      | NULL |    3 |       |

+----+-------------+----------+-------+---------------+------+---------+------+------+-------+

1 row in set (0.00 sec)

这样排序优化是有效的。

无法优化的情况9

使用的表索引的类型不能按顺序保存行。例如，对于HEAP表的HASH索引情况即如此。有不同的ORDER BY和GROUP BY表达式

要测试这种情况，我们得新建一张表：

CREATE TABLE `heap_test` (

`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',

`name` varchar(20) NOT NULL COMMENT '名称',

PRIMARY KEY (`id`),

KEY `name` (`name`)

)

ENGINE=MEMORY

AUTO_INCREMENT=3

DEFAULTCHARSET=utf8

COMMENT='测试heap表'

插入几条记录：

INSERT INTO `heap_test` (`id`, `name`) VALUES

(1, '张三'),

(2, '李四');

测试一下：

mysql>EXPLAIN SELECT * FROM heap_test FORCE INDEX(name) ORDER BY name;

+----+-------------+-----------+------+---------------+------+---------+------+------+----------------+

| id | select_type | table     | type | possible_keys | key  | key_len | ref  | rows | Extra          |

+----+-------------+-----------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | heap_test | ALL  | NULL          | NULL | NULL    | NULL |    2 | Using filesort |

+----+-------------+-----------+------+---------------+------+---------+------+------+----------------+

1 row in set (0.00 sec)

的确排序优化无效。

除了以上的情况，还有几个要注意的地方。

注意点1

字段别名对排序的影响：

mysql>EXPLAIN SELECT ABS(shop_id) shop_id FROM shop FORCE INDEX(shop_id) ORDER BY shop_id;

+----+-------------+-------+-------+---------------+---------+---------+------+------+-----------------------------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                       |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-----------------------------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 | Using index; Using filesort |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-----------------------------+

1 row in set (0.00 sec)

这个例子中我们对shop_id取绝对值并给了一个别名shop_id，不幸的是，这个表中的确有一个字段叫shop_id，此时按shop_id排序，用到的是别名而不是字段，即使强制使用了shop_id索引也无效。对于这种情况，换一个别名就可以解决：

mysql>EXPLAIN SELECT ABS(shop_id) shop_new_id FROM shop FORCE INDEX(shop_id) ORDER BY shop_id;

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 | Using index |

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

1 row in set (0.00 sec)

注意点2

GROUP BY默认会对字段排序，跟你显示的按分组字段ORDER BY一样，写不写出来都一样，没有性能损失。如果想避免GROUP BY的排序开销，可以强制指定取消排序，先看一下不取消的情况：

mysql>EXPLAIN SELECT goods_id, COUNT(1) FROM shop FORCE INDEX(shop_id) GROUP BY goods_id;

+----+-------------+-------+-------+---------------+---------+---------+------+------+----------------------------------------------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                                        |

+----+-------------+-------+-------+---------------+---------+---------+------+------+----------------------------------------------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 | Using index; Using temporary; Using filesort |

+----+-------------+-------+-------+---------------+---------+---------+------+------+----------------------------------------------+

1 row in set (0.00 sec)

再看一下取消的情况：

mysql>EXPLAIN SELECT goods_id, COUNT(1) FROM shop FORCE INDEX(shop_id) GROUP BY goods_id ORDER BY null;

+----+-------------+-------+-------+---------------+---------+---------+------+------+------------------------------+

| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                        |

+----+-------------+-------+-------+---------------+---------+---------+------+------+------------------------------+

|  1 | SIMPLE      | shop  | index | NULL          | shop_id | 8       | NULL |    7 | Using index; Using temporary |

+----+-------------+-------+-------+---------------+---------+---------+------+------+------------------------------+

1 row in set (0.00 sec)

此时已经没有了Using filesort。

注意点3

如果排序不可避免，可以用下面的办法加速：

增加sort_buffer_size变量的大小。

增加read_rnd_buffer_size变量的大小。

更改tmpdir指向具有大量空闲空间的专用文件系统。


出处：http://ustb80.blog.51cto.com/6139482/1073352

你可能感兴趣的:(MySQL ORDER BY优化的那些事儿)

  • 斤斤计较的婚姻到底有多难？ 白心之岂必有为
    很多人私聊我会问到在哪个人群当中斤斤计较的人最多？我都会回答他，一般婚姻出现问题的斤斤计较的人士会非常多，以我多年经验，在婚姻落的一塌糊涂的人当中，斤斤计较的人数占比在20～30%以上，也就是说10个婚姻出现问题的斤斤计较的人有2-3个有多不减。在婚姻出问题当中，有大量的心理不平衡的、尖酸刻薄的怨妇。在婚姻中仅斤斤计较有两种类型：第一种是物质上的，另一种是精神上的。在物质与精神上抠门已经严重的影响
  • 情绪觉察日记第37天 露露_e800
    今天是家庭关系规划师的第二阶最后一天，慧萍老师帮我做了个案，帮我处理了埋在心底好多年的一份恐惧，并给了我深深的力量！这几天出来学习，爸妈过来婆家帮我带小孩，妈妈出于爱帮我收拾东西，并跟我先生和婆婆产生矛盾，妈妈觉得他们没有照顾好我…。今晚回家见到妈妈，我很欣赏她并赞扬她，妈妈说今晚要跟我睡我说好，当我们俩躺在床上准备睡觉的时候，我握着妈妈的手对她说:妈妈这几天辛苦你了，你看你多利害把我们的家收拾得
  • 芦花鞋一四 许叶晗
    又是在一个寒冷的夏日里，青铜和葵花决定今天一起去卖芦花鞋，奶奶亲手给他们做了一碗热乎乎的粥对他们说:“就靠你们两挣生活费了这碗粥赶紧趁热喝了吧！”于是青铜和葵花喝完了奶奶给她们做的粥，就准备去镇上卖卢花鞋，这回青铜和葵花穿着新的芦花鞋来到了镇上。青铜这回看到了很多人都在卖，用手势表达对葵花说:“这回有好多人在抢我们生意呢！我们必须得吆喝起来。”葵花点了点头。可是谁知他们也大声的叫，卖芦花喽！卖芦花
  • QQ群采集助手，精准引流必备神器 2401_87347160 其他经验分享
    功能概述微信群查找与筛选工具是一款专为微信用户设计的辅助工具，它通过关键词搜索功能，帮助用户快速找到相关的微信群，并提供筛选是否需要验证的群组的功能。主要功能关键词搜索：用户可以输入关键词，工具将自动查找包含该关键词的微信群。筛选功能：工具提供筛选机制，用户可以选择是否只显示需要验证或不需要验证的群组。精准引流：通过上述功能，用户可以更精准地找到目标群组，进行有效的引流操作。3.设备需求该工具可以
  • 关于沟通这件事，项目经理不需要每次都面对面进行 流程大师兄
    很多项目经理都会遇到这样的问题，项目中由于事情太多，根本没有足够的时间去召开会议，那在这种情况下如何去有效地管理项目中的利益相关者？当然，不建议电子邮件也不需要开会的话，建议可以采取下面几种方式来形成有效的沟通，这几种方式可以帮助你努力的通过各种办法来保持和各方面的联系。项目经理首先要问自己几个问题，项目中哪些利益相关者是必须要进行沟通的？可以列出项目中所有的利益相关者清单，同时也整理出项目中哪些
  • 机器学习与深度学习间关系与区别 ℒℴѵℯ心·动ꦿ໊ོ꫞ 人工智能学习深度学习python
    一、机器学习概述定义机器学习（MachineLearning,ML）是一种通过数据驱动的方法，利用统计学和计算算法来训练模型，使计算机能够从数据中学习并自动进行预测或决策。机器学习通过分析大量数据样本，识别其中的模式和规律，从而对新的数据进行判断。其核心在于通过训练过程，让模型不断优化和提升其预测准确性。主要类型1.监督学习（SupervisedLearning）监督学习是指在训练数据集中包含输入
  • 铭刻于星（四十二） 随风至
    69夜晚，绍敏同学做完功课后，看了眼房外，没听到动静才敢从书包的夹层里拿出那个心形纸团。折痕压得很深，都有些旧了，想来是已经写好很久了。绍敏同学慢慢地、轻轻地捏开折叠处，待到全部拆开后，又反复抚平纸张，然后仔细地一字字默看。只是开头的三个字是第一次看到，让她心漏跳了几拍。“亲爱的绍敏：从四年级的时候，我就喜欢你了，但是我一直不敢说，怕影响你学习。六年级的时候听说有人跟你表白，你接受了，我很难过，但
  • 底层逆袭到底有多难，不甘平凡的你准备好了吗？让吴起给你说说 造命者说
    底层逆袭到底有多难，不甘平凡的你准备好了吗？让吴起给你说说我叫吴起，生于公元前440年的战国初期，正是群雄并起、天下纷争不断的时候。后人说我是军事家、政治家、改革家，是兵家代表人物。评价我一生历仕鲁、魏、楚三国，通晓兵家、法家、儒家三家思想，在内政军事上都有极高的成就。周安王二十一年（公元前381年），因变法得罪守旧贵族，被人乱箭射死。我出生在卫国一个“家累万金”的富有家庭，从年轻时候起就不甘平凡
  • 2020-01-25 晴岚85
    郑海燕坚持分享590天2020.1.24在生活中只存在两个问题。一个问题是：你知道想要达成的目标是什么，但却不知道如何才能达成；另一个问题是：你不知道你的目标是什么。前一个是行动的问题，后一个是结果的问题。通过制定具体的下一步行动，可以解决不知道如何开始行动的问题。而通过去想象结果，对结果做预估，可以解决找不着目标的问题。对于所有吸引我们注意力，想要完成的任务，你可以先想象一下，预期的结果究竟是什
  • 随笔 | 仙一般的灵气 海思沧海
    仙岛今天，我看了你全部，似乎已经进入你的世界我不知道，这是否是梦幻，还是你仙一般的灵气吸引了我也许每一个人都要有一份属于自己的追求，这样才能够符合人生的梦想，生活才能够充满着阳光与快乐我不知道，我为什么会这样的感叹，是在感叹自己的人生，还是感叹自己一直没有孜孜不倦的追求只感觉虚度了光阴，每天活在自己的梦中，活在一个不真实的世界是在逃避自己，还是在逃避周围的一切有时候我嘲笑自己，嘲笑自己如此的虚无，
  • 想家 爆米花机
    也许不同于大家对家乡的思念，我对家乡甚至是疯狂的不舍。还未踏出车站就感觉到幸福，我享受这里的夕阳、这里的浓烈柴火味、这里每一口家常菜。我是宅女，我贪恋家的安逸。刚刚踏出大学校门，初出茅庐，无法适应每年只能国庆和春节回家。我焦虑、失眠、无端发脾气，是无法适应工作的节奏，是无法接受我将一步步离开家乡的事实。我不想承认自己胸无大志，选择再次踏上征程。图片发自App
  • 【iOS】MVC设计模式 Magnetic_h iosmvc设计模式objective-c学习ui
    MVC前言如何设计一个程序的结构，这是一门专门的学问，叫做"架构模式"（architecturalpattern），属于编程的方法论。MVC模式就是架构模式的一种。它是Apple官方推荐的App开发架构，也是一般开发者最先遇到、最经典的架构。MVC各层controller层Controller/ViewController/VC（控制器）负责协调Model和View，处理大部分逻辑它将数据从Mod
  • OC语言多界面传值五大方式 Magnetic_h iosui学习objective-c开发语言
    前言在完成暑假仿写项目时，遇到了许多需要用到多界面传值的地方，这篇博客来总结一下比较常用的五种多界面传值的方式。属性传值属性传值一般用前一个界面向后一个界面传值，简单地说就是通过访问后一个视图控制器的属性来为它赋值，通过这个属性来做到从前一个界面向后一个界面传值。首先在后一个界面中定义属性@interfaceBViewController:UIViewController@propertyNSSt
  • 一百九十四章. 自相矛盾 巨木擎天
    唉！就这么一夜，林子感觉就像过了很多天似的，先是回了阳间家里，遇到了那么多不可思议的事情儿。特别是小伙伴们，第二次与自己见面时，僵硬的表情和恐怖的气氛，让自己如坐针毡，打从心眼里难受！还有东子，他现在还好吗？有没有被人欺负？护城河里的小鱼小虾们，还都在吗？水不会真的干枯了吧？那对相亲相爱漂亮的太平鸟儿，还好吧！春天了，到了做窝、下蛋、喂养小鸟宝宝的时候了，希望它们都能够平安啊！虽然没有看见家人，也
  • UI学习——cell的复用和自定义cell Magnetic_h ui学习
    目录cell的复用手动（非注册）自动（注册）自定义cellcell的复用在iOS开发中，单元格复用是一种提高表格（UITableView）和集合视图（UICollectionView）滚动性能的技术。当一个UITableViewCell或UICollectionViewCell首次需要显示时，如果没有可复用的单元格，则视图会创建一个新的单元格。一旦这个单元格滚动出屏幕，它就不会被销毁。相反，它被添
  • element实现动态路由+面包屑 软件技术NINI vue案例vue.js前端
    el-breadcrumb是ElementUI组件库中的一个面包屑导航组件，它用于显示当前页面的路径，帮助用户快速理解和导航到应用的各个部分。在Vue.js项目中，如果你已经安装了ElementUI，就可以很方便地使用el-breadcrumb组件。以下是一个基本的使用示例：安装ElementUI（如果你还没有安装的话）:你可以通过npm或yarn来安装ElementUI。bash复制代码npmi
  • 10月|愿你的青春不负梦想-读书笔记-01 Tracy的小书斋
    本书的作者是俞敏洪，大家都很熟悉他了吧。俞敏洪老师是我行业的领头羊吧，也是我事业上的偶像。本日摘录他书中第一章中的金句：『一个人如果什么目标都没有，就会浑浑噩噩，感觉生命中缺少能量。能给我们能量的，是对未来的期待。第一件事，我始终为了进步而努力。与其追寻全世界的骏马，不如种植丰美的草原，到时骏马自然会来。第二件事，我始终有阶段性的目标。什么东西能给我能量？答案是对未来的期待。』读到这里的时候，我便
  • C语言宏函数 南林yan C语言c语言
    一、什么是宏函数？通过宏定义的函数是宏函数。如下，编译器在预处理阶段会将Add(x,y)替换为((x)*(y))#defineAdd(x,y)((x)*(y))#defineAdd(x,y)((x)*(y))intmain(){inta=10;intb=20;intd=10;intc=Add(a+d,b)*2;cout<
  • 地推话术，如何应对地推过程中家长的拒绝 校师学
    相信校长们在做地推的时候经常遇到这种情况：市场专员反馈家长不接单，咨询师反馈难以邀约这些家长上门，校区地推疲软，招生难。为什么？仅从地推层面分析，一方面因为家长受到的信息轰炸越来越多，对信息越来越“免疫”；而另一方面地推人员的专业能力和营销话术没有提高，无法应对家长的拒绝，对有意向的家长也不知如何跟进，眼睁睁看着家长走远；对于家长的疑问，更不知道如何有技巧地回答，机会白白流失。由于回答没技巧和专业
  • 谢谢你们，爱你们！ 鹿游儿
    昨天家人去泡温泉，二个孩子也带着去，出发前一晚，匆匆下班，赶回家和孩子一起收拾。饭后，我拿出笔和本子（上次去澳门时做手帐的本子）写下了1\2\3\4\5\6\7\8\9,让后让小壹去思考，带什么出发去旅游呢？她在对应的数字旁边画上了，泳衣、泳圈、肖恩、内衣内裤、tapuy、拖鞋……画完后，就让她自己对着这个本子，将要带的，一一带上，没想到这次带的书还是这本《便便工厂》(晚上姑婆发照片过来，妹妹累得
  • C语言如何定义宏函数？ 小九格物 c语言
    在C语言中，宏函数是通过预处理器定义的，它在编译之前替换代码中的宏调用。宏函数可以模拟函数的行为，但它们不是真正的函数，因为它们在编译时不会进行类型检查，也不会分配存储空间。宏函数的定义通常使用#define指令，后面跟着宏的名称和参数列表，以及宏展开后的代码。宏函数的定义方式：1.基本宏函数：这是最简单的宏函数形式，它直接定义一个表达式。#defineSQUARE(x)((x)*(x))2.带参
  • 微服务下功能权限与数据权限的设计与实现 nbsaas-boot 微服务java架构
    在微服务架构下，系统的功能权限和数据权限控制显得尤为重要。随着系统规模的扩大和微服务数量的增加，如何保证不同用户和服务之间的访问权限准确、细粒度地控制，成为设计安全策略的关键。本文将讨论如何在微服务体系中设计和实现功能权限与数据权限控制。1.功能权限与数据权限的定义功能权限：指用户或系统角色对特定功能的访问权限。通常是某个用户角色能否执行某个操作，比如查看订单、创建订单、修改用户资料等。数据权限：
  • 理解Gunicorn：Python WSGI服务器的基石 范范0825 ipythonlinux运维
    理解Gunicorn：PythonWSGI服务器的基石介绍Gunicorn，全称GreenUnicorn，是一个为PythonWSGI（WebServerGatewayInterface）应用设计的高效、轻量级HTTP服务器。作为PythonWeb应用部署的常用工具，Gunicorn以其高性能和易用性著称。本文将介绍Gunicorn的基本概念、安装和配置，帮助初学者快速上手。1.什么是Gunico
  • 小丽成长记（四十三） 玲玲54321
    小丽发现，即使她好不容易调整好自己的心态下一秒总会有不确定的伤脑筋的事出现，一个接一个的问题，人生就没有停下的时候，小问题不断出现。不过她今天看的书，她接受了人生就是不确定的，厉害的人就是不断创造确定性，在Ta的领域比别人多的确定性就能让自己脱颖而出，显示价值从而获得的比别人多的利益。正是这样的原因，因为从前修炼自己太少，使得她现在在人生道路上打怪起来困难重重，她似乎永远摆脱不了那种无力感，有种习
  • 学点心理知识，呵护孩子健康 静候花开_7090
    昨天听了华中师范大学教育管理学系副教授张玲老师的《哪里才是学生心理健康的最后庇护所，超越教育与技术的思考》的讲座。今天又重新学习了一遍，收获匪浅。张玲博士也注意到了当今社会上的孩子由于心理问题导致的自残、自杀及伤害他人等恶性事件。她向我们普及了一个重要的命题，她说心理健康的一些基本命题，我们与我们通常的一些教育命题是不同的，她还举了几个例子，让我们明白我们原来以为的健康并非心理学上的健康。比如如果
  • 2021年12月19日，春蕾教育集团团建活动感受——黄晓丹 黄错错加油
    感受:1.从陌生到熟悉的过程。游戏环节让我们在轻松的氛围中得到了锻炼，也增长了不少知识。2.游戏过程中，我们贡献的是个人力量，展现的是团队的力量。它磨合的往往不止是工作的熟悉，更是观念上契合度的贴近。3.这和工作是一样的道理。在各自的岗位上，每个人摆正自己的位置、各司其职充分发挥才能，并团结一致劲往一处使，才能实现最大的成功。新知:1.团队精神需要不断地创新。过去，人们把创新看作是冒风险，现在人们
  • Cell Insight | 单细胞测序技术又一新发现，可用于HIV-1和Mtb共感染个体诊断 尐尐呅
    结核病是艾滋病合并其他疾病中导致患者死亡的主要原因。其中结核病由结核分枝杆菌（Mycobacteriumtuberculosis,Mtb）感染引起，获得性免疫缺陷综合症（艾滋病）由人免疫缺陷病毒（Humanimmunodeficiencyvirustype1,HIV-1）感染引起。国家感染性疾病临床医学研究中心/深圳市第三人民医院张国良团队携手深圳华大生命科学研究院吴靓团队，共同研究得出单细胞测序
  • c++ 的iostream 和 c++的stdio的区别和联系 黄卷青灯77 c++算法开发语言iostreamstdio
    在C++中，iostream和C语言的stdio.h都是用于处理输入输出的库，但它们在设计、用法和功能上有许多不同。以下是两者的区别和联系：区别1.编程风格iostream（C++风格）：C++标准库中的输入输出流类库，支持面向对象的输入输出操作。典型用法是cin（输入）和cout（输出），使用>操作符来处理数据。更加类型安全，支持用户自定义类型的输入输出。#includeintmain(){in
  • 瑶池防线 谜影梦蝶
    冥华虽然逃过了影梦的军队，但他是一个忠臣，他选择上报战况。败给影梦后成逃兵，高层亡尔还活着，七重天失守......随便一条，即可处死冥华。冥华自然是知道以仙界高层的习性此信一发自己必死无疑，但他还选择上报实情，因为责任。同样此信送到仙宫后，知道此事的人，大多数人都认定冥华要完了，所以上到仙界高层，下到扫大街的，包括冥华自己，全都准备好迎接冥华之死。如果仙界现在还属于两方之争的话，冥华必死无疑。然而
  • 爬山后遗症 璃绛
    爬山，攀登，一步一步走向制高点，是一种挑战。成功抵达是一种无法言语的快乐，在山顶吹吹风，看看风景，这是从未有过的体验。然而，爬山一时爽，下山腿打颤，颠簸的路，一路向下走，腿部力量不够，走起来抖到不行，停不下来了！第二天必定腿疼，浑身酸痛，坐立难安！
  • 用MiddleGenIDE工具生成hibernate的POJO（根据数据表生成POJO类） AdyZhang POJOeclipseHibernateMiddleGenIDE
    推荐:MiddlegenIDE插件,   是一个Eclipse   插件.     用它可以直接连接到数据库,   根据表按照一定的HIBERNATE规则作出BEAN和对应的XML ，用完后你可以手动删除它加载的JAR包和XML文件!     今天开始试着使用
  • .9.png Cb123456 android
      “点九”是andriod平台的应用软件开发里的一种特殊的图片形式，文件扩展名为：.9.png 　　智能手机中有自动横屏的功能,同一幅界面会在随着手机(或平板电脑)中的方向传感器的参数不同而改变显示的方向,在界面改变方向后,界面上的图形会因为长宽的变化而产生拉伸,造成图形的失真变形。 　　我们都知道android平台有多种不同的分辨率，很多控件的切图文件在被放大拉伸后，边
  • 算法的效率 天子之骄 算法效率复杂度最坏情况运行时间大O阶平均情况运行时间
    算法的效率 效率是速度和空间消耗的度量。集中考虑程序的速度，也称运行时间或执行时间，用复杂度的阶(O)这一标准来衡量。空间的消耗或需求也可以用大O表示，而且它总是小于或等于时间需求。   以下是我的学习笔记：   1.求值与霍纳法则，即为秦九韶公式。   2.测定运行时间的最可靠方法是计数对运行时间有贡献的基本操作的执行次数。运行时间与这个计数成正比。
  • java数据结构 何必如此 java数据结构
    Java 数据结构 Java工具包提供了强大的数据结构。在Java中的数据结构主要包括以下几种接口和类： 枚举（Enumeration） 位集合（BitSet） 向量（Vector） 栈（Stack） 字典（Dictionary） 哈希表（Hashtable） 属性（Properties） 以上这些类是传统遗留的，在Java2中引入了一种新的框架-集合框架(Collect
  • MybatisHelloWorld 3213213333332132
    //测试入口TestMyBatis package com.base.helloworld.test; import java.io.IOException; import org.apache.ibatis.io.Resources; import org.apache.ibatis.session.SqlSession; import org.apache.ibat
  • Java|urlrewrite|URL重写|多个参数 7454103 javaxmlWeb工作
     个人工作经验！ 如有不当之处，敬请指点 1.0  web -info 目录下建立     urlrewrite.xml  文件 类似如下： <?xml version="1.0" encoding="UTF-8" ?>   <!DOCTYPE u
  • 达梦数据库+ibatis darkranger sqlmysqlibatisSQL Server
    --插入数据方面 如果您需要数据库自增... 那么在插入的时候不需要指定自增列. 如果想自己指定ID列的值, 那么要设置 set identity_insert  数据库名.模式名.表名; ----然后插入数据; example: create table zhabei.test( id bigint identity(1,1) primary key, nam
  • XML 解析 四种方式 aijuans android
    XML现在已经成为一种通用的数据交换格式,平台的无关性使得很多场合都需要用到XML。本文将详细介绍用Java解析XML的四种方法。 XML现在已经成为一种通用的数据交换格式,它的平台无关性,语言无关性,系统无关性,给数据集成与交互带来了极大的方便。对于XML本身的语法知识与技术细节,需要阅读相关的技术文献,这里面包括的内容有DOM(Document Object
  • spring中配置文件占位符的使用 avords
    1.类 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.o
  • 前端工程化-公共模块的依赖和常用的工作流 bee1314 webpack
    题记： 一个人的项目，还有工程化的问题嘛？   我们在推进模块化和组件化的过程中，肯定会不断的沉淀出我们项目的模块和组件。对于这些沉淀出的模块和组件怎么管理？另外怎么依赖也是个问题？ 你真的想这样嘛？   var BreadCrumb = require(‘../../../../uikit/breadcrumb’); //真心ugly。  
  • 上司说「看你每天准时下班就知道你工作量不饱和」，该如何回应？ bijian1013 项目管理沟通IT职业规划
    问题：上司说「看你每天准时下班就知道你工作量不饱和」，如何回应         正常下班时间6点，只要是6点半前下班的，上司都认为没有加班。   Eno-Bea回答，注重感受，不一定是别人的         虽然我不知道你具体从事什么工作与职业，但是我大概猜测，你是从事一项不太容易出现阶段性成果的工作
  • TortoiseSVN，过滤文件 征客丶 SVN
    环境： TortoiseSVN 1.8 配置： 在文件夹空白处右键 选择  TortoiseSVN -> Settings 在 Global ignote pattern 中添加要过滤的文件： 多类型用英文空格分开 *name ： 过滤所有名称为 name 的文件或文件夹 *.name ： 过滤所有后缀为 name 的文件或文件夹 --------
  • 【Flume二】HDFS sink细说 bit1129 Flume
    1. Flume配置   a1.sources=r1 a1.channels=c1 a1.sinks=k1 ###Flume负责启动44444端口 a1.sources.r1.type=avro a1.sources.r1.bind=0.0.0.0 a1.sources.r1.port=44444 a1.sources.r1.chan
  • The Eight Myths of Erlang Performance bookjovi erlang
    erlang有一篇guide很有意思： http://www.erlang.org/doc/efficiency_guide 里面有个The Eight Myths of Erlang Performance： http://www.erlang.org/doc/efficiency_guide/myths.html   Myth: Funs are sl
  • java多线程网络传输文件(非同步)-2008-08-17 ljy325 java多线程socket
    利用 Socket 套接字进行面向连接通信的编程。客户端读取本地文件并发送；服务器接收文件并保存到本地文件系统中。 使用说明:请将TransferClient, TransferServer, TempFile三个类编译，他们的类包是FileServer. 客户端: 修改TransferClient: serPort, serIP, filePath, blockNum,的值来符合您机器的系
  • 读《研磨设计模式》-代码笔记-模板方法模式 bylijinnan java设计模式
    声明： 本文只为方便我个人查阅和理解，详细的分析以及源代码请移步 原作者的博客http://chjavach.iteye.com/ import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; import java.sql.ResultSet;
  • 配置心得 chenyu19891124 配置
    时间就这样不知不觉的走过了一个春夏秋冬，转眼间来公司已经一年了，感觉时间过的很快，时间老人总是这样不停走，从来没停歇过。 作为一名新手的配置管理员，刚开始真的是对配置管理是一点不懂，就只听说咱们公司配置主要是负责升级，而具体该怎么做却一点都不了解。经过老员工的一点点讲解，慢慢的对配置有了初步了解，对自己所在的岗位也慢慢的了解。 做了一年的配置管理给自总结下： 1.改变 从一个以前对配置毫无
  • 对“带条件选择的并行汇聚路由问题”的再思考 comsci 算法工作软件测试嵌入式领域模型
    2008年上半年，我在设计并开发基于”JWFD流程系统“的商业化改进型引擎的时候，由于采用了新的嵌入式公式模块而导致出现“带条件选择的并行汇聚路由问题”(请参考2009-02-27博文)，当时对这个问题的解决办法是采用基于拓扑结构的处理思想，对汇聚点的实际前驱分支节点通过算法预测出来，然后进行处理，简单的说就是找到造成这个汇聚模型的分支起点，对这个起始分支节点实际走的路径数进行计算，然后把这个实际
  • Oracle 10g 的clusterware 32位 下载地址 daizj oracle
    Oracle 10g 的clusterware 32位 下载地址 http://pan.baidu.com/share/link?shareid=531580&uk=421021908 http://pan.baidu.com/share/link?shareid=137223&uk=321552738 http://pan.baidu.com/share/l
  • 非常好的介绍：Linux定时执行工具cron dongwei_6688 linux
    Linux经过十多年的发展，很多用户都很了解Linux了，这里介绍一下Linux下cron的理解，和大家讨论讨论。cron是一个Linux 定时执行工具，可以在无需人工干预的情况下运行作业，本文档不讲cron实现原理，主要讲一下Linux定时执行工具cron的具体使用及简单介绍。 新增调度任务推荐使用crontab -e命令添加自定义的任务（编辑的是/var/spool/cron下对应用户的cr
  • Yii assets目录生成及修改 dcj3sjt126com yii
    assets的作用是方便模块化，插件化的，一般来说出于安全原因不允许通过url访问protected下面的文件，但是我们又希望将module单独出来，所以需要使用发布，即将一个目录下的文件复制一份到assets下面方便通过url访问。 assets设置对应的方法位置 \framework\web\CAssetManager.php   assets配置方法 在m
  • mac工作软件推荐 dcj3sjt126com mac
    mac上的Terminal + bash ＋ screen组合现在已经非常好用了，但是还是经不起iterm＋zsh＋tmux的冲击。在同事的强烈推荐下，趁着升级mac系统的机会，顺便也切换到iterm＋zsh＋tmux的环境下了。 我为什么要要iterm2 切换过来也是脑袋一热的冲动，我也调查过一些资料，看了下iterm的一些优点： * 兼容性好，远程服务器 vi 什么的低版本能很好兼
  • Memcached(三)、封装Memcached和Ehcache frank1234 memcachedehcachespring ioc
    本文对Ehcache和Memcached进行了简单的封装，这样对于客户端程序无需了解ehcache和memcached的差异，仅需要配置缓存的Provider类就可以在二者之间进行切换，Provider实现类通过Spring IoC注入。 cache.xml <?xml version="1.0" encoding="UTF-8"?>
  • Remove Duplicates from Sorted List II hcx2013 remove
    Given a sorted linked list, delete all nodes that have duplicate numbers, leaving only distinct numbers from the original list. For example,Given 1->2->3->3->4->4->5,
  • Spring4新特性——注解、脚本、任务、MVC等其他特性改进 jinnianshilongnian spring4
    Spring4新特性——泛型限定式依赖注入 Spring4新特性——核心容器的其他改进 Spring4新特性——Web开发的增强 Spring4新特性——集成Bean Validation 1.1(JSR-349)到SpringMVC  Spring4新特性——Groovy Bean定义DSL Spring4新特性——更好的Java泛型操作API  Spring4新
  • MySQL安装文档 liyong0802 mysql
      工作中用到的MySQL可能安装在两种操作系统中，即Windows系统和Linux系统。以Linux系统中情况居多。   安装在Windows系统时与其它Windows应用程序相同按照安装向导一直下一步就即，这里就不具体介绍，本文档只介绍Linux系统下MySQL的安装步骤。   Linux系统下安装MySQL分为三种：RPM包安装、二进制包安装和源码包安装。二
  • 使用VS2010构建HotSpot工程 p2p2500 HotSpotOpenJDKVS2010
    1. 下载OpenJDK7的源码：      http://download.java.net/openjdk/jdk7      http://download.java.net/openjdk/      2. 环境配置     ▶
  • Oracle实用功能之分组后列合并 seandeng888 oracle分组实用功能合并
    1       实例解析 由于业务需求需要对表中的数据进行分组后进行合并的处理，鉴于Oracle10g没有现成的函数实现该功能，且该功能如若用JAVA代码实现会比较复杂，因此，特将SQL语言的实现方式分享出来，希望对大家有所帮助。如下： 表test 数据如下： ID,SUBJECTCODE,DIMCODE,VALUE 1&nbs
  • Java定时任务注解方式实现 tuoni javaspringjvmxmljni
    Spring 注解的定时任务，有如下两种方式： 第一种： <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"  xmlns:xsi="http
  • 11大Java开源中文分词器的使用方法和分词效果对比 yangshangchuan word分词器ansj分词器Stanford分词器FudanNLP分词器HanLP分词器
    本文的目标有两个： 1、学会使用11大Java开源中文分词器 2、对比分析11大Java开源中文分词器的分词效果 本文给出了11大Java开源中文分词的使用方法以及分词结果对比代码，至于效果哪个好，那要用的人结合自己的应用场景自己来判断。 11大Java开源中文分词器，不同的分词器有不同的用法，定义的接口也不一样，我们先定义一个统一的接口： /** * 获取文本的所有分词结果, 对比
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他