Tại sao mysql xóa bộ đệm truy vấn trong phiên bản 8.0?

mysql query-cache mysql-8.0

— shaoyihe
nguồn

Đây là ưu tiên TỐT NHẤT mà mọi người có thể làm cho việc giảm chu kỳ CPU của máy chủ của bạn được sử dụng mỗi phút.

— Wilson Hauck

@WilsonHauck Đối với cơ sở dữ liệu nhỏ, có. Và thật tuyệt vời khi trả về mysql dễ dự đoán hơn trong cpu / thời gian cần thiết. Tuy nhiên, khi số đếm (*) trên một bảng lớn có thể mất 2-3 giờ để hoàn thành bộ đệm truy vấn có thể giảm thời gian đó xuống còn vài mili giây. Người đàn ông trong bộ đệm giữa không có gì thay thế, họ không biết liệu dữ liệu có thay đổi hay không. Cho rằng đó là một quyết định gần chết cho cơ sở dữ liệu khổng lồ.

— Giăng

@john Đăng kết quả văn bản của SHOW CREATE TABLE (yourtablename); và tôi sẽ đề xuất một cái gì đó sẽ tốt trong vòng 2-3 giờ để trả lại số hàng của bạn.

— Wilson Hauck

@WilsonHauck Tôi có hàng tá bảng như vậy trên nhiều máy chủ, hầu như không quan trọng bạn sử dụng cấu trúc nào. Dưới đây là một ví dụ pastebin.com/MHVACAny Điền vào đó với 1 tỷ hàng và thử đếm nhanh bằng cách sử dụng một chỉ mục mà không cần lưu trữ truy vấn. Với bộ nhớ đệm truy vấn, vấn đề là một phần nghìn giây mà không cần khoảng nửa giờ đến một giờ mỗi lần đếm. Bây giờ hãy cập nhật một trong các cột tại các vị trí ngẫu nhiên 1 tỷ lần với các giá trị khác nhau và bạn sẽ thấy chỉ số của nó giảm xuống còn 4-5 giờ (mất hiệu suất tuyến tính với các bản cập nhật). (phần thứ hai là một vấn đề khác biệt của innodb, không công bằng ở đây :)

— John

@John Kết quả và nnnn sec với truy vấn này là gì? CHỌN COUNT (scs_id) từ x_full; ?

— Wilson Hauck

Câu trả lời:

Có một blog chi tiết từ nhóm máy chủ MySQL về điều này, nơi Matt Lord nói:

Bộ đệm truy vấn đã bị tắt theo mặc định kể từ MySQL 5.6 (2013) vì được biết là không mở rộng quy mô với khối lượng công việc thông lượng cao trên các máy đa lõi.

Chúng tôi đã xem xét những cải tiến nào chúng tôi có thể thực hiện để truy vấn bộ đệm so với tối ưu hóa mà chúng tôi có thể thực hiện nhằm cải thiện tất cả các khối lượng công việc.

Trong khi những lựa chọn này là trực giao, tài nguyên kỹ thuật là hữu hạn. Điều đó có nghĩa là chúng tôi đang chuyển chiến lược để đầu tư vào các cải tiến thường áp dụng cho tất cả các khối lượng công việc.

— danblack
nguồn

Câu đố hay !!!

Đây là một thách thức đối với hầu hết các nhà phát triển cơ sở dữ liệu để ước tính chính xác kích thước của tập kết quả phổ biến nhất trong các ứng dụng của họ. Có một bộ đệm truy vấn lớn chỉ là một miếng băng lớn cho điều đó.

Có một lý do lớn hơn đã báo trước sự sụp đổ của bộ đệm truy vấn. Bốn năm trước, tôi đã trả lời bài viết Tại sao query_cache_type bị tắt theo mặc định bắt đầu từ MySQL 5.6? . Rất ngắn gọn, bộ đệm truy vấn luôn kiểm tra nhóm bộ đệm InnoDB để biết các thay đổi. Bạn có thể tìm thấy điều này trên các trang 209-215 của MySQL hiệu suất cao (Phiên bản 2) .

Tôi đã đề cập đến điều này trong những năm qua:

