Mysql, handlersocket và phân vùng?

Question

Plugin trình xử lý có biết phân vùng có thể có trên bảng không? Tôi đã không tìm thấy đề cập về các tài liệu này, tôi thậm chí không biết nếu phân vùng là minh bạch cho các ổ cắm xử lý hoặc nó là cái gì mà tối ưu hóa sql nào.

Answer 1

Câu trả lời ngắn:

HandlerSocket hoạt động tốt với các bảng được phân đoạn (nghĩa là tất cả các thao tác được hỗ trợ), nhưng không biết bất kỳ phân vùng nào. Phân vùng cắt tỉa không được cố gắng, và do đó, có một chi phí hiệu suất khi handlersocket được sử dụng với các bảng được phân đoạn.

Long trả lời:

Phân vùng trong MySQL được thực hiện ở các cấp độ khác nhau: phân tích cú pháp, xử lý chung chung, truy vấn tối ưu. Trình xử lý chung (ha_partition) cung cấp phân vùng cho các công cụ không hỗ trợ nó (tất cả chúng ngoại trừ NDB). Trình xử lý này thực hiện một loại chuỗi các mẫu có trách nhiệm: nó cắm chính nó giữa máy chủ và các trình xử lý thông thường của công cụ bên dưới (một trên mỗi phân vùng).

Khi truy vấn được thực hiện, trình xử lý ha_partition chuyển tiếp các thao tác tới tất cả các trình xử lý cơ bản tương ứng với từng phân vùng. Đây là lý do tại sao bạn có thể có cùng hỗ trợ phân vùng cho InnoDB, MyISAM, v.v ...

Cắt tỉa phân vùng (tức là lọc tìm kiếm/quét vô dụng) được thực hiện trong trình tối ưu hóa truy vấn, không phải trong trình xử lý ha_partition. Vì vậy, về cơ bản khi tra cứu được thực hiện thông qua ha_partition, nếu trình tối ưu hóa không giới hạn danh sách phân vùng, tra cứu được thực hiện trên tất cả các phân vùng, và sau đó một thuật toán kết hợp được sử dụng để đọc n con trỏ song song.

Sau đây presentation bởi Mattias Jonsson và Mikael Ronström (Oracle) rất hữu ích để hiểu cách phân vùng được triển khai trong MySQL.

Bây giờ plugin HandlerSocket trực tiếp dựa trên trình xử lý chung. Không có kiến ​​thức phân vùng ở cấp HandlerSocket. Khi truy vấn HandlerSocket được áp dụng đối với một bảng được phân đoạn, trình xử lý ha_partition sẽ được sử dụng một cách minh bạch.

Tin vui là HandlerSocket hoạt động tốt với các bảng được phân đoạn mà không mất thêm chi phí. Tin xấu là nó không được hưởng lợi từ việc cắt phân vùng vì điều này chỉ được thực hiện trong trình tối ưu hóa truy vấn SQL.

Đây là một ví dụ để chứng minh điều đó (được kiểm tra với Máy chủ Percona 5.5). Chúng tôi sẽ sử dụng 2 bảng: mytable_np không được phân đoạn, mytable được phân đoạn.

create table mytable_np (id int, x varchar(100), primary key(id), key(x)) 
engine=InnoDB ; 

insert into mytable_np values (1, 'A'); 
insert into mytable_np values (11, 'B'); 
insert into mytable_np values (21, 'C'); 
insert into mytable_np values (31, 'D'); 
insert into mytable_np values (41, 'E'); 
insert into mytable_np values (51, 'F'); 
commit; 

create table mytable (id int, x varchar(100), primary key(id), key(x)) 
engine=InnoDB 
partition by range (id) (
    partition p0 values less than (10), 
    partition p1 values less than (20), 
    partition p2 values less than (30), 
    partition p3 values less than (40), 
    partition p4 values less than (50), 
    partition pend values less than (1000) 
); 

insert into mytable values (1, 'A'); 
insert into mytable values (11, 'B'); 
insert into mytable values (21, 'C'); 
insert into mytable values (31, 'D'); 
insert into mytable values (41, 'E'); 
insert into mytable values (51, 'F'); 
commit; 

Các truy vấn sau đây có thể được thực hiện để thực hiện một đơn giản chính truy cập chính:

select * from mytable where id = 51 ; 

select * from mytable_np where id = 51 ; 

Các kịch bản netcat/telnet sau đây có thể được sử dụng để truy vấn sử dụng HandlerSocket (hãy cẩn thận với các ký tự TAB):

P  0  test mytable PRIMARY id,x                                                 
0  =  1  51 

P  0  test mytable_np PRIMARY id,x                                                 
0  =  1  51 

Để đánh giá số lần tra cứu, truy vấn sau có thể được thực hiện trước và sau mỗi lần thực hiện truy vấn để đếm số lượng truy cập khóa trình xử lý:

show global status like 'Handler_read_key' ; 

Nếu chúng ta đo lường số lượng chủ chốt xử lý các truy cập thực hiện trong bốn trường hợp, chúng tôi đã nhận:

SQL query against non partitioned table:  2 
SQL query against partitioned table:   2 
HandlerSocket against non partitioned table: 2 
HandlerSocket against partitioned table:  7 

Trong ba trường hợp đầu tiên, chúng tôi có một tra cứu để tìm ra liên tiếp, cộng với một thêm phím truy cập để kiểm tra này là hàng cuối cùng để đọc. Trong trường hợp cuối cùng, chúng tôi có một tra cứu cho mỗi phân vùng không trống. Có 6 trong số đó. Chìa khóa sẽ được tìm thấy chỉ trong một trong số họ, và một truy cập thêm được thực hiện để kiểm tra có chỉ là một hàng phù hợp. Vì vậy, kết quả là 7.

Ví dụ này chứng minh rằng ngay cả trong trường hợp đơn giản nhất (truy cập khóa chính), HandlerSocket không thể cắt phân vùng. Một hình phạt hiệu suất nên luôn luôn được mong đợi khi HandlerSocket được sử dụng chống lại phân vùng. Các phân vùng nhiều hơn, chi phí cao hơn (tuyến tính).