Tôi có một bảng kho trông như thế này:thêm cột di tích MySQL hiệu suất
CREATE TABLE Warehouse (
id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
eventId BIGINT(20) UNSIGNED NOT NULL,
groupId BIGINT(20) NOT NULL,
activityId BIGINT(20) UNSIGNED NOT NULL,
... many more ids,
"txtProperty1" VARCHAR(255),
"txtProperty2" VARCHAR(255),
"txtProperty3" VARCHAR(255),
"txtProperty4" VARCHAR(255),
"txtProperty5" VARCHAR(255),
... many more of these
PRIMARY KEY ("id")
KEY "WInvestmentDetail_idx01" ("groupId"),
... several more indices
) ENGINE=INNODB;
Bây giờ, các truy vấn sau đây dành khoảng 0.8s trong truy vấn thời gian và 0.2s trong lấy thời gian, đối với một tổng cộng khoảng một giây. Truy vấn trả về ~ 67.000 hàng.
SELECT eventId
FROM Warehouse
WHERE accountId IN (10, 8, 13, 9, 7, 6, 12, 11)
AND scenarioId IS NULL
AND insertDate BETWEEN DATE '2002-01-01' AND DATE '2011-12-31'
ORDER BY insertDate;
Việc thêm nhiều id vào mệnh đề chọn không thực sự thay đổi hiệu suất.
SELECT eventId, groupId, activityId, insertDate
FROM Warehouse
WHERE accountId IN (10, 8, 13, 9, 7, 6, 12, 11)
AND scenarioId IS NULL
AND insertDate BETWEEN DATE '2002-01-01' AND DATE '2011-12-31'
ORDER BY insertDate;
Tuy nhiên, thêm cột "thuộc tính" sẽ thay đổi thành 0,6 giây tìm nạp và thời gian truy vấn 1,8 giây.
SELECT eventId, txtProperty1
FROM Warehouse
WHERE accountId IN (10, 8, 13, 9, 7, 6, 12, 11)
AND scenarioId IS NULL
AND insertDate BETWEEN DATE '2002-01-01' AND DATE '2011-12-31'
ORDER BY insertDate;
Bây giờ để thực sự thổi tất ngắn của bạn. Thay vì txtProperty1, sử dụng txtProperty2 thay đổi số lần tìm nạp 0,8, truy vấn 24 giây!
SELECT eventId, txtProperty2
FROM Warehouse
WHERE accountId IN (10, 8, 13, 9, 7, 6, 12, 11)
AND scenarioId IS NULL
AND insertDate BETWEEN DATE '2002-01-01' AND DATE '2011-12-31'
ORDER BY insertDate;
Hai cột này giống hệt nhau về loại dữ liệu mà chúng giữ: hầu như không rỗng và không được lập chỉ mục (không phải là tạo nên sự khác biệt). Để chắc chắn bản thân bảng là lành mạnh, tôi đã chạy phân tích/tối ưu hóa nó.
Điều này thực sự gây khó chịu cho tôi. Tôi có thể thấy lý do tại sao việc thêm các cột vào mệnh đề select chỉ có thể tăng thời gian tìm nạp, nhưng nó không nên thay đổi thời gian truy vấn, đặc biệt là không đáng kể. Tôi sẽ đánh giá cao bất kỳ ý tưởng nào về những gì đang gây ra sự chậm lại này.
CHỈNH SỬA - Các điểm dữ liệu khác
SELECT * thực sự vượt trội hơn txtProperty2 - 0.8 truy vấn, 8.4s tìm nạp. Quá tệ Tôi không thể sử dụng vì thời gian tìm nạp (dự kiến) quá dài.
Thời gian này có thể lặp lại như thế nào? –
và không được lập chỉ mục (không phải là tạo nên sự khác biệt) .... nó có thể (http://en.wikipedia.org/wiki/Index_%28database%29#Covering_Index) –
@Rowland - Có, tôi có lặp lại timings trên hai máy tính xách tay dev và một máy chủ QA. Rõ ràng, máy chủ là nhanh hơn, nhưng mô hình vẫn còn. –