Làm thế nào để bạn tăng hiệu suất MySQL bằng cách sử dụng tài nguyên máy chủ hiện tại?

Tôi có một cơ sở dữ liệu MySQL và một số truy vấn của tôi trở nên chậm. Thời gian truy vấn không ổn định. Hầu hết các truy vấn đều nhanh, nhưng một số trong số chúng (có thể là đọc và trả về ít dữ liệu hơn) mất nhiều thời gian.

Tôi biết rằng thực tiễn tốt nhất là thêm chỉ mục hoặc mã cấu trúc lại, nhưng tôi đã thêm chỉ mục và tôi không muốn cấu trúc lại mã (ít nhất là trong khi tôi có các biến thể khác).

Tôi có bộ nhớ trống 8 Gb và CPU chỉ được tải đến 25% lúc cao điểm. Vì vậy, tôi muốn sử dụng tất cả các tài nguyên của tôi.

Tôi cố gắng điều chỉnh cấu hình MySQL nhưng tôi không có kinh nghiệm trong việc điều chỉnh như vậy, vì vậy tôi tăng năng suất không nhiều như tôi muốn. Đây là một ví dụ:

# Query_time: 3.019647  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 504
SET timestamp=1313380874;
SELECT COUNT(inboxentities.id) FROM inboxentities  WHERE (active=true)AND(deleted=false)AND((to_ = '44219ca4-a657-4909-b30d-a7ba0ed8e4b0'))AND(notification=true);

PS inboxentitiescó 500.000 hồ sơ. Tôi có index1 (idx_to): to_và index2 (idx_complex): deleted, notification, active,to_

Đây là kết quả giải thích chọn:

+----+-------------+---------------+------+------------------------------------------------+--------+---------+-------+------+-------------+
| id | select_type | table         | type | possible_keys                                  | key    | key_len | ref   | rows | Extra       |
+----+-------------+---------------+------+------------------------------------------------+--------+---------+-------+------+-------------+
|  1 | SIMPLE      | inboxentities | ref  | idx_status,idx_statusToname,idx_to,idx_complex | idx_to | 768     | const |  286 | Using where |
+----+-------------+---------------+------+------------------------------------------------+--------+---------+-------+------+-------------+

Đây là truy vấn ban đầu của bạn từ nhật ký chậm

SELECT COUNT(inboxentities.id) FROM inboxentities
WHERE (active=true)
AND (deleted=false)
AND ((to_ = '44219ca4-a657-4909-b30d-a7ba0ed8e4b0'))
AND (notification=true);

Cách hiệu quả nhất để lập chỉ mục cho một truy vấn như thế này là tạo một chỉ mục bao gồm càng nhiều trường trong mệnh đề WHERE càng tốt. Một chỉ mục được tạo ra với khái niệm đó trong tâm trí được gọi là chỉ số bao trùm .

Nhìn vào mệnh đề WHERE

• 'hoạt động' là đúng hoặc sai (2 giá trị). Một chỉ mục của lĩnh vực đó bị sai lệch.
• 'đã xóa' là đúng hoặc sai (2 giá trị). Một chỉ mục của lĩnh vực đó bị sai lệch.
• 'thông báo' là đúng hoặc sai (2 giá trị). Một chỉ mục của lĩnh vực đó bị sai lệch.
• 'to_' là một giá trị đáng để lập chỉ mục và thu hẹp.

Mặc dù bạn đã xác định idx_complex, nhưng có một yếu tố nữa cho truy vấn khiến chỉ mục idx_complex không được sử dụng: mệnh đề COUNT (inboxentities.id) .

Bạn đang đếm một cái gì đó trong một bảng. Chỉ mục không có điểm tham chiếu đến bảng ngoại trừ to_. Bộ điều hợp truy vấn MySQL sẽ chọn idx_to, chỉ mục đơn giản nhất. Để buộc Trình tối ưu hóa truy vấn MySQL chọn chỉ mục bao phủ mà bạn muốn (idx_complex) chỉ cần COUNT từ chỉ mục chứ không phải bảng. Đề nghị của tôi là thay đổi truy vấn một chút:

