慢sql一些个人看法

慢sql对一个系统的危害非常大
某些场景需要特别注意：如大屏等的接口，这些接口前端轮询，请求频率高，如果有慢sql严重的话会拖垮整个数据库

慢sql治理
抓取慢sql工具 druid

慢sql治理
explain看执行脚本
注意explain看到的直接计划并不代表永远都会这样，执行计划有时候会与入参有关

在MySQL中，最后使用哪个索引是由优化器（Optimizer）决定的。优化器负责评估可用的索引，并根据查询的特性和数据库的统计信息选择最优的索引来执行查询。

优化器会考虑多个因素来选择索引，包括但不限于以下方面：

索引的选择性：选择具有更高选择性的索引可以提供更好的查询性能。
查询条件：优化器会考虑查询条件中的列是否有索引，以及索引的类型和列的分布。
数据量：优化器会根据表中的数据量来评估使用不同索引的代价和收益。
查询类型：对于不同的查询类型（如SELECT、UPDATE、DELETE等），优化器可能会选择不同的索引。
统计信息：优化器会根据数据库中的统计信息（如表大小、行数、分布等）来评估索引的效果。
在执行查询之前，优化器会生成多个执行计划，并评估每个计划的成本，然后选择成本最低的计划来执行查询。因此，最后使用的索引是由优化器的决策结果决定的。

需要注意的是，优化器并不总是做出最佳的决策。有时候，优化器可能会选择不正确的索引或者没有使用索引，这可能导致查询性能低下。在这种情况下，可以通过分析查询执行计划（EXPLAIN）、调整索引策略或者提供提示（HINT）来优化查询的性能。

当表的大小达到了2kw，无论如何优化查询都会很慢，这个时候需要考虑归档，表拆分
归档意思：生产往往没有物理删除的权限，逻辑删除掉的数据还保留在表中就会是一种负担，这个时候就需要归档（将逻辑删除掉的数据物理删除）

拆表：看数据的用途，如果一个表的数据只有前面几个月的数据是用户比较关心的，实际使用场景比较多的，可以考虑冷热数据分离的手段，将前三个月的数据备份一份到一个新的（热数据）表，这样将大部分的查询都导向热数据小表，从而减轻数据库的压力

常见的拆表框架

sharding-jdbc