慢sql一些个人看法

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

慢sql治理
抓取慢sql工具 druid

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

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

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

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

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

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

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

常见的拆表框架

sharding-jdbc

你可能感兴趣的:(sql,数据库)