收到疯狂慢查询和请求超时报警、MySQL请求通过度量分析异常，和CLI ->显示proceslist看到很多慢查询。此前，SQL是不是，这是问题，因为数据量的增加，虽然饲料表大一亿，饲料流信息已近热的特点，所以它不是因为受innodb_buffer_pool_size.the原因效率低引起的IO效率低，后来进一步解释执行计划的分析，和MySQL查询优化器选择的指标，他认为是有效的。
MySQL查询优化器在大多数情况下是可靠的，但是您的SQL语言应该注意多个索引。最后的结果有点犹豫。因为MySQL只能使用同一SQL的一个索引，您选择哪一个当数据量很小时，MySQL优化器将发布主要索引索引，并使用索引和唯一的索引。当您达到数据级别时，由于查询操作有一个内插，MySQL查询优化器可能会选择主关键字！
总之，MySQL查询优化基于检索成本考虑，而不是基于时间成本考虑。优化器根据现有的数据状态计算成本，而不是SQL的实际执行。
因此，MySQL优化器每次都不能达到最佳效果，无法准确预测成本。如果我们想准确地获得每个指数的成本，我们必须知道它，所以成本分析只是一个预测。因为据估计，有一个错误的判断。
我们所说的表是提要信息流表，我们知道提要信息流表访问不仅是频繁的，而且是大量的数据，但是这个表的数据结构很简单，索引也很简单。一共有两个索引，一个是主键索引，另一个是唯一唯一索引索引。
如下所示，该表必须订购十亿级，因为有足够的缓存向前，而且出于同样的原因，所以不要来拆分表。
问题是，当数据级别小于一亿时，MySQL优化器选择使用索引索引。当数据级别超过一亿时，MySQL查询优化器选择使用主键索引。问题是查询速度太慢。
这是正常情况下。
MySQL >解释`饲料`哪里user_id *选择（116537309116709093116709377）和CID（100110051054109210931095）和ID号128384713限0, 11 G ID顺序；
*************************** 1。行***************************
编号：1
select_type：简单
表：饲料
分区：空
范围类型：
possible_keys：小学、feed_user_target
关键词：feed_user_target
key_len：6
参考：空
行数：18
过滤：50
额外的：使用；使用索引；使用filesort
1排，1警告（0秒）
相同的SQL语句在数据量大变化后，由MySQL查询优化器更改索引的选择。
MySQL >解释`饲料`哪里user_id *选择（116537309116709093116709377）和CID（100110051054109210931095）和ID号128384713限0, 11 G ID顺序；
*************************** 1。行***************************
编号：1
select_type：简单
表：饲料
类型：范围
possible_keys：小学、feed_user_target
关键词：小学
key_len：4
参考：空
行数：11873197
附加：使用在哪里
1行集（0秒）
然后，解决方案是使用强制索引强制查询优化器使用我们给出的索引。
解释选择*从`饲料`力指数（feed_user_target）在哪里user_id（116537309116709093116709377）…
因此，我们应该做些什么来防止这个问题，因为MySQL优化器选择了一个低效率的索引，因为数据增强了
针对这一问题，本文对多家工厂的DBA进行了协商，结果与我们的一致，只在后期查询时发现问题，然后在SQL语句中指定强制索引来解决索引问题，而且在系统的早期阶段，我们将避免此类问题。然而，业务开发人员经常与DBA的评审工作进行合作。但在后期，为了省事，自以为是还是觉得没问题，这就造成mysql查询意外。
我对MySQL优化器对索引规则的选择有一点了解，我将花时间好好研究规则。
