最近出现一个问题，mysql历史月表的数据达到2000万左右的时候大概是16G，我们的历史月表有20多个字段。查询速度，非常的慢。
为此，我们花费了一周的时间解决这个查询性能的问题。
首先，我们把当前表的建表语句show了一下，发现字段默认的排序规则是：COLLATE=utf8mb4_0900_ai_ci，而开发建议书建议我们使用的字段编码和字段排序规则是：CHARSET=utf8mb4 COLLATE=utf8mb4_bin；
utf8mb4_0900_ai_ci的排序规则：
utf8mb4_0900_ai_ci是mysql针对utf8mb4编码的排序规则。0900代表Unicode9.0的规范，ai表示accent insensitivity，也就是“不区分音调”，而ci表示case insensitivity,也就是“不区分大小写”。
在比较字符时，utf8mb4_0900_ai_ci不仅会忽略大小写和重音符号，而且还能识别不同的Unicode字符。因此，它能更准确地比较字符，避免了诸如在utf8mb4_general_ci排序规则下的问题。
然而，utf8mb4_0900_ai_ci的缺点是在某些情况下比utf8mb4_general_ci慢。所以，在实际情况中，可以根据应用程序的需求来选择适合的排序规则。
utf8mb4_bin的排序规则：
utf8mb4_bin的排序规则是二进制，他对字符串的每个字符都使用二进制数据进行编译和存储，且区分大小写。
这里我们按照开发建议书所有字段采用了utf8mb4_bin的排序规则。
其次，明细月表中的时间字段样式为“2023-09-27 17:33:25.123” 样式，且时间字段采用的是varchar(40),这种设计方式，不如直接把字段类型改成char(23)更加的节省查询性能，因为在mysql中，char和varchar是两种常见
的字符串数据类型。它们的主要区别在于存储方式和性能。
1.存储方式：
char:是固定长度的，指定了字段的长度后，不管实际存储的数据长度是多少，都会占用指定的空间。如果数据长度小于指定的长度，mysql会用空格来填充。
varchar：是可变长度的，只会占用实际数据长度加上1或2个字节（用于存储长度信息）。
2.查询性能：
char:由于char