如果你想过滤特定年份(例如2000年)的记录，那么优化WHERE子句，如下所示:

SELECT MONTH(date_column), COUNT(*)
FROM date_table
WHERE date_column >= '2000-01-01' AND date_column < '2001-01-01'
GROUP BY MONTH(date_column)
-- average 0.016 sec.

而不是:

WHERE YEAR(date_column) = 2000
-- average 0.132 sec.

结果是根据一个包含300k行和date列索引的表生成的。

至于GROUP BY子句，我根据上面提到的表测试了三个变体;以下是调查结果:

SELECT YEAR(date_column), MONTH(date_column), COUNT(*)
FROM date_table
GROUP BY YEAR(date_column), MONTH(date_column)
-- codelogic
-- average 0.250 sec.

SELECT YEAR(date_column), MONTH(date_column), COUNT(*)
FROM date_table
GROUP BY DATE_FORMAT(date_column, '%Y%m')
-- Andriy M
-- average 0.468 sec.

SELECT YEAR(date_column), MONTH(date_column), COUNT(*)
FROM date_table
GROUP BY EXTRACT(YEAR_MONTH FROM date_column)
-- fu-chi
-- average 0.203 sec.

最后一个是赢家。

如果你的搜索已经超过几年了，你仍然想每月分组，我建议:

版本1:

SELECT SQL_NO_CACHE YEAR(record_date), MONTH(record_date), COUNT(*)
FROM stats
GROUP BY DATE_FORMAT(record_date, '%Y%m')

版本#2(更有效):

SELECT SQL_NO_CACHE YEAR(record_date), MONTH(record_date), COUNT(*)
FROM stats
GROUP BY YEAR(record_date)*100 + MONTH(record_date)

我在一个大表上比较了这些版本，有1,357,918行(innodb)， 第二个版本的效果似乎更好。

版本1(平均执行10次):1.404秒 版本2(平均执行10次):0.780秒

(增加SQL_NO_CACHE键，防止MySQL对查询进行缓存。)

试试这个

SELECT COUNT(id)
FROM stats
GROUP BY EXTRACT(YEAR_MONTH FROM record_date)

EXTRACT(unit FROM date)函数更好，因为使用较少的分组，并且函数返回一个数字值。

分组时的比较条件将比DATE_FORMAT函数(返回字符串值)快。尝试使用函数|字段返回非字符串值的SQL比较条件(WHERE, HAVING, ORDER BY, GROUP BY)。

如果你想在MySQL中按日期分组，那么使用下面的代码:

 SELECT COUNT(id)
 FROM stats
 GROUP BY DAYOFMONTH(record_date)

希望这为那些要找到这个帖子的人节省了一些时间。

下面的查询在Oracle Database 12c Release 12.1.0.1.0中为我工作

SELECT COUNT(*)
FROM stats
GROUP BY 
extract(MONTH FROM TIMESTAMP),
extract(MONTH FROM TIMESTAMP),
extract(YEAR  FROM TIMESTAMP);

GROUP BY DATE_FORMAT(record_date, '%Y%m')

Note (primarily, to potential downvoters). Presently, this may not be as efficient as other suggestions. Still, I leave it as an alternative, and a one, too, that can serve in seeing how faster other solutions are. (For you can't really tell fast from slow until you see the difference.) Also, as time goes on, changes could be made to MySQL's engine with regard to optimisation so as to make this solution, at some (perhaps, not so distant) point in future, to become quite comparable in efficiency with most others.