Khi nào nên sử dụng MySQL query_cache?

Cho đến gần đây, tôi đã xem bộ đệm truy vấn là một công cụ rất quan trọng để cải thiện hiệu năng truy vấn. Hôm nay, tôi đã nghe một podcast thảo luận về việc điều chỉnh bộ đệm truy vấn thành 0 và sử dụng giải pháp bộ nhớ đệm tốt hơn (như memcache.d).

Nhưng họ cũng đề cập rằng có một vài trường hợp trong đó query_cache là hữu ích. Vì vậy, một khuyến nghị chung sẽ là kích hoạt nó theo yêu cầu (sử dụng SELECT SQL_CACHE, với cài đặt query_cache_type = 2 config).

Câu hỏi của tôi là, giả sử bạn đã có một giải pháp bộ nhớ đệm như memcache.d, loại tình huống nào sẽ làm cho query_cache tối ưu hơn?

Chỉnh sửa: thêm liên kết

Memcached (hoặc Coherence ) lưu trữ toàn bộ tập kết quả . Một bộ đệm trong cơ sở dữ liệu lưu trữ các hàng cơ sở dữ liệu. Vì vậy, giả sử bạn có một mẫu truy cập trong đó truy vấn được cố định và dữ liệu thay đổi không thường xuyên (ví dụ select * from restaurants where location='london'). Bạn có thể chạy truy vấn đó hàng nghìn lần cho mỗi lần thêm một nhà hàng mới, do đó, lưu bộ đệm toàn bộ kết quả có ý nghĩa, nó lưu vào cơ sở dữ liệu mọi lúc - nhưng bạn vẫn có tất cả khả năng quản lý và linh hoạt của RDBMS và SQL (bạn chỉ cần loại bỏ bộ đệm trong trường hợp kỳ lạ thay đổi dữ liệu). Một số người gọi dữ liệu tham khảo này hoặc dữ liệu tĩnh.

Nhưng giả sử bạn có mẫu truy cập đặc biệt (có lẽ có nhiều tùy chọn để người dùng của bạn tìm chính xác nơi họ muốn ăn tối nay, nhưng hiếm khi hai người dùng có cùng sở thích). Sau đó, bạn có thể muốn lưu trữ các hàng (để lưu vào đĩa) nhưng tập hợp từng kết quả được đặt trong bộ nhớ. Đó là khi bạn muốn cơ sở dữ liệu tự quản lý cái gì và làm thế nào nó lưu trữ. Trong hầu hết các trường hợp, một cách tiếp cận lai hoặc lớp sẽ hoạt động tốt nhất.

Lưu ý rằng cũng có một loại bộ nhớ đệm thứ ba đang hoạt động - bộ đệm hệ thống tập tin của hệ điều hành. Tôi không thích điều này, vì một lý do đơn giản là nếu bạn đọc một khối từ đĩa thì nó hiện tồn tại trong bộ đệm cơ sở dữ liệu và bộ đệm hệ thống tệp, nhưng cơ sở dữ liệu không "biết" về cái sau, vì vậy nó không thể làm bất cứ điều gì thông minh với nó, như xem mức độ thường xuyên được sử dụng. Từ quan điểm của DBA, mọi bộ nhớ dự phòng trên hệ thống và về những gì bản thân HĐH cần để được hạnh phúc đều bị lãng phí.

Tôi nghĩ rằng có rất nhiều thông tin sai về bộ đệm truy vấn ngoài kia.

Trường hợp tốt nhất cho bộ đệm truy vấn, là khi bạn phải kiểm tra một số lượng rất lớn các hàng, nhưng chỉ trả lại một vài cho khách hàng. Một tình huống điển hình trong đó điều này là phổ biến, là một hệ thống không áp dụng tối ưu hóa hoặc lập chỉ mục thích hợp.

Trong tình huống có nhiều truy vấn là tra cứu khóa chính hoặc được tối ưu hóa rất tốt, bộ đệm truy vấn có thể gây ra khả năng mở rộng âm. Vâng: nó làm cho mọi thứ tồi tệ hơn!

Lý do cho điều này, là thiết kế có thêm một số khóa bên trong, điều này hạn chế máy chủ MySQL của bạn mở rộng trên các máy đa lõi.

Bộ đệm truy vấn là một nguyên nhân cho nhiều "gian hàng đột ngột" trong MySQL - không phải tất cả chúng đều rõ ràng. Trong Percona Server, chúng tôi đã thêm một trạng thái mới vào danh sách quy trình (Chờ đợi trên Qcache mutex): http://www.percona.com/docs/wiki/percona-server:features:status_wait_query_cache_mutex

(Tuyên bố miễn trừ trách nhiệm, tôi làm việc cho Percona.)

Tôi không nghĩ rằng nó đã được đề cập ở đây, nhưng có thể bộ đệm truy vấn cũng có ảnh hưởng xấu đến hiệu suất; có lẽ đây là những gì đã được đề cập trên podcast của bạn. Nếu hiệu quả của bộ đệm truy vấn thấp ( Qcache_hits / (Qcache_hits + Com_select)) và có nhiều mận bộ đệm truy vấn ( Qcache_lowmem_prunes/Uptime) xảy ra thì có thể chi phí duy trì bộ đệm là chi phí cao hơn bạn đạt được.

Bài đăng này của Peter Zaitsev bao gồm mọi thứ chi tiết hơn một chút. Trái với một số câu trả lời ở đây, ông nói rằng bộ đệm dành cho toàn bộ tập kết quả. Tuy nhiên, bài viết đã được vài năm tuổi. Một số suy nghĩ gần đây đã được đăng vào tháng Tư.

Tôi luôn có ấn tượng rằng nó đang lưu trữ các bộ kết quả đầy đủ, không phải các hàng như đã đề cập ở trên. Nếu bạn có chính xác cùng một truy vấn, nó sẽ bỏ qua phân tích / lập kế hoạch và trả về cùng một tập kết quả (kích thước tối đa được kiểm soát bởi query_cache_limit).

Nếu bạn đã tắt bộ đệm truy vấn, thì môi trường đọc cao trong đó các CHỌN rất đơn giản, sau đó không có cơ chế khóa nào được bật. Tôi mới trải nghiệm điều này với MySQL 5.5 bằng cách sử dụng nhiều bộ đệm.

Nếu bạn gọi các truy vấn cơ bản giống nhau nhiều lần, không cần phải lặp đi lặp lại cùng một truy vấn cho đến khi những con bò về nhà. Một bộ đệm truy vấn nhỏ sẽ đủ trong một môi trường đọc nặng bằng cách sử dụng một bộ CHỌN nhỏ mà bạn biết sẽ luôn được gọi.

memcached tiện dụng hơn nhiều đối với các tập dữ liệu lớn trong môi trường đọc nặng. Truy vấn bộ nhớ cache là một con vịt què tại thời điểm đó.