django orm性能优化

参考：

django 分页查询大表，很慢

 面试小知识：MySQL索引相关

 MySQL 用 limit 为什么会影响性能？

前言

orm性能优化是一件很重要的事，一般万条以上的数据都需要优化处理了。

这次项目开发，接口测试的时候发现一个接口居然要数秒到一分钟，我都等的不耐烦了，客户用了肯定抓狂。于是开始思考怎么优化，这里记录一下。

优化方法

1、给字段加索引，查询速度从15秒减少到0.06秒。参考这篇文章django模型字段参数db_index添加索引

2、order_by()使用优化，对于数据量比较大的表，直接使用order_by()会很大程度降低性能。

order_by()排序优化

今天主要来看看order_by()优化

在我之前的代码中order_by()的对象是filter多个条件筛选过的少量数据，故表现不明显，在使用索引过后性能就很快。

看看下面这份代码，因为没有日期筛选所以数据量较大，仅仅对collect_date索引已经不能明显提高性能，实测循环一次大概1-2秒，HostUsageMonitor表数据量级是80w条

    for metric_name in data_source_const.METRIC_NEED_STAT:

        # 获取最新采集日期

        monitor_objs = (

            HostUsageMonitor.objects.filter(email=email, metric_name=metric_name).order_by("-collect_date")

        )

        if not monitor_objs.exists():

            resource_usage_data[metric_name] = 0

            continue

        latest_collect_date = monitor_objs[0].collect_date

        # 获取最新日期下的监控数据

        ...

这里讲一下优化的过程

先打断点看看monitor_objs.query或者修改配置让django打印sql（后者效果更好，配置参考django - 打印执行的sql）

1、直接用order_by()，2.321秒

HostUsageMonitor.objects.filter(email="110@qq.com", metric_name="mem_util").order_by("-collect_date")

latest_collect_date = monitor_objs[0].collect_date

(2.321) SELECT `data_sync_hostusagemonitor`.`id`, `data_sync_hostusagemonitor`.`server_id`, `data_sync_hostusagemonitor`.`metric_name`, `data_sync_hostusagemonitor`.`collect_date`, `data_sync_hostusagemonitor`.`average`, `data_sync_hostusagemonitor`.`unit`, `data_sync_hostusagemonitor`.`email`, `data_sync_hostusagemonitor`.`region_id`

FROM `data_sync_hostusagemonitor`

WHERE (`data_sync_hostusagemonitor`.`email` = '110@qq.com' AND `data_sync_hostusagemonitor`.`metric_name` = 'mem_util')

ORDER BY `data_sync_hostusagemonitor`.`collect_date` DESC  LIMIT 1;

args=('110@qq.com', 'mem_util')

2、用only()只加载collect_date，3.783秒

HostUsageMonitor.objects.filter(email="110@qq.com", metric_name="mem_util").only("collect_date").order_by("-collect_date")

latest_collect_date = monitor_objs[0].collect_date

(3.783) SELECT `data_sync_hostusagemonitor`.`id`, `data_sync_hostusagemonitor`.`collect_date`

FROM `data_sync_hostusagemonitor`

WHERE (`data_sync_hostusagemonitor`.`email` = '110@qq.com' AND `data_sync_hostusagemonitor`.`metric_name` = 'mem_util')

ORDER BY `data_sync_hostusagemonitor`.`collect_date` DESC  LIMIT 1;

args=('110@qq.com', 'mem_util')

3、用only()只加载id，根据查出的id列表做二次查询，0.009秒

monitor_objs_only_id = (

            HostUsageMonitor.objects.filter(email=email, metric_name=metric_name).only("id").order_by("-collect_date")

        )

monitor_objs = HostUsageMonitor.objects.filter(id__in=[monitor.id for monitor in monitor_objs_only_id])

latest_collect_date = monitor_objs[0].collect_date

(0.007) SELECT `data_sync_hostusagemonitor`.`id`

FROM `data_sync_hostusagemonitor`

WHERE (`data_sync_hostusagemonitor`.`email` = '110@qq.com' AND `data_sync_hostusagemonitor`.`metric_name` = 'mem_util')

ORDER BY `data_sync_hostusagemonitor`.`collect_date` DESC;

args=('110@qq.com', 'mem_util')

(0.002) SELECT `data_sync_hostusagemonitor`.`id`, `data_sync_hostusagemonitor`.`server_id`, `data_sync_hostusagemonitor`.`metric_name`, `data_sync_hostusagemonitor`.`collect_date`, `data_sync_hostusagemonitor`.`average`, `data_sync_hostusagemonitor`.`unit`, `data_sync_hostusagemonitor`.`email`, `data_sync_hostusagemonitor`.`region_id`

