Python性能提升神器！lru_cache的介绍和讲解

Posted 2023-05-10

参考技术A

我们经常谈论的缓存一词，更多的类似于将硬盘中的数据存放到内存中以至于提高读取速度，比如常说的redis，就经常用来做数据的缓存。 Python的缓存（lru_cache）是一种装饰在被执行的函数上，将其执行的结果缓存起来，当下次请求的时候，如果请求该函数的传参未变则直接返回缓存起来的结果而不再执行函数的一种缓存装饰器。

那它和redis的区别在哪？有什么优势？怎么使用？ 下面为你讲解

1.现在我们先不使用缓存来写一个求两数之和的函数，并调用执行它两次：

执行结果

可以看到 test 被执行了两次，现在我们加上缓存再进行执行：

执行结果

可以看到 test 函数只被执行了一次，第二次的调用直接输出了结果，使用了缓存起来的值。

2.当我们使用递归求斐波拉契数列 （斐波那契数列指的是这样一个数列：0,1,1,2,3,5,8，它从第3项开始，每一项都等于前两项之和） 的时候，缓存对性能的提升就尤其明显了：

不使用缓存求第40项的斐波拉契数列

执行时间

使用缓存求第40项的斐波拉契数列：

执行时间

两个差距是非常明显的，因为不使用缓存时，相当于要重复执行了很多的函数，而使用了 lru_cache 则把之前执行的函数结果已经缓存了起来，就不需要再次执行了。

查看lru_cache源码会发现它可以传递两个参数： maxsize 、 typed ：

代表被lru_cache装饰的方法最大可缓存的结果数量 （被装饰方法传参不同一样，则结果不一样；如果传参一样则为同一个结果） ， 如果不指定传参则默认值为128，表示最多缓存128个返回结果，当达到了128个时，有新的结果要保存时，则会删除最旧的那个结果。如果maxsize传入为None则表示可以缓存无限个结果；

默认为false，代表不区分数据类型，如果设置为True，则会区分传参类型进行缓存，官方是这样描述的:

但在python3.9.8版本下进行测试，typed为false时，按照官方的测试方法测试得到的还是会被当成不同的结果处理，这个时候typed为false还是为true都会区别缓存，这与官方文档的描述存在差异：

执行结果

但如果是多参数的情况下，则会被当成一个结果：

执行结果

这个时候设置typed为true时，则会区别缓存：

执行结果

当传参个数大于1时，才符合官方的说法，不清楚是不是官方举例有误

当传递的参数是dict、list等的可变参数时，lru_cache是不支持的，会报错：

报错结果

缓存 缓存位置 是否支持可变参数 是否支持分布式 是否支持过期时间设置 支持的数据结构 需单独安装 redis 缓存在redis管理的内存中 是 是 是 支持5种数据结构 是 lru_cache 缓存在应用进程的内存中，应用被关闭则被清空 否 否 否 字典（参数为：key，结果为：value） 否

经过上面的分析，lru_cache 功能相对于redis来说要简单许多，但使用起来更加方便，适用于小型的单体应用。如果涉及的缓存的数据种类比较多并且想更好的管理缓存、或者需要缓存数据有过期时间（类似登录验证的token）等，使用redis是优于lru_cache的。

性能提升神器Covering Indexes

可能有小伙伴会问，Covering Indexes到底是什么神器呢？它又是如何来提升性能的呢？接下来我会用最通俗易懂的语言来进行介绍，毕竟不是每个程序猿都要像DBA那样深刻理解数据库，知道如何用以及如何用好神器才是最关键的。

Covering Indexes就是一个索引覆盖所有要查询的字段（ps：这句话我挖个坑，文末我来解释）。

An index that contains all required information to resolve the query is known as a “Covering Index” – it completely covers the query.
Covering Index includes all the columns, the query refers to in the SELECT, JOIN, and WHERE clauses.

 接下来我们通过一个非常简单的sql来进行分析：

SELECT column1, column2 FROM tablename WHERE column3=xxx;

你能想象将sql的执行时间从1.8秒，降到1.2秒，继续压榨到0.5，0.2.....，酣畅淋漓，怎一个爽字了得。就跟排兵布阵一样，打胜仗固然重要，但得想出成本最低效果最好的阵法，定会收获满满的成就感。

这条sql要如何来进行优化呢？第一反应可能就是说给“column3”加索引（普通索引或唯一索引）啊，没错，这样确实能在很大程度上提升这条sql的性能。

我们来分析下上面sql的执行计划：因为给“column3”建了索引，就会快速根据这个索引查询到符合条件的结果；然后再去这些符合条件的结果里查找所需的column1、column2字段；请注意，整个过程出现了两次查询，一次是查询索引，另一次查询结果的所需字段。

那能不能将上面说的执行计划再优化一下呢？大杀器Covering Indexes就是用来干这事的。给column3、column1、column2建个复合索引，如下：

alter table table_name add index index_column3 (column3，column1，column2) ;

这样就可以直接通过索引就能查询出符合条件的数据，而不必像上面那样先去查索引，然后再去查数据的两个过程。

光说不练那是假把式！小伙伴们可以用explain去试试上面的两种情况，如果执行复合索引后的情况，你会发现Extra里出现Using index。

刚开始我说挖了个坑，现在我把坑填上。既然神器Covering Indexes这么好用，以后select语句的我都不管三七二十一的都亮出神器。难不成你select *也要亮神器？一个表那么多字段，全建成索引？那索引文件会不堪重负的，这就会适得其反，带来一系列恶果的。索引文件过大会造成insert、update非常慢，你select倒是爽快了，不能不顾其他兄弟吧，不仗义的事咱不能干，切记！

如果看完这个分析还不过瘾，下面我给几篇参考文章：

https://www.c-sharpcorner.com/UploadFile/b075e6/improving-sql-performance-using-covering-indexes/

https://www.red-gate.com/simple-talk/sql/learn-sql-server/using-covering-indexes-to-improve-query-performance/

https://stackoverflow.com/questions/609343/what-are-covering-indexes-and-covered-queries-in-sql-server

https://stackoverflow.com/questions/62137/what-is-a-covered-index