Có quá nhiều bảng trong cơ sở dữ liệu Mysql có thể ảnh hưởng đến hiệu suất?


10

Có quá nhiều bảng (ví dụ 200) trong một cá thể cơ sở dữ liệu Mysql có thể làm giảm hiệu suất của nó?

Câu trả lời:


8

Nói chung, càng nhiều thứ bạn có sẽ làm giảm hiệu suất. Tuy nhiên, 200 dường như là một con số khá nhỏ. 2.000 có thể là một hit hiệu suất thực sự và chắc chắn 20.000. Tuy nhiên, nói chung, bạn nên giữ số lượng bảng của mình nhỏ vì MySQL có thể xử lý số lượng hàng rất lớn trong bảng.


7
Một số lượng lớn các bảng có thể tạo ra sự khác biệt lớn nếu ứng dụng của bạn sử dụng 'information_schema'. Không có gì trong 'information_schema' được lưu trữ. Một số hệ thống ORM khác nhau sử dụng rất nhiều điều này.
Zoredache


4

Số lượng bảng không quan trọng bằng:

  1. Những truy vấn nào bạn đang chạy - bạn không có khả năng truy vấn tất cả 200 trong một truy vấn
  2. Tải truy vấn tổng thể trên hệ thống tại bất kỳ thời điểm nào

Có các bảng thừa có nghĩa là bộ nhớ và dung lượng ổ cứng có thể lấy lại và sử dụng cho những thứ khác. Hãy nhớ rằng việc không chuẩn hóa các bảng của bạn làm tăng nguy cơ dữ liệu xấu vì bạn đang thoát khỏi tính toàn vẹn của giới thiệu.


4

Nói chung 200 bảng không phải là một vấn đề nhưng nó phụ thuộc vào một số điều.

Máy chủ MySQL chuyên dụng vs Máy chủ được chia sẻ với phần mềm khác, RAM 128Mb so với 128Gb, ​​v.v., các bảng nhỏ có ít bản ghi so với các bảng có đốm màu và hàng triệu hàng.

MySQL có thể cài đặt và nhiều công cụ mỗi hiệu ứng bảng hiệu suất theo những cách khác nhau.

MyISAM thường có ba tệp trên mỗi bảng .frm, .MYD, .MYI

INNODB ở chế độ bình thường có .frm với tất cả dữ liệu được lưu trữ trong tệp trung tâm

INNODB trong một tệp cho mỗi chế độ bảng có .frm, .idb

table_open_cache là số lượng bảng có thể được mở cùng một lúc (Mặc định 64). Điều này có thể cần phải lớn hơn số lượng bảng trong lược đồ của bạn vì nó liên quan đến số lượng kết nối đang truy vấn DB. 100 kết nối tham gia 3 bảng có nghĩa là bạn có 300 bảng được lưu trong bộ nhớ cache cộng với bất kỳ bảng tạm thời nào. Nói chung, một lược đồ hoặc các kết nối càng phức tạp thì số lượng càng lớn.

open-files-limit Tôi có xu hướng đặt giá trị này thành 4x bảng_open_cache, nên rộng rãi thay vì bận tâm để tìm ra một giá trị chính xác.

Giới hạn xử lý tệp hệ điều hành cho người dùng mysql cũng có thể là một vấn đề (trên linux, mặc định thường có thể là 1024, ulimit -n để hiển thị giới hạn người dùng) điều này có thể gây ra sự cố với số lượng bảng lớn khi số lượng ít hơn yêu cầu mysql. Điều này ít nhất phải giống như giới hạn tệp mở.

Như với bất kỳ cơ sở dữ liệu nào, có hàng trăm tham số điều chỉnh mà bạn có thể điều chỉnh để tối ưu hóa cơ sở dữ liệu cho lược đồ cụ thể của mình. MySQL tệ hơn cho điều này hơn hầu hết khi bạn có thể cắm thêm các công cụ bổ sung nếu bạn muốn tức là công cụ cụm NDB.

http://dev.mysql.com/doc/refman/5.1/en/table-cache.html

Hy vọng nó giúp


2

Đối với mỗi chỉ mục của bảng, MySQL có chỉ mục riêng. Index lấy bộ nhớ để giữ và sử dụng, và có giới hạn toàn cầu cho các chỉ mục. Khi có nhiều bảng chỉ mục không thể có trong RAM, vì vậy chúng sẽ chuyển sang đĩa, điều này ảnh hưởng trực tiếp đến hiệu suất. Hãy thử nâng mức này trong my.cnf:: key_buffer_size=256Mđây là dung lượng RAM được đặt sang một bên để giữ thông tin chỉ mục.


1

Có thể không Chắc chắn rồi. Nhưng bao nhiêu phụ thuộc rất nhiều vào ứng dụng của bạn và các mẫu truy cập của ứng dụng đó, và nếu bạn đang sử dụng myisam hoặc innodb, và nếu innodb có ở chế độ tệp trên mỗi bảng hay không, và kích thước của nhật ký innodb. Bạn sẽ cần phải cung cấp cho chúng tôi nhiều chi tiết hơn thế.


1

Không - Tôi không nghĩ số lượng bảng sẽ là nút cổ chai hiệu năng trong hệ thống của bạn. Rốt cuộc, chúng chỉ là các tập tin trên hệ thống tập tin của bạn. Không có gì bất thường về việc có hàng trăm bảng trong cơ sở dữ liệu.

Nhiều khả năng là các truy vấn của bạn không được tối ưu hóa đúng cách. Tôi sẽ khuyên nên bật log-slow-querieslog-queries-not-using-indexes. Khi bạn xác định các truy vấn chậm, hãy sử dụng explaintùy chọn để xem kế hoạch truy vấn cho các truy vấn này để xác định các vị trí thiếu chỉ mục.

Xem http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html để biết thêm chi tiết.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.