无效楼层，该帖已经被删除。治疗几颗青春痘 结果全身牛皮癣 还有更脑残的设计吗？

国家特级残废啊，其残次程度不亚于XXX没屁眼。

主要为了解决少数的高层帖子问题，而把所有的帖子都打残废了。
打个比恰当的比喻：为了治疗脸上几颗小青春痘，结果青春痘没了，但全身牛皮癣。

以前的高层帖子与普通帖子，两种机制，不是挺好的嘛，为什么统一？
统一就统一吧，也是少数高层帖子适应多数普通帖子，而不是把多数的普通帖子打残，适应少数高层帖子。

已经无数人来吐嘈了，没办法，设计如此。
部分原因是开发人员，大部分原因是mysql的包袱

楼主不用这么激动啦，因为你还没见过更让你蛋痛的设计

大家都知道MyISAM是表锁，Innodb是行锁，在大并发读写时后者的性能更好。
但是，细节是魔鬼。innodb照样会表锁的：

InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。
（1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
在如表20-9所示的例子中，开始tab_no_index表没有索引：

2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。应用设计的时候要注意这一点。

（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。

（4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。关于MySQL在什么情况下不使用索引的详细讨论，参见本章“索引问题”一节的介绍。
在下面的例子中，检索值的数据类型与索引字段不同，虽然MySQL能够进行数据类型转换，但却不会使用索引，从而导致InnoDB使用表锁。通过用explain检查两条SQL的执行计划，我们可以清楚地看到了这一点。
例子中tab_with_index表的name字段有索引，但是name字段是varchar类型的，如果where条件中不是和varchar类型进行比较，则会对name进行类型转换，而执行的全表扫描。

锁索引而不是锁数据，无索引就表锁，有索引遇上GAP照样表锁…… mysql这货周身都是窟窿
开发人员才是真正的蛋痛，尤其是是从oracle、db2等等转过来的人，在其他db上面自然而然都有的功能居然在mysql上面找不到。

mark35 发表于 2012-9-24 20:48
已经无数人来吐嘈了，没办法，设计如此。
部分原因是开发人员，大部分原因是mysql的包袱

MYSQL的瓶颈确实存在。
但“无效楼层”这个设计确实是败笔，主要为了解决少数的高层帖子问题，而把所有的帖子都打残废了。
打个比恰当的比喻：为了治疗脸上几颗小青春痘，结果青春痘没了，但全身牛皮癣。

以前的高层帖子与普通帖子，两种机制，不是挺好的嘛，为什么统一？
统一就统一吧，也是少数高层帖子适应多数普通帖子，而不是把多数的普通帖子打残，适应少数高层帖子。

上班困怎么办

anywy 发表于 2012-9-25 09:27
MYSQL的瓶颈确实存在。
但“无效楼层”这个设计确实是败笔，主要为了解决少数的高层帖子问题，而把所有 ...

以前的两种机制会导致（排序）混乱的。所以就统一，但解决方法实在是不敢恭维。
其实有个完美的解决方案，我这儿已经测试成功。只不过在mysql这烂货上面比较麻烦

呜呜呜 困困困

不懂。。。。

呵呵，这个问题确实有点搞笑

难道这就是老年病。。官方已经衰老了？