俄罗斯方块

走TCP连接MySQL，即使是本地的MySQL。即：HOST用IP。

支持LZ，围观的人不仅犯法，还是二逼。

v2ex.com Alexa Traffic Rank: 6,710 Traffic Rank in CN: 926

我觉得即使是v2ex.com这样规模的站点，不管你是用php还是python抑或是ruby，都不会让v2ex这个产品因为技术原因而发展不下去。即使是重写一个，三种语言的使用者重写出来的速度估计也都差不多，谁快谁慢还真说不清楚。

所以我觉得需要考虑语言的特征和好坏，都是超大型项目比如facebook,twitter,weibo才需要考虑的，“你们”手上都在负责着怎么样的项目呢？对于大多数人，争论一点意义都木。

我觉得是那个人的品质问题，或者说他还没到成熟的时候，不管多少钱你既然已经答应了，最少也要把手头上的事情做完再走吧，再不济也要交接吧。

在上海不管8K，还是18K其实你生活的都那样。这确实不是钱的问题。

@kingwkb 嗷，那也没什么区别。

@kingwkb

group by aid,bid 上千万，也就是数据量在千万级别，我觉得效果没多大区别，如果你现在有上千万数据，跑下不就知道了。

aid 是你上文中说的场景中的 tag，group by aid 上千万，你有上千万的tag？

select sql_no_cache bid from d where aid=6 and bid in (select bid from d where aid=7);
select sql_no_cache bid from d where aid in (6,7) group by bid having count(*)=2;
select sql_no_cache t1.bid from d t1 ,d t2 where t1.aid=6 and t2.aid=7 and t1.bid=t2.bid;

三条SQL语句都经过反复执行，所消耗的时间也都稳定在如上的时间上。

就这个数据量来说，似乎

select sql_no_cache bid from d where aid in (6,7) group by bid having count(*)=2;

效率最高。

我造了点数据，测试了下。

mysql> show create table d\G
*************************** 1. row ***************************
Table: d
Create Table: CREATE TABLE `d` (
`aid` int(11) DEFAULT NULL,
`bid` int(11) DEFAULT NULL,
KEY `idx1` (`aid`,`bid`),
KEY `idx2` (`bid`,`aid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> select count(*) from d;
+----------+
| count(*) |
+----------+
| 465005 |
+----------+
1 row in set (0.36 sec)

mysql> select count(*) from (select count(*) from d group by aid,bid) t1;
+----------+
| count(*) |
+----------+
| 465005 |
+----------+
1 row in set (0.29 sec)

mysql> select aid,count(*) from d group by aid;
+------+----------+
| aid | count(*) |
+------+----------+
| 1 | 16640 |
| 2 | 16640 |
| 3 | 16640 |
| 4 | 16640 |
| 5 | 16640 |
| 6 | 33197 |
| 7 | 32448 |
| 11 | 16640 |
| 12 | 16640 |
| 13 | 16640 |
| 14 | 16640 |
| 15 | 16640 |
| 16 | 16640 |
| 17 | 16640 |
| 21 | 16640 |
| 22 | 16640 |
| 23 | 16640 |
| 24 | 16640 |
| 25 | 16640 |
| 26 | 16640 |
| 31 | 16640 |
| 32 | 16640 |
| 33 | 16640 |
| 34 | 16640 |
| 35 | 16640 |
| 36 | 16640 |
+------+----------+
26 rows in set (0.22 sec)

mysql> select count(*) from d where aid=7;
+----------+
| count(*) |
+----------+
| 32448 |
+----------+
1 row in set (0.03 sec)

mysql> select count(*) from d where aid=6;
+----------+
| count(*) |
+----------+
| 33197 |
+----------+
1 row in set (0.03 sec)

mysql> select sql_no_cache bid from d where aid=6 and bid in (select bid from d where aid=7);
| 331800 |
| 332000 |
| 332200 |
| 332400 |
| 332600 |
| 332800 |
+--------+
18221 rows in set (0.12 sec)

mysql> select sql_no_cache bid from d where aid in (6,7) group by bid having count(*)=2;
| 331800 |
| 332000 |
| 332200 |
| 332400 |
| 332600 |
| 332800 |
+--------+
18221 rows in set (0.08 sec)

mysql> select sql_no_cache t1.bid from d t1 ,d t2 where t1.aid=6 and t2.aid=7 and t1.bid=t2.bid;
| 331800 |
| 332000 |
| 332200 |
| 332400 |
| 332600 |
| 332800 |
+--------+
18221 rows in set (0.11 sec)

熬夜会 性冷淡。

个人觉得 OLTP 环境下 MySQL Partition 没什么作用。就目前硬件资源的价格以及用户对反应速度的需求，OLTP 环境下，把所有热点数据载入内存已经是标准需求了。数据可以全部载入内存了，文件再大也无所谓了。

对于 OLAP 环境，MySQL Partition 的目的是防止内存不够而文件过大造成文件系统性能低。所以是否用 MySQL Partition 也不是根据记录数来决定的，而是根据单表文件体积来定的，就上次他们讨论来看，似乎20G的时候分一下性能会提升不少。

sync_binlog=0的时候，不好意思，写错了。binlog是循序写的，只要对写磁盘实时要求不高性能很好。

MySQL本身似乎并没有这种功能，你有两种发放可以做到。

1.通过多实例的方式把不同的库放到不同的实例上，分别监控。

2.分析general log，MySQL开binlog在sync_binlog=1的时候性能损耗不到1%，开general log只会更低。

你一点都不爱她，让她走吧。

'blog' 多了两个单引号。