MySQL – 为什么COUNT的“大于”快但“小于”需要永远？

SELECT count(*) c FROM full_view WHERE verified > ( DATE (NOW()) - INTERVAL 30 DAY)

如果我运行该查询,它需要一瞬间,但如果我切换比较运算符,它需要很长时间.现在第一种方式count = 0,第二种方式count = 120000,但如果我只计算整个表也需要微秒.

但是有一些东西很时髦,因为如果查询完成它之后会非常快速地运行. MySQL正在缓存查询或者其他什么？好吧,我不想依赖缓存来确保网站不会挂起.

这似乎是荒谬的：如果它可以快速计算大于特定日期的所有内容,为什么还需要更长的时间来计算相反的情况呢？无论哪种方式,它必须透视整个表格吗？它需要返回的只是一个数字,因此带宽不应成为问题.

解释查询：

1, 'SIMPLE', 'b', 'range', 'updated,verified_index', 'updated', '3', '', 28, 'Using where'`    
1, 'SIMPLE', 'l', 'eq_ref', 'PRIMARY', 'PRIMARY', '4', 'xyz_main.b.loc_id', 1, 'Using index'
1, 'SIMPLE', 'f', 'ALL', '', '', '', '', 2214, ''

编辑：

这可能有些兴趣,我在运行查询时发现了这个信息：

Handler_read_rnd_next：

> 254436689(做不到的时候)
> 2(大于)

Key_read_requests：
314393 vs 33(33是使用大于时所有统计数据的最大数字)

Handler_read_key：
104303 vs 1

绕过视图并直接在主表上运行查询消除了缓慢.那么我需要做些什么才能加快速度呢？视图基本上是这样的：

SELECT x, y, z, verified FROM table1 LEFT JOIN table2 on tab2_ID = table2.ID LEFT JOIN table3 on tab3_ID = table3.ID

解决了：
弗兰基带领我走向正确的方向.第二个连接表(公司表)通过公司的全文名称加入.我最近才决定在该表中添加一个整数键.名称列应该被编入索引,但我可能会拙劣.无论如何,我重新组织了一切.我在主表中转换了外键以匹配公司表的整数ID,而不是完整的公司名称.我重新索引每个表中的列,然后我更新了视图以反映新的连接点.现在它可以在两个方向上立即运行. :)所以我猜整数键是关键.问题已经消失,但我仍然不觉得我原来的问题真的得到了解决.

谢谢你的帮助.

解决方法:

请运行以下查询并发布结果.

EXPLAIN SELECT count(*) c 
FROM full_view 
WHERE verified > ( DATE (NOW()) - INTERVAL 30 DAY)

长期被遗忘的EXPLAIN几乎总会带来一些东西！

标签：comparison-operators,performance,mysql,count
来源： https://codeday.me/bug/20190827/1739568.html