优化临时表使用,SQL语句性能提升100倍
【问题现象】 线上mysql数据库爆出一个慢查询,DBA观察发现, 查询时服务器IO飙升,IO占用率达到100%, 执行时间长达7s左右 。 SQL语句如下: SELECT DISTINCT g.*, cp.name AS cp_name, c.name AS category_name, t.name AS type_name FROM gm_game g LEFT
【问题现象】
线上mysql数据库爆出一个慢查询,DBA观察发现,查询时服务器IO飙升,IO占用率达到100%, 执行时间长达7s左右。
SQL语句如下:
SELECT DISTINCT g.*, cp.name AS cp_name, c.name AS category_name, t.name AS type_name FROM gm_game
g LEFT JOIN gm_cp
cp ON cp.id = g.cp_id AND cp.deleted = 0 LEFT JOIN gm_category
c ON c.id = g.category_id AND c.deleted = 0 LEFT JOIN gm_type
t ON t.id = g.type_id AND t.deleted = 0 WHERE g.deleted = 0 ORDER BY g.modify_time DESC LIMIT 20 ;
【问题分析】
使用explain查看执行计划,结果如下:
这条sql语句的问题其实还是比较明显的:
查询了大量数据(包括数据条数、以及g.* ),然后使用临时表order by,但最终又只返回了20条数据。
DBA观察到的IO高,是因为sql语句生成了一个巨大的临时表,内存放不下,于是全部拷贝到磁盘,导致IO飙升。
【优化方案】
优化的总体思路是拆分sql,将排序操作和查询所有信息的操作分开。
第一条语句:查询符合条件的数据,只需要查询g.id即可
SELECT DISTINCT g.id FROM gm_game
g LEFT JOIN gm_cp
cp ON cp.id = g.cp_id AND cp.deleted = 0 LEFT JOIN gm_category
c ON c.id = g.category_id AND c.deleted = 0 LEFT JOIN gm_type
t ON t.id = g.type_id AND t.deleted = 0 WHERE g.deleted = 0 ORDER BY g.modify_time DESC LIMIT 20 ;
第二条语句:查询符合条件的详细数据,将第一条sql的结果使用in操作拼接到第二条的sql
SELECT DISTINCT g.*, cp.name AS cp_name,c.name AS category_name,t.name AS type_name FROM gm_game
g LEFT JOIN gm_cp
cp ON cp.id = g.cp_id AND cp.deleted = 0 LEFT JOIN gm_category
c ON c.id = g.category_id AND c.deleted = 0 LEFT JOIN gm_type
t ON t.id = g.type_id AND t.deleted = 0 WHERE g.deleted = 0 and g.id in(…………………) ORDER BY g.modify_time DESC ;
【实测效果】
在SATA机器上测试,优化前大约需要50s,优化后第一条0.3s,第二条0.1s,优化后执行速度是原来的100倍以上,IO从100%降到不到1%
在SSD机器上测试,优化前大约需要7s,优化后第一条0.3s,第二条0.1s,优化后执行速度是原来的10倍以上,IO从100%降到不到1%
可以看出,优化前磁盘io是性能瓶颈,SSD的速度要比SATA明显要快,优化后磁盘不再是瓶颈,SSD和SATA性能没有差别。
【理论分析】
MySQL在执行SQL查询时可能会用到临时表,一般情况下,用到临时表就意味着性能较低。
- 临时表存储
MySQL临时表分为“内存临时表”和“磁盘临时表”,其中内存临时表使用MySQL的MEMORY存储引擎,磁盘临时表使用MySQL的MyISAM存储引擎;
一般情况下,MySQL会先创建内存临时表,但内存临时表超过配置指定的值后,MySQL会将内存临时表导出到磁盘临时表;
Linux平台上缺省是/tmp目录,/tmp目录小的系统要注意啦。
- 使用临时表的场景
1)ORDER BY子句和GROUP BY子句不同, 例如:ORDERY BY price GROUP BY name;
2)在JOIN查询中,ORDER BY或者GROUP BY使用了不是第一个表的列 例如:SELECT * from TableA, TableB ORDER BY TableA.price GROUP by TableB.name
3)ORDER BY中使用了DISTINCT关键字 ORDERY BY DISTINCT(price)
4)SELECT语句中指定了SQL_SMALL_RESULT关键字 SQL_SMALL_RESULT的意思就是告诉MySQL,结果会很小,请直接使用内存临时表,不需要使用索引排序 SQL_SMALL_RESULT必须和GROUP BY、DISTINCT或DISTINCTROW一起使用 一般情况下,我们没有必要使用这个选项,让MySQL服务器选择即可。
- 直接使用磁盘临时表的场景
1)表包含TEXT或者BLOB列;
2)GROUP BY 或者 DISTINCT 子句中包含长度大于512字节的列;
3)使用UNION或者UNION ALL时,SELECT子句中包含大于512字节的列;
- 临时表相关配置
tmp_table_size:指定系统创建的内存临时表最大大小; http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_tmp_table_size
max_heap_table_size: 指定用户创建的内存表的最大大小; http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_max_heap_table_size
注意:最终的系统创建的内存临时表大小是取上述两个配置值的最小值。
- 表的设计原则
使用临时表一般都意味着性能比较低,特别是使用磁盘临时表,性能更慢,因此我们在实际应用中应该尽量避免临时表的使用。 常见的避免临时表的方法有:
1)创建索引:在ORDER BY或者GROUP BY的列上创建索引;
2)分拆很长的列:一般情况下,TEXT、BLOB,大于512字节的字符串,基本上都是为了显示信息,而不会用于查询条件, 因此表设计的时候,应该将这些列独立到另外一张表。
- SQL优化
如果表的设计已经确定,修改比较困难,那么也可以通过优化SQL语句来减少临时表的大小,以提升SQL执行效率。
常见的优化SQL语句方法如下:
1)拆分SQL语句
临时表主要是用于排序和分组,很多业务都是要求排序后再取出详细的分页数据,这种情况下可以将排序和取出详细数据拆分成不同的SQL,以降低排序或分组时临时表的大小,提升排序和分组的效率,我们的案例就是采用这种方法。
2)优化业务,去掉排序分组等操作
有时候业务其实并不需要排序或分组,仅仅是为了好看或者阅读方便而进行了排序,例如数据导出、数据查询等操作,这种情况下去掉排序和分组对业务也没有多大影响。
- 如何判断使用了临时表?
使用explain查看执行计划,Extra列看到Using temporary就意味着使用了临时表。
详细信息请参考MySQL官方手册: http://dev.mysql.com/doc/refman/5.1/en/internal-temporary-tables.html
原文地址:优化临时表使用,SQL语句性能提升100倍, 感谢原作者分享。

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