FROM `data_sync_hostusagemonitor`

WHERE `data_sync_hostusagemonitor`.`id` IN (10, 90, 170, 226, 282, 338, 490, 1002, 1082, 1138, 1194, 1250, 1306, 1362, 1586, 1642, 1842, 1970, 2026, 2082, 2138, 2194, 2250, 2306, 2362, 2418, 2498, 2554, 2610, 2666, 2722, 2778, 2834, 2890, 2970, 3314, 3370, 3426, 3482, 3538, 3594, 3746, 3826, 3882, 4124, 4204, 4284, 4359, 4401, 4492, 4565, 4614, 4734, 4776, 4818, 5129, 5401, 5457, 5535, 5597, 5653, 5709, 5765, 5821, 5877, 5933, 5989, 6045, 6101, 6181, 6237, 6293, 9, 89, 169, 225, 281, 337, 489, 1001, 1081, 1137, 1193, 1249, 1305, 1361, 1585, 1641, 1841, 1969, 2025, 2081, 2137, 2193, 2249, 2305, 2361, 2417, 2497, 2553, 2609, 2665, 2721, 2777, 2833, 2889, 2969, 3313, 3369, 3425, 3481, 3537, 3593, 3745, 3825, 3881, 4123, 4203, 4283, 4358, 4400, 4491, 4564, 4613, 4733, 4775, 4817, 5128, 5400, 5456, 5534, 5596, 5652, 5708, 5764, 5820, 5876, 5932, 5988, 6044, 6100, 6180, 6236, 6292)

LIMIT 1;

args=(10, 90, 170, 226, 282, 338, 490, 1002, 1082, 1138, 1194, 1250, 1306, 1362, 1586, 1642, 1842, 1970, 2026, 2082, 2138, 2194, 2250, 2306, 2362, 2418, 2498, 2554, 2610, 2666, 2722, 2778, 2834, 2890, 2970, 3314, 3370, 3426, 3482, 3538, 3594, 3746, 3826, 3882, 4124, 4204, 4284, 4359, 4401, 4492, 4565, 4614, 4734, 4776, 4818, 5129, 5401, 5457, 5535, 5597, 5653, 5709, 5765, 5821, 5877, 5933, 5989, 6045, 6101, 6181, 6237, 6293, 9, 89, 169, 225, 281, 337, 489, 1001, 1081, 1137, 1193, 1249, 1305, 1361, 1585, 1641, 1841, 1969, 2025, 2081, 2137, 2193, 2249, 2305, 2361, 2417, 2497, 2553, 2609, 2665, 2721, 2777, 2833, 2889, 2969, 3313, 3369, 3425, 3481, 3537, 3593, 3745, 3825, 3881, 4123, 4203, 4283, 4358, 4400, 4491, 4564, 4613, 4733, 4775, 4817, 5128, 5400, 5456, 5534, 5596, 5652, 5708, 5764, 5820, 5876, 5932, 5988, 6044, 6100, 6180, 6236, 6292)

观察以上3种orm执行的sql，发现关键在于limit 1，这个limit严重影响了我们的查询速度。

那么为什么limit减少了查询结果，反而加慢了查询效率呢？查阅mysql官方文档可知，在使用order的同时使用limit，会对所有数据进行扫描重排，所以效率很差。

在1和2中orm的order_by()生成的sql都带有limit 1，因为这个sql是在我们monitor_objs[0].collect_date调用查询结果时才组合并查询的。

在3中因为我们拆分成了2次查询。第一条sql的所有查询结果都会被第2条用到，所以不会有limit条件限制；但第2条查询结果我们也会调用monitor_objs[0]也会有个limit 1，这里不会降低查询效率的原因有2个：

order by和limit一起出现会对所有数据进行扫描重排，第2条查询没有order by，实测不会有扫描重排（1、2中sql去掉order_by查询效率明显提高）。
假如有重排，扫描重排的时候影响性能的主要原因还是非主键字段匹配（WHERE email = "xxx"）（实测用email和id匹配速度天差地别），这里第2条sql主要是主键id的匹配，而根据主键查询是非常快的。

所以在使用order_by()后又只调用结果集的一部分数据时，要特别注意性能问题。

巴特西

django orm性能优化

前言

优化方法

order_by()排序优化

最新文章

热门文章