mysql 카운트 쿼리가 매우 느린 경우 어떻게 해야 합니까? mysql 쿼리 속도 최적화 솔루션

MySQL 쿼리 속도가 너무 느려서 매우 귀찮은 일입니다. 따라서 저자는 mysql 쿼리 속도에 대한 최적화 계획을 정리하는 데 시간을 투자했습니다. 이 기사는 모두 저자의 개인적인 의견입니다. 질문이나 실수가 있으면 언제든지 소통하고 수정해 주세요. 함께 배우고 발전해 나가세요.

대형 테이블을 위한 MySQL count() 최적화

권장되는 관련 mysql 비디오 자습서: "mysql tutorial"

이 문서를 작성하는 것은 모든 사람이 의심을 없애고 주제로 돌아갈 수 있도록 돕기 위한 것입니다. B+ 트리와 결합한 데이터 실험 결과 추측을 기반으로 한 구조 및 판단

오늘은 MySQL의 count() 연산 최적화를 실험했습니다. 다음 설명은 mysql5.7 InnoDB 스토리지 엔진을 기반으로 합니다.

생성된 테이블의 구조는 다음과 같습니다(데이터 양은 100만 개).

먼저 mysql의 count(*), count(PK), count(1) 중 어느 것이 맞는지에 대한 질문입니다. )가 더 빠릅니다.
구현 결과는 다음과 같습니다.



차이가 없습니다! WHERE 절을 추가한 후 세 쿼리에 동일한 시간이 걸리므로 사진을 게시하지 않겠습니다.

회사에 있을 때 SQL 문 select count(*) from table을 작성했는데, 데이터가 많을 때 속도가 너무 느렸습니다. 그렇다면 최적화하는 방법은 무엇입니까? select count(*) from table的SQL语句，在数据多的时候非常慢。所以要怎么优化呢？

这要从InnoDB的索引说起, InnoDB的索引是B+Tree。

对主键索引来说：它只有在叶子节点上存储数据，它的key是主键，并且value为整条数据。 
对辅助索引来说：key为建索引的列，value为主键。

这给我们两个信息： 
1. 根据主键会查到整条数据 
2. 根据辅助索引只能查到主键，然后必须通过主键再查到剩余信息。

所以如果要优化count(*)操作的话，我们需要找一个短小的列，为它建立辅助索引。 
在我的例子中就是status，虽然它的”severelity”几乎为0.

先建立索引：ALTER TABLE test1 ADD INDEX (status); 
然后查询，如下图： 
 
可以看到，查询时间从3.35s下降到了0.26s，查询速度提升近13倍。

如果索引是str这一列，结果又会是怎么样呢？ 
先建立索引: alter table test1 add index (str) 
结果如下： 

可以看到，时间为0.422s，也很快，但是比起status这列还是有着1.5倍左右的差距。

再大胆一点做个实验，我把status这列的索引删掉，建立一个status和left(omdb,200)(这一列平均1000个字符)的联合索引，然后看查询时间。 
建立索引： alter table test1 add index (status,omdb(200)) 
结果如下： 
 
时间为1.172s 
alter table test1 add index (status

InnoDB의 인덱스로 시작됩니다. InnoDB의 인덱스는 B+Tree입니다.

기본 키 인덱스의 경우 리프 노드에만 데이터를 저장하며 키는 기본 키이고 값은 전체 데이터 조각입니다.
보조 인덱스의 경우: 키는 인덱스할 열이고 값은 기본 키입니다.
이것은 두 가지 정보를 제공합니다.

1. 기본 키를 기반으로 전체 데이터를 찾습니다.

2. 보조 인덱스를 기반으로 기본 키만 찾을 수 있으며 나머지 정보는 다음을 통해 찾아야 합니다. 기본 키.
따라서 count(*) 연산을 최적화하려면 짧은 열을 찾아 이에 대한 보조 색인을 생성해야 합니다.

제 경우에는 상태이지만 "심각도"는 거의 0입니다.

먼저 인덱스를 생성하세요: ALTER TABLE test1 ADD INDEX (status) ;

그런 다음 아래와 같이 쿼리합니다.

쿼리 시간이 3.35초에서 0.26초로 줄어들고, 쿼리 속도가 거의 13배 증가한 것을 확인할 수 있습니다.

인덱스가 str 열인 경우 결과는 어떻게 되나요? 먼저 인덱스 생성: alter table test1 add index (str) 결과는 다음과 같습니다:

시간도 0.422초로 매우 빠른 것을 알 수 있지만 와 비교하면 status 열은 아직 1.5배 정도의 차이가 있습니다.

좀 더 과감하게 실험해 보기 위해 status 열의 인덱스를 삭제하고 status 및 left(omdb,200)를 만들었습니다. > (이 열의 평균 길이는 1000자입니다.) 조인트 인덱스를 확인한 다음 쿼리 시간을 살펴봅니다.

색인 생성: alter table test1 add index (status,omdb(200))

결과는 다음과 같습니다. 🎜 🎜시간은 1.172초 🎜alter table test1 index 추가(status code>,imdbid);🎜🎜보충! ! 🎜인덱스 실패에 주의하세요! 🎜인덱스 설정 후의 정상적인 모습: 🎜🎜key_len이 6이고, Extra 설명에서 index를 사용하고 있는 것을 볼 수 있습니다.🎜🎜그리고 인덱스가 실패하는 경우: 🎜🎜🎜🎜다음과 같이 인덱스가 실패하는 상황이 많이 있습니다. 함수 사용,! = 연산 등 자세한 내용은 공식 문서를 참조하세요. 🎜🎜MySQL에 대한 심층적인 연구는 없습니다. 위 내용은 B+ 트리의 데이터 구조를 기반으로 한 저의 판단과 실험 결과에 대한 추측에 따른 것입니다. 부족한 점이 있으면 정정해 주시기 바랍니다. 🎜🎜관련 기사: 🎜🎜🎜Sql server2005 쿼리 속도를 최적화하는 50가지 방법 요약🎜🎜🎜🎜쿼리 속도 향상: SQL Server 데이터베이스 최적화 계획🎜🎜🎜 🎜

위 내용은 mysql 카운트 쿼리가 매우 느린 경우 어떻게 해야 합니까? mysql 쿼리 속도 최적화 솔루션의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!