Sep 05, 2012: Là chi phí chung của việc vô hiệu hóa bộ đệm truy vấn thường xuyên có bao giờ đáng không?
Sep 25, 2013: làm mất hiệu lực các mục bộ đệm truy vấn (khóa)
Sep 26, 2013: giá trị lần truy cập bộ đệm truy vấn không thay đổi trong cơ sở dữ liệu của tôi
Dec 23, 2013: MySQL có mức sử dụng CPU và bộ nhớ cao

Bộ đệm truy vấn RIP !!!

— RolandoMyQueryDBA
nguồn

Tôi đồng ý rằng bộ đệm truy vấn là một băng chủ yếu cho số lượng quá chậm trên innodb. Nó làm cho các truy vấn và ứng dụng hoàn toàn không thể đoán trước được trong thời gian phản hồi, bạn có thể thấy mili giây đến giờ trên cùng một truy vấn tùy thuộc vào việc nó có được lưu trong bộ nhớ cache hay không. Tuy nhiên, ít nhất đó là một miếng băng. Bây giờ bạn đang chảy máu :)

— John

QC tồn tại trước khi InnoDB tồn tại. Câu chuyện cũ mà tôi đã nghe (có lẽ vào khoảng năm 2002) là QC đã được thêm vào để giành điểm chuẩn với MyISAM.

— Rick James

@RickJames Hah nghe có vẻ hợp lý, mặc dù điều đó gian lận Mysql cần một điều hơn bất cứ điều gì khác theo quan điểm của tôi: đa luồng trên tất cả các loại truy vấn. Họ dường như làm việc theo hướng đó (một chút ở đây một chút ở đó) một chút nhưng nó đã được thực hiện từ lâu. Đó cũng sẽ là một tính năng giết người không chỉ giành chiến thắng mà còn 'sở hữu' nhiều loại điểm chuẩn

— John

@ John - MySQL 8.0.17 (?) Có một vài truy vấn song song. Tôi chưa hào hứng. Một sản phẩm gọi là "shard query" đã xuất hiện từ lâu; nó chứng tỏ rằng sự song song thường chỉ cung cấp một nửa năng lực lý thuyết. (ví dụ: 8 lõi chỉ mang lại tốc độ tăng gấp 4 lần.) Ngoài ra, hãy nhớ rằng hầu hết I / O không có sự song song trừ khi bạn có một số thiết lập RAID nhất định.

— Rick James

@John - và ... Các máy chủ "Từ lâu" có một, có thể là hai lõi CPU. Vì vậy, song song không phải là rất hữu ích. Khi đã có nhiều lõi, có một loạt các hoạt động để dọn sạch Mutexes để nhiều kết nối có thể hoạt động song song.

— Rick James

(Tôi đồng ý với Câu trả lời khác, nhưng đây là giá trị 2 xu của tôi.)

Như đã thực hiện, ...

QC không thể hoạt động với Galera hoặc Tái tạo nhóm, cả hai đều có lực kéo nhiều hơn trong đấu trường HA.
Khi query_cache_sizelớn, nó có hiệu quả thấp hơn. Điều này là do sự thiếu hiệu quả trong "cắt tỉa". (Lưu ý: Aurora đã thực hiện lại và dường như đã khắc phục vấn đề này.)
Có một chi phí trong mỗi SELECT vì nó không biết liệu QC sẽ đi vào chơi. Nhiều thập kỷ trước, điều này được ước tính là 11%. Cho đến khi thoát khỏi QC, cách giải quyết duy nhất là thực hiện cả hai query_cache_size = 0 và query_cache_type = 0 trong tệp cấu hình. (Rất ít người nhận ra cả hai đều cần thiết.)
Trong máy chủ Sản xuất điển hình, việc chèn đang diễn ra thường xuyên. Vì mỗi lần chèn gây ra việc cắt xén tất cả các mục cho (các) bảng đó, QC hầu như vô dụng đối với các bảng như vậy.
Có lẽ 95% trong số hàng trăm hệ thống tôi đã xem xét cho các vấn đề về hiệu năng sẽ tốt hơn nếu không có QC.

— Rick James
nguồn