2016-01-26 15 views
10

Tôi có một truy vấn chạy trong khoảng 20 giây trên máy chủ MySQL 5.1 nhưng mất gần 15 phút trên máy chủ MariaDB 5.5. Các nghi phạm thông thường như key_buffer_size và tmp_table_size và max_heap_table_size đều bằng nhau (128M). Hầu hết các thiết lập đều bình đẳng như xa như tôi có thể nhìn thấy (query_cache, vv)Mariadb 5.5 chậm hơn MySQL 5.1

Truy vấn:

SELECT products.id, 
concat(publications.company_name,' [',publications.quote,'] ', products.name) as n, 
products.impressions, 
products.contacts, 
is_channel, 
sl.i, 
count(*) 
FROM products 
LEFT JOIN publications ON products.publications_id = publications.id 
LEFT OUTER JOIN ( 
    SELECT adspace.id AS i, 
    slots.products_id FROM adspace 
    LEFT JOIN slots ON adspace.slots_id = slots.id 
     AND adspace.end > '2016-01-25 10:28:49' 
     WHERE adspace.active = 1) AS sl 
    ON sl.products_id = products.id 
WHERE 1 = 1 
AND publications.active=1 
GROUP BY products.id 
ORDER BY n ASC; 

Sự khác biệt duy nhất là trong fase giải thích:

Cũ server (MySQL 5.1)

máy chủ
+----+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 
| id | select_type | table  | type | possible_keys | key  | key_len | ref          | rows | Extra       | 
+----+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 
| 1 | PRIMARY  | products  | ALL | NULL   | NULL | NULL | NULL         | 6568 | Using temporary; Using filesort | 
| 1 | PRIMARY  | publications | eq_ref | PRIMARY  | PRIMARY | 4  | db.products.publications_id |  1 | Using where         | 
| 1 | PRIMARY  | <derived2> | ALL | NULL   | NULL | NULL | NULL         | 94478 |         | 
| 2 | DERIVED  | adspace  | ALL | NULL   | NULL | NULL | NULL         | 101454 | Using where      | 
| 2 | DERIVED  | slots  | eq_ref | PRIMARY  | PRIMARY | 4  | db.adspace.slots_id   |  1 |            | 
+----+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 

mới (MariaDB 5,5)

+------+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 
| id | select_type | table  | type | possible_keys | key  | key_len | ref          | rows | Extra       | 
+------+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 
| 1 | SIMPLE  | products  | ALL | test_idx  | NULL | NULL | NULL         | 6557 | Using temporary; Using filesort | 
| 1 | SIMPLE  | publications | eq_ref | PRIMARY  | PRIMARY | 4  | db.products.publications_id |  1 | Using where         | 
| 1 | SIMPLE  | adspace  | ALL | NULL   | NULL | NULL | NULL         | 100938 | Using where      | 
| 1 | SIMPLE  | slots  | eq_ref | PRIMARY  | PRIMARY | 4  | db.adspace.slots_id   |  1 | Using where         | 
+------+-------------+--------------+--------+---------------+---------+---------+-----------------------------------------+--------+---------------------------------+ 

Một chỉ mục đã được thêm vào bảng sản phẩm trên máy chủ mới để tăng tốc độ, không có kết quả.

biến Động cơ:

Cũ server:

mysql> show variables like '%engine%'; 
+---------------------------+--------+ 
| Variable_name    | Value | 
+---------------------------+--------+ 
| engine_condition_pushdown | ON  | 
| storage_engine   | MyISAM | 
+---------------------------+--------+ 

mysql> show variables like '%buffer_pool%'; 
+-------------------------+---------+ 
| Variable_name   | Value | 
+-------------------------+---------+ 
| innodb_buffer_pool_size | 8388608 | 
+-------------------------+---------+ 

New server:

MariaDB [db]> show variables like '%engine%'; 
+---------------------------+--------+ 
| Variable_name    | Value | 
+---------------------------+--------+ 
| default_storage_engine | InnoDB | 
| engine_condition_pushdown | OFF | 
| storage_engine   | InnoDB | 
+---------------------------+--------+ 


MariaDB [db]> show variables like '%buffer_pool%'; 
+---------------------------------------+-----------+ 
| Variable_name       | Value  | 
+---------------------------------------+-----------+ 
| innodb_blocking_buffer_pool_restore | OFF  | 
| innodb_buffer_pool_instances   | 1   | 
| innodb_buffer_pool_populate   | OFF  | 
| innodb_buffer_pool_restore_at_startup | 0   | 
| innodb_buffer_pool_shm_checksum  | ON  | 
| innodb_buffer_pool_shm_key   | 0   | 
| innodb_buffer_pool_size    | 134217728 | 
+---------------------------------------+-----------+ 

