一个文章表的 MySQL 索引怎么建立合理

Question

有如下结构的MySQL 表 CREATE TABLE `t_article` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `content` varchar(255) NOT NULL COMMENT '内容', `like_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '点赞数', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 COMMENT='文章表'; 插入数据： INSERT INTO `t_article` (`id`, `content`, `like_count`) VALUES ('1', 'aaa', '4'); INSERT INTO `t_article` (`id`, `content`, `like_count`) VALUES ('2', 'rrrr', '53'); INSERT INTO `t_article` (`id`, `content`, `like_count`) VALUES ('3', 'ttt', '7'); INSERT INTO `t_article` (`id`, `content`, `like_count`) VALUES ('4', 'rree', '6'); INSERT INTO `t_article` (`id`, `content`, `like_count`) VALUES ('5', 'rrr', '888'); 需求是查询文章列表，根据点赞数（like_count）字段从大到小排序，SQL 语句如下： SELECT id FROM t_article ORDER BY like_count DESC LIMIT 0,4; 怎么建立索引才合理，问题原由是看了很多大佬文章都会说索引字段不应该频繁更新，但是 like_count 这个字段肯定是经常更新的， 另外还有个衍生问题，如下SQL 执行的分析 type 为 index 有没有毛病，这个SQL没有用 where 条件，没有用 排序字段，但是还是会进行全表扫描，又该怎么优化呢 SELECT id FROM t_article LIMIT 0,4; EXPLAIN 分析

Answer 1

至于索引字段是否可以频繁修改的问题, 也要看数据量的大小, 如果你的数据量不是很大(如只有几十万),则完全不用考虑这个问题. 很多问题都可以等到数据量大到一定程序再回来解决, 因为过度设计真是很浪费.

查询一定要有排序字段, 否则结果顺序不可以预知. 有了排序字段, 也会用上合适的索引.
参见这个答案

Answer 2

首先 你可以考虑下你这样的表是否有问题？只记录点赞数你如何保证每个用户只点赞一次？
好吧 我们假设你有另外一个点赞表 然后这里也同步更新好了 那么它是否适合做索引？
那就取决于你对这个查询到底有多频繁？如果频繁查询还是要建索引的，哪怕频繁更新对索引维护有一定影响（其实有change_buffer在效率也还好啦）
最后你的那个SQL语句用的是聚集索引，也就是主键的那个索引

Answer 3

SELECT id FROM t_article WHERE id > 10000 ORDER BY like_count DESC LIMIT 0,4;
只会走id上的索引，即使有id和like_count的联合索引，也是忽略like_count列的索引了