SELECT *가 SELECT foo보다 크기가 빠른 이유는 무엇입니까?

다음과 같이 값과 해시 테이블을 고려하십시오.

+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| id         | int(11)  | NO   | PRI | NULL    | auto_increment |
| val        | char(9)  | NO   |     | NULL    |                |
| val_hashed | char(50) | YES  |     | NULL    |                |
+------------+----------+------+-----+---------+----------------+

다음 쿼리는 0.00 초 후에 완료됩니다.

SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;

그러나이 쿼리는 3 분 17 초가 걸립니다.

SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;

쿼리가 실행되는 동안 프로세스 목록에 상태가 표시 Sorting result됩니다. 상황은 완전히 재현 가능합니다. INSERT테이블에서 작업을 지속적으로 수행하는 다른 프로세스가 있습니다.

더 구체적인 쿼리가 *쿼리 보다 실행하는 데 더 오래 걸리는 이유는 무엇 입니까? 나는 항상 *성능상의 이유로 쿼리를 피해야 한다고 믿었습니다 .

문구 ORDER BY 1는 다른 열을 나타냅니다. 첫 번째 id는 두 번째 val입니다. id열쇠 이기 때문에 색인이 생성되고 order by사소한 일이 될 것입니다. 하는 방법은 order by val, 그러나, 시스템은 모든 행, 정렬 전체 테이블을 검색해야합니다 val다음 해당 행 하나를 선택합니다.

두 쿼리를 모두 변경하면 order by id실행 시간이 거의 동일하다고 생각합니다.

쿼리의 성능 차이는 MG에 의해 잘 설명되어 있습니다. 이 문제를 해결하려고합니다.

나는 항상 성능상의 이유로 쿼리를 피해야한다고 항상 믿었다.

select *그 자체로는 특별한 처벌이 없으며 잘못 사용하면 문제가됩니다. 단일 테이블 쿼리에서는 잘 작동합니다. 이제 해당 테이블을 20 개의 열이있는 다른 테이블에 조인하고 나중에 여러 개의 열이있는 5 개의 다른 테이블에 조인을 추가합니다. 이제 문제입니다. 따라서 광범위한 반창고를 가르치는 사람들은 이유를 설명하지 않고 "X를 절대하지 마십시오".