다양한 Java 프레임워크의 성능 비교: REST API 요청 처리: Vert.x가 최고이며 요청 속도는 SpringBoot의 2배, Dropwizard의 3배입니다. 데이터베이스 쿼리: SpringBoot의 HibernateORM은 Vert.x 및 Dropwizard의 ORM보다 우수합니다. 캐싱 작업: Vert.x의 Hazelcast 클라이언트는 SpringBoot 및 Dropwizard의 캐싱 메커니즘보다 우수합니다. 적합한 프레임워크: 애플리케이션 요구 사항에 따라 선택하세요. Vert.x는 고성능 웹 서비스에 적합하고, SpringBoot는 데이터 집약적 애플리케이션에 적합하며, Dropwizard는 마이크로서비스 아키텍처에 적합합니다.

시간 복잡도는 입력 크기를 기준으로 알고리즘의 실행 시간을 측정합니다. C++ 프로그램의 시간 복잡성을 줄이는 팁에는 데이터 저장 및 관리를 최적화하기 위한 적절한 컨테이너(예: 벡터, 목록) 선택이 포함됩니다. Quick Sort와 같은 효율적인 알고리즘을 활용하여 계산 시간을 단축합니다. 여러 작업을 제거하여 이중 계산을 줄입니다. 불필요한 계산을 피하려면 조건부 분기를 사용하세요. 이진 검색과 같은 더 빠른 알고리즘을 사용하여 선형 검색을 최적화합니다.

