于是，第一个截图中的结果就转换为了如下的格式
这里刻意按照4个buckets生成的直方图，应该来说足够简单了，熟悉MSSQL直方图同学，应该一眼就可以看明白这个直方图的含义（测试数据量是400,000）
以第一个bucket为例：["2018-06-15 04:57:48.000000", "2018-07-02 15:13:04.000000", 0.25, 95311]
很明显，
1，"2018-06-15 04:57:48.000000"和"2018-07-02 15:13:04.000000"是类似于sqlserver中直方图中的下限值与上限值
2，0.25小于bucket的值的比例（也就小于这个区间上限制值的比例）
3，95311是这个区间的字段值不重复的行数。
到最后一个bucket，采样率必然是1，也就是100%
需要注意的是，直方图的更新时间是标准时间（UTC value），而不是服务器当前时间。
MySQL 8.0中的直方图基本上与sqlserver的直方图一致，都是基于单列的抽样预估，但是MySQL直方图中没有类似于sqlserver中的字段选择性，
不过这个字段选择性本身意义也不大 ，sqlserver中对于复合索引，两个字段合计在一块统计，除非两个字段的同时分布的都很均匀，否则多字段索引的字段选择性参考意义不大。
这也是复合索引无法做到较为精确预估的原因。
存在的疑问？
写过一点MySQL统计信息的，不过是在MySQL5.7下面，还没有直方图的概念https://www.linuxidc.com/Linux/2018-08/153704.htm
触发统计信息更新的变量还是set global innodb_stats_on_metadata = 1;但是经测试，统计信息的直方图并没有因此而更新。
innodb_stats_on_metadata在MySQL5.7中影响到的是MySQL的索引上的统计信息，而这里纯粹是统计信息的直方图（MySQL 8.0中直方图跟索引没有必然的关系）。
另外，这里经过反复测试发现，buckets的数据量，与生成直方图的效率并没有非常明显的关系，如下截图，也并不清楚，buckets数量跟取样百分比有什么关系。
又仔细看了一下参考链接的内容，发现这么一段话：
Maintaining an index has a cost. If you have an index, every INSERT/UPDATE/DELETE causes the index to be updated. This is not free, and will have an impact on your performance. A histogram on the other hand is created once and never updated unless you explicitly ask for it. It will thus not hurt your INSERT/UPDATE/DELETE-performance.
它本身是说明索引与直方图之间的关系的，提到直方图创建之后并不会自动更新，除非主动更新。
不得不吐槽的就是，如果我在某个字段上创建了一个索引，还需要顺便在创建一个统计信息直方图？并且这个直方图并不会随着数据的变化自动更新，还需要手动更新。
MySQL 8.0中会不会把统计信息和索引关联起来，或者根据需要自动创建统计信息，如果统计信息做不到自动更新，基本上可以认为是残废的统计信息了。
关于生成直方图中时的资源的消耗