大致上大部分的数据库都有统计分析，主要的作用就是在语句执行的情况下，能尽量的选择相对正确的方式来走执行计划，越准确的统计分析，可以带来更好的执行计划和数据库的语句执行性能，但相对来说越准确的统计分析，也会带来系统在统计时的性能消耗，越大的数据库系统，对统计分析的需求和要求也就越高。

从MYSQL 5.6 开始，统计分析的信息会固化在系统的存储中，通过下面的语句可以查看我们相隔的开关是否打开。

而在进行统计分析中都有一个采样率的概念，也就是根据估计索引列的基数和其他的统计信息要抽样的索引页的数量。其实这样算看似合理，但实际上如果挑选的索引页不具有代表性，这样的算法还可能会错误引导数据库的基本的统计分析的信息。这也就是为什么有时候明明建立了索引，却不走，在手动触发统计分析后，执行的结果有变化了的原因。默认抽样的页数是8 pages，我们可以改动默认抽样的页数，来达到提高准确率的功效。但同样付出的代价就是，在抽样时的消耗的I/O 和相关资源。

我们是可以定期对一些大表进行 analyze table 的，可以写一个定期的运行的脚本来完成此事，尽量达到统计分析的准确性。但通常一般都是通过自动触发的方式来完成这样的工作。

而我们可以进行一个测试，关于MYSQL的索引和真是的表信息之间是否有差距。

1 我们将需要检验的字段进行distinct 并且 count 返回的数据和我们建立索引的数据进行比对，看看是否有问题，对比两张图中的数据，可以清晰的发现，索引中的Cardinality 和实际中的字段的数据比较，是不一样的。

其实我们已经操作了analyze table 但是我们依然没有得到准确的数字，在平时这可能不会有什么问题，但如果是较大的表例如上千万的表，如果这方面错的比较错，会对执行计划产生问题，这时候可能就需要我们通过手动的方式来更新某些表的记录。

update mysql.innodb_table_stats set n_rows = 300024 where database_name = 'employees' and table_name = 'employees';

同理也可以更新 innodb_index_stats表里面的数据

以上方法仅仅使用于统计分析的不准确严重影响到了执行计划，一般我们还是不要动系统中的统计分析表，另外这样做的另一个问题就是， 你的表不会频繁更新的操作，并且你要找好自己更新数值的时间点。