C++ 다중 스레드 성능을 최적화하기 위한 효과적인 기술에는 리소스 경합을 피하기 위해 스레드 수를 제한하는 것이 포함됩니다. 경합을 줄이려면 가벼운 뮤텍스 잠금을 사용하세요. 잠금 범위를 최적화하고 대기 시간을 최소화합니다. 동시성을 향상하려면 잠금 없는 데이터 구조를 사용하세요. 바쁜 대기를 피하고 이벤트를 통해 스레드에 리소스 가용성을 알립니다.

BitgetLaunchpool은 모든 암호화폐 애호가를 위해 설계된 동적 플랫폼입니다. BitgetLaunchpool은 독특한 제품으로 돋보입니다. 여기에서 토큰을 스테이킹하여 에어드랍, 높은 보상, 초기 참가자에게만 제공되는 넉넉한 상금 풀 등 더 많은 보상을 잠금 해제할 수 있습니다. BitgetLaunchpool이란 무엇인가요? BitgetLaunchpool은 사용자 친화적인 이용 약관에 따라 토큰을 스테이킹하고 획득할 수 있는 암호화폐 플랫폼입니다. Launchpool에 BGB 또는 기타 토큰을 투자함으로써 사용자는 무료 에어드랍, 수익을 받고 넉넉한 보너스 풀에 참여할 수 있는 기회를 갖게 됩니다. 담보자산의 수입은 T+1시간 이내에 계산되며, 보상은 다음을 기준으로 합니다.

Go에서 난수를 생성하는 가장 좋은 방법은 애플리케이션에 필요한 보안 수준에 따라 다릅니다. 낮은 보안: 대부분의 애플리케이션에 적합한 의사 난수를 생성하려면 math/rand 패키지를 사용하십시오. 높은 보안성: crypto/rand 패키지를 사용하여 더 강력한 무작위성을 요구하는 애플리케이션에 적합한 암호화된 보안 무작위 바이트를 생성합니다.

벤치마크에 따르면 소규모 고성능 애플리케이션의 경우 Quarkus(빠른 시작, 낮은 메모리) 또는 Micronaut(TechEmpower 우수)가 이상적인 선택입니다. SpringBoot는 대규모 풀 스택 애플리케이션에 적합하지만 시작 시간과 메모리 사용량이 약간 느립니다.

고성능 애플리케이션을 개발할 때 C++는 특히 마이크로 벤치마크에서 다른 언어보다 성능이 뛰어납니다. 매크로 벤치마크에서는 Java, C# 등 다른 언어의 편의성과 최적화 메커니즘이 더 나은 성능을 발휘할 수 있습니다. 실제 사례에서 C++는 이미지 처리, 수치 계산 및 게임 개발에서 우수한 성능을 발휘하며 메모리 관리 및 하드웨어 액세스에 대한 직접적인 제어는 확실한 성능 이점을 제공합니다.

최근 'Black Myth: 오공'은 각 플랫폼의 동시 접속자 수가 새로운 최고치를 기록하며 전 세계적으로 큰 주목을 받고 있습니다. 이 게임은 여러 플랫폼에서 큰 상업적 성공을 거두었습니다. 'Black Myth: Wukong'의 Xbox 버전 출시가 연기되었습니다. 'Black Myth: Wukong'은 PC와 PS5 플랫폼으로 출시되었지만 Xbox 버전에 대한 확실한 소식은 없습니다. 관계자는 '검은 신화:오공'이 엑스박스 플랫폼으로 출시될 것임을 확인한 것으로 알려졌다. 하지만 아직 구체적인 출시 날짜는 발표되지 않았습니다. 최근 Xbox 버전의 출시가 기술적인 문제로 인해 지연된 것으로 알려졌습니다. 관련 블로거에 따르면, 그는 Gamescom에서 개발자 및 "Xbox 내부자"와의 커뮤니케이션을 통해 "Black Myth: Wukong"의 Xbox 버전이 존재한다는 사실을 알게 되었습니다.
