mysql查询优化

 最近出现一个问题，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)更加的节省空间，但是由于该时间字段还是查询条件必须的字段，我们在优化时直接将该字段的

字段类型改成了datetime(3),并将该字段设置成索引字段，发现查询速度有了很大的提升。