Tất cả các bảng được sử dụng trong truy vấn là MyISAM (cả máy chủ cũ và mới)

Tiểu sử cho thấy rằng truy vấn cũ dành khoảng 16 giây trong 'sao chép vào bảng tmp' và các câu hỏi mới erver khoảng 800 giây trong fase này.

Máy chủ mới tất cả đều có ổ đĩa SSD để lưu trữ và máy chủ cũ có đĩa bình thường.

Chỉnh sửa: Tôi cũng có máy chủ MySQL 5.5 và truy vấn chỉ mất khoảng 10 giây. Ngoài ra với tất cả các thiết lập tương tự như xa như tôi có thể nhìn thấy.

tôi đã cố gắng để tóm tắt nó trong một bảng:

Location:  Customer     Own      Customer 
MySQL Type:  MySQL      MySQL     MariaDB 
Mysql Version: 5.1.56-community-log  5.5.39-1-log (Debian) 5.5.44-MariaDB-log 
HDD:   Normal      Normal     SSD 
Type:   Virtual      Real     Virtual 
Query time:  ~15s      ~10s     ~15min 
DB engine:  MyISAM      InnoDB     InnoDB 
Table Engine: MyISAM      MyISAM     MyISAM 

Tôi không muốn viết lại truy vấn (mặc dù nó có thể sử dụng một số công việc) nhưng tôi muốn tìm sự khác biệt giữa 2 máy, của tôi đoán là một thiết lập không lý tưởng trong MariaDB nhưng tôi không thể tìm thấy nó.

+0

Bạn có chắc là bạn sử dụng cùng một công cụ bảng cho cả hai cơ sở dữ liệu? – Mjh

+0

Có lẽ câu trả lời cho câu hỏi của bạn: Bộ lưu trữ hoàn toàn khác ... – hendrik

+0

Vì vậy, nếu tôi hiểu chính xác, động cơ ở cấp cơ sở dữ liệu sẽ tạo sự khác biệt ngay cả khi động cơ ở mức bảng giống nhau? – darkownage

Trả lời

4

Từ giải thích ở trên có thể thấy rằng Derived Table Merge Optimization được sử dụng. Thật không may trong trường hợp của bạn có nghĩa là thay vì chỉ quét một bảng đầy đủ trên adspace một số ~ 6k được thực hiện.

Một giải pháp khả thi là vô hiệu hóa tối ưu hóa trước truy vấn bằng cách phát hành set optimizer_switch='derived_merge=off';.Ngược lại, tương thích ngược lại sẽ thêm GROUP BY adspace.id, slots.products_id vào truy vấn phụ (nếu nó không thay đổi kết quả - an toàn nhất là nhóm trên PK của tất cả các bảng đã tham gia), ngăn cấm hợp nhất bằng các ngữ nghĩa khác nhau.

Có một báo cáo optimizer bug về điều đó - trường hợp của bạn có thể trợ giúp.

+0

Cài đặt của derived_merge = OFF làm cho truy vấn chuyển từ ~ 15min đến ~ 0.3seconds. Tốc độ tăng nhỏ :) – darkownage

+0

@darkownage - Tôi bị nhầm lẫn bởi nhận xét của bạn - đó có phải là một _decrease_ đáng kể không? hoặc _increase_? –

+0

@RickJames - Xin lỗi vì câu lạ :) Truy vấn diễn ra từ khoảng 15 phút đến 0,5 giây. Vì vậy, tốc độ tăng lên rất lớn. Chúng tôi đã chọn tắt 'tối ưu hóa' này vì nó đã bị chặn và truy vấn đã thực hiện công việc và là cách khắc phục dễ nhất. Hy vọng điều này sẽ trả lời câu hỏi của bạn :) – darkownage

1

Đây có thể không phải là câu trả lời nhưng MariaDB 5.5 sử dụng một thuật toán khác để thực hiện phép nối. Theo như tôi biết trong MariaDB 5.5 Batch Key Access Join đã được giới thiệu. Các phiên bản cũ hơn của MySQL hoặc MariaDB sử dụng một phiên bản khác. Mặc dù phiên bản mới sẽ nhanh hơn trong hầu hết các trường hợp, có thể các bảng cụ thể của bạn hoạt động tốt hơn bằng cách sử dụng phiên bản cũ.

Chỉnh sửa: Câu trả lời này có thể đã lỗi thời khi bạn đề cập rằng bạn đã sử dụng các công cụ lưu trữ khác nhau.