Ý tôi là như sau:
Nếu tạo một chỉ mục trên một bảng với ncác hàng mất tthời gian. Sẽ tạo một chỉ mục trên cùng một bảng với thời gian 1000*nxấp xỉ 1000*t.
Những gì tôi đang cố gắng đạt được là ước tính thời gian cần thiết để tạo chỉ mục trên cơ sở dữ liệu sản xuất bằng cách tạo cùng một chỉ mục trên cơ sở dữ liệu thử nghiệm nhỏ hơn nhiều .
Câu trả lời:
Tạo chỉ mục về cơ bản là một hoạt động sắp xếp , vì vậy tốt nhất là có độ phức tạp tăng trưởng của đơn hàng n log ntrung bình (bạn có thể thấy nó hoạt động tốt hơn trong một số trường hợp và không có khả năng làm tồi tệ hơn nhiều).
Nếu tất cả các trang dữ liệu có liên quan của bạn phù hợp với RAM và đã có RAM và chỉ mục cũng sẽ phù hợp và DBMS của bạn không buộc các trang chỉ mục được ghi trước khi tạo xong (vì vậy các khối chỉ mục không được cập nhật trên đĩa nhiều lần trong suốt hoạt động), khi đó tốc độ ghi chỉ mục kết quả vào đĩa sẽ có ý nghĩa lớn hơn thời gian thực hiện sắp xếp - vì vậy bạn có thể thấy bạn tiến gần hơn đến mối quan hệ tuyến tính giữa số lượng hàng và thời gian tạo chỉ mục - nhưng nếu bạn cho rằng trường hợp xấu hơn thì bạn sẽ ít ngạc nhiên hơn!
Hãy nhớ rằng trừ khi bạn sẽ không dừng truy cập vào cơ sở dữ liệu sản xuất trong quá trình vận hành, bất kỳ chỉ mục nào được tạo sẽ cạnh tranh băng thông IO và / hoặc khóa với hoạt động khác, vì vậy bạn nên thử tính toán điều này nếu bạn đang thực hiện kiểm tra ước tính thời gian của mình trên một hệ thống khác ngay cả khi nó được cấu hình giống hệt nhau.
Cũng đáng chú ý là nếu bạn có thể chia các trục cho các chỉ mục từ các trục cho bảng thì bạn sẽ có thể làm việc từ hai đĩa cùng một lúc (vẫn bị giới hạn ở tốc độ của bộ điều khiển đĩa ở giữa, nếu RAID hoặc tương tự, nhưng nó sẽ nhanh hơn một đĩa).
Tôi nhận ra rằng việc tạo một chỉ mục không hoàn toàn là một hoạt động đọc-ghi-mô-đun, nhưng nó tăng tốc đáng kể.
CẨN THẬN: Bản thân tôi là một người MSSQL và vì vậy tôi không chắc chắn về MySQL, nhưng tôi phải tưởng tượng rằng khái niệm chia tách trục không đặc trưng cho SQLServer và Oracle (nơi tôi cũng đã nghe nói về nó, IIRC ). Tôi chỉ không biết làm thế nào để thiết lập khái niệm đó. Nhưng theo thuật ngữ SQLServer, điều đó có nghĩa là có một nhóm fileg riêng biệt bên cạnh PRIMARYvà đưa các chỉ mục vào nhóm filegroup khác, với các filegroup khác được gán cho một nhóm các trục chính không liên quan PRIMARY(vị trí trục chính được cấp so với filegroups là một câu chuyện khác hoàn toàn)
Nó phụ thuộc.
Biến số 1: Nếu MySQL chọn xây dựng (các) chỉ mục một cách nhanh chóng hoặc đợi cho đến khi tất cả dữ liệu được đưa vào, sau đó thực hiện sắp xếp, v.v., để xây dựng chỉ mục. Lưu ý: Các chỉ số UNIQUE (tôi nghĩ) phải được xây dựng nhanh chóng để có thể xác minh tính ĐỘC ĐÁO. KHÓA CHÍNH cho InnoDB được lưu trữ cùng với dữ liệu (hoặc bạn có thể nói ngược lại), do đó PHẢI được xây dựng ngẫu nhiên.
Biến số 2: Chỉ mục theo dõi dữ liệu (ví dụ: AUTO_INCREMENT hoặc dấu thời gian) so với ngẫu nhiên (GUID, MD5) hoặc ở đâu đó ở giữa (số phần, tên, friend_id).
Biến số 3 (nếu chỉ mục được xây dựng nhanh chóng): Chỉ mục có thể vừa với bộ đệm (key_buffer hoặc innodb_buffer_pool) hoặc có thể tràn vào đĩa.
Các chỉ mục theo dõi dữ liệu là hiệu quả và hầu như tuyến tính, bất kể câu trả lời cho # 1.
Id ngẫu nhiên là một nỗi đau. Nếu chỉ mục không phù hợp với bộ đệm, thời gian để xây dựng nó sẽ tệ hơn nhiều so với tuyến tính, bất kể các biến khác. (Tôi không đồng ý với Rolando trong trường hợp này.) Một bảng InnoDB khổng lồ có GUID cho PK rất chậm để CHỌN vào - lập kế hoạch trên 100 hàng / giây cho các đĩa thông thường; có thể 1000 nếu bạn có SSD. LOAD DATA và INSERT hàng loạt sẽ không giúp bạn vượt qua sự chậm chạp của bộ lưu trữ ngẫu nhiên.
3,53 đến 5,6 - không có nhiều thay đổi.
Nhiều trục chính? Phân chia RAID tốt hơn trong hầu hết mọi tình huống so với việc gán thủ công cái này ở đây và cái kia ở đó. Tách thủ công dẫn đến các tình huống không cân bằng - quét bảng bị kẹt trên đĩa dữ liệu; một hoạt động chỉ mục bị kẹt trên đĩa chỉ mục; một truy vấn đơn độc đầu tiên đánh vào đĩa chỉ mục, sau đó là đĩa dữ liệu (không chồng lấp); v.v.