SELECT COUNT(to_) FROM inboxentities
WHERE (active=true)
AND (deleted=false)
AND ((to_ = '44219ca4-a657-4909-b30d-a7ba0ed8e4b0'))
AND (notification=true);

Hãy thử một lần !!!

CẬP NHẬT 2011-08-15 15:16 EDT

Một số người đã thấy hiệu suất cận biên tăng đáng kể bằng cách thay đổi my.cnf để đáp ứng nhu cầu hiệu suất của Storage Engine.

Bạn cần đặt Bộ đệm chính MyISAM và Bộ đệm InnoDB.

Điều này sẽ đề xuất kích thước phù hợp MyISAM Key Cache cho tập dữ liệu đã cho của bạn:

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1))
recommended_key_buffer_size FROM
(SELECT LEAST(POWER(2,32),KBS1) KBS
FROM (SELECT SUM(index_length) KBS1
FROM information_schema.tables
WHERE engine='MyISAM' AND
table_schema NOT IN ('information_schema','mysql')) AA ) A,
(SELECT 2 PowerOf1024) B;

Điều này sẽ đề xuất nhóm Bộ đệm InnoDB có kích thước phù hợp cho tập dữ liệu đã cho của bạn

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,
(SELECT 2 PowerOf1024) B;

BTW

• (CHỌN 0 PowerOf1024) tạo câu trả lời bằng byte
• (CHỌN 1 PowerOf1024) tạo câu trả lời bằng KB
• (CHỌN 2 PowerOf1024) tạo câu trả lời bằng MB
• (CHỌN 3 PowerOf1024) tạo câu trả lời tính bằng GB

Nếu bạn vượt quá điều này, gửi email cho tôi.

Khi bạn có các cài đặt này, hãy đảm bảo rằng số kết hợp cho đề xuất_key_buffer_size và đề xuất_innodb_buffer_pool_size không vượt quá 75% RAM đã cài đặt.

CẬP NHẬT 2011-08-15 15:35 EDT

Bạn có thể muốn chạy mysqltuner.pl trên máy chủ để cho phép nó cho bạn biết cách sử dụng bộ nhớ cho các kết nối DB. Cài đặt quản lý sử dụng bộ nhớ cho mỗi Kết nối DB bao gồm

• tham gia_buffer_size
• sort_buffer_size
• đọc_buffer_size

Chúng thường được nhân với max_connections .

Bạn có thể tải mysqltuner.pl xuống như sau từ dòng lệnh Linux:

wget mysqltuner.pl

Đầu ra từ nó là một cái gì đó như thế này:

$ perl mysqltuner.pl

 >>  MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: username
Please enter your MySQL administrative password: (password hidden)

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.47-community-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 7G (Tables: 6)
[--] Data in InnoDB tables: 2G (Tables: 382)
[!!] Total fragmented tables: 84

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 12d 20h 24m 6s (54M q [49.462 qps], 555K conn, TX: 287B, RX: 95B)
[--] Reads / Writes: 62% / 38%
[--] Total buffers: 9.3G global + 48.2M per thread (1250 max threads)
[!!] Maximum possible memory usage: 68.2G (291% of installed RAM)
[OK] Slow queries: 0% (647/54M)
[OK] Highest usage of available connections: 5% (69/1250)
[OK] Key buffer size / total MyISAM indexes: 256.0M/19.4M
[OK] Key buffer hit rate: 100.0% (51M cached / 10 reads)
[OK] Query cache efficiency: 89.3% (47M cached / 52M selects)
[!!] Query cache prunes per day: 60670
[OK] Sorts requiring temporary tables: 0% (239 temp sorts / 1M sorts)
[!!] Temporary tables created on disk: 47% (1M on disk / 2M total)
[OK] Thread cache hit rate: 99% (103 created / 555K connections)
[OK] Table cache hit rate: 21% (722 open / 3K opened)
[OK] Open file limit used: 0% (70/32K)
[OK] Table locks acquired immediately: 99% (12M immediate / 12M locks)
[OK] InnoDB data size / buffer pool: 2.4G/8.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Increasing the query_cache size over 128M may reduce performance
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (> 1G) [see warning above]
    tmp_table_size (> 32M)
    max_heap_table_size (